React Native eller Kotlin Multiplatform?

Kotlin Multiplatform har på kort tid gått fra kuriositet til et reelt alternativ, og i 2026 vurderer stadig flere native-team det opp mot det etablerte React Native. De to løser det samme grunnproblemet, nemlig å slippe å bygge alt to ganger, men med ulik filosofi. Her er forskjellen sett fra kundens side.

To modeller for å dele kode

Den avgjørende forskjellen ligger i hvor mye som deles mellom iOS og Android.

React Native deler i prinsippet alt. Både logikken og grensesnittet i appen skrives én gang, i JavaScript, og kjører på begge plattformene. Det gir maksimal gjenbruk: én kodebase, ett team, to apper.

Kotlin Multiplatform, KMP, deler bare den felles logikken: beregninger, regler og hvordan appen snakker med serveren. Selve grensesnittet bygges native for hver plattform, altså separat for iOS og Android. Du deler hjernen, men bygger ansiktet to ganger.

Det høres ut som mer arbeid med KMP, og for grensesnittets del stemmer det. Gevinsten er at grensesnittet blir helt native og føles akkurat slik hver plattform skal, samtidig som du slipper å skrive logikken dobbelt.

Modenhet i økosystem og verktøy

Økosystemet har betydning for hvor smidig byggingen går fordi det avgjør hvor mye som allerede finnes ferdig til gjenbruk.

React Native har altså et forsprang i bredden av ferdige komponenter, noe som kan gjøre vanlige appbehov raskere å løse. KMP er stabilt og brukes i produksjon, men har et smalere utvalg av ferdige deler. Gapet krymper år for år, men det finnes.

Hvilket team velger hva

Den mest praktiske måten å velge på er å se på hvilket team du har eller ønsker å ha.

KMP passer ofte eksisterende native-team. Et team som allerede bygger native, særlig med Kotlin på Android-siden, kan ta i bruk KMP for å dele logikken uten å forlate den native verdenen sin. Teamet beholder den native følelsen i grensesnittet og slipper samtidig dobbeltarbeid i logikken.

React Native passer ofte webnære team. Utviklere med bakgrunn i JavaScript og web kommer raskt inn i React Native. Vil du maksimere delt kode og nå begge plattformene raskt med ett team, er det en naturlig vei.

Et konkret eksempel: Har du allerede en native Android-app og et team som kan Kotlin, og vil legge til iOS uten å skrive om logikken, er KMP en elegant måte å gjøre det på. Starter du derimot fra null med webutviklere i teamet, heller det mot React Native.

Hva forskjellen betyr for tid og kostnad

Fordi React Native også deler grensesnittet, er det som regel mindre å bygge for å dekke begge plattformene, og det kan gå raskere når du starter fra null. KMPs native grensesnitt per plattform innebærer mer arbeid i UI-delen, men gir til gjengjeld en helt native følelse og passer særlig godt når du allerede har native kode å bygge videre på.

Poenget er at ingen av modellene er «billigst» i seg selv. Hvilken som blir mest effektiv, avhenger av hvor du starter. Har du allerede native kode og kompetanse, slipper du med KMP å kaste det. Starter du på bar bakke med webnære utviklere, gjør React Native det mulig å dele mer med en gang.

Unngå å velge etter trend

Den vanligste fallgruven er å velge rammeverk etter hva som er mest omtalt akkurat nå, i stedet for etter egen situasjon. KMP får mye oppmerksomhet som utfordrer, men oppmerksomhet er ikke det samme som at det passer din situasjon. Det samme gjelder motsatt vei.

En tryggere måte å tenke på: Ta utgangspunkt i hvilket team og hvilken kodebase du har eller vil bygge opp, og la det avgjøre. Velger du ut fra eksisterende kompetanse og startpunkt, blir byggingen smidigere, og du reduserer risikoen for noen gang å måtte gjøre et kostbart teknologibytte senere.

Slik tenker vi rundt valget

Som med andre valg av rammeverk er holdningen vår at teamet og utgangspunktet veier tyngre enn trenden. Vi tar utgangspunkt i hvor appen skal starte, hvilken kompetanse som finnes og hvor native opplevelsen må være, og anbefaler teknologi ut fra det heller enn ut fra hva som er mest omtalt. Vil du drøfte hvilken tilnærming som passer din situasjon, er du velkommen til å ta kontakt.