React Native eller Kotlin Multiplatform?

Kotlin Multiplatform er på kort tid gået fra kuriositet til et reelt alternativ, og i 2026 vurderer flere og flere native-teams det over for det etablerede React Native. De to løser det samme grundproblem, nemlig at slippe for at bygge alt to gange, men med forskellig filosofi. Her er forskellen set fra kundens side.

To modeller for at dele kode

Den afgørende forskel ligger i hvor meget der deles mellem iOS og Android.

React Native deler i princippet alt. Både appens logik og dens brugerflade skrives én gang, i JavaScript, og kører på begge platforme. Det giver maksimal genbrug: én kodebase, ét team, to apps.

Kotlin Multiplatform, KMP, deler kun den fælles logik: beregninger, regler og måden appen taler med serveren på. Selve brugerfladen bygges native til hver platform, altså separat til iOS og Android. Du deler hjernen, men bygger ansigtet to gange.

Det lyder som mere arbejde med KMP, og i brugerfladedelen er det også sådan. Gevinsten er at brugerfladen bliver helt native, med hver platforms præcise fornemmelse, samtidig med at du slipper for at skrive logikken to gange.

Modenhed i økosystem og værktøjer

Økosystemet har betydning for hvor gnidningsfrit udviklingen forløber fordi det afgør hvor meget der allerede findes færdigt til genbrug.

React Native har altså et forspring i bredden af færdige komponenter, hvilket kan gøre almindelige app-behov hurtigere at løse. KMP er stabilt og bruges i produkter i drift, men har et smallere udvalg af færdige dele. Afstanden bliver mindre år for år, men den er der.

Hvilket team vælger hvad

Den mest praktiske måde at vælge på er at se på hvilket team du har eller vil have.

KMP passer ofte til eksisterende native-teams. Et team der allerede bygger native, især med Kotlin på Android-siden, kan indføre KMP for at dele logikken uden at forlade sin native verden. Teamet bevarer den native fornemmelse i brugerfladen og slipper samtidig for dobbeltarbejde i logikken.

React Native passer ofte til teams tæt på web. Udviklere med baggrund i JavaScript og web kommer hurtigt ind i React Native. Vil du have så meget delt kode som muligt og hurtigt nå begge platforme med ét team, er det en naturlig vej.

Et konkret eksempel: Har du allerede en native Android-app og et team der kan Kotlin, og vil du tilføje iOS uden at omskrive logikken, er KMP en elegant måde at gøre det på. Starter du derimod fra bunden med webudviklere i teamet, hælder det mod React Native.

Hvad forskellen betyder for tid og omkostninger

Fordi React Native også deler brugerfladen, er der som regel mindre at bygge for at dække begge platforme, og det kan gå hurtigere når du starter fra bunden. KMP’s native brugerflade pr. platform betyder mere arbejde i UI-delen, men giver til gengæld en helt native fornemmelse og passer særlig godt når du allerede har native kode at bygge videre på.

Pointen er at ingen af modellerne er “billigst” i sig selv. Hvad der bliver mest effektivt, afhænger af hvor du starter. Har du allerede native kode og kompetencer, sparer KMP dig for at smide det væk. Starter du på bar mark med udviklere tæt på web, gør React Native at mere kan deles med det samme.

Undgå at vælge efter trends

Den mest almindelige faldgrube er at vælge framework efter hvad der er mest omtalt lige nu, i stedet for ud fra dine egne forhold. KMP får meget opmærksomhed som udfordrer, men opmærksomhed er ikke det samme som at det passer til din situation. Det samme gælder den anden vej.

En mere sikker måde at tænke på: Tag udgangspunkt i hvilket team og hvilken kodebase du har eller vil opbygge, og lad det afgøre valget. Vælger du ud fra eksisterende kompetencer og dit startpunkt, forløber udviklingen mere gnidningsfrit, og du mindsker risikoen for nogensinde at skulle foretage et dyrt teknologiskifte senere.

Sådan tænker vi om valget

Ligesom ved andre valg af framework er vores holdning at teamet og udgangspunktet vejer tungere end trenden. Vi ser på hvor appen skal starte, hvilke kompetencer der findes og hvor meget appen skal føles native, og anbefaler teknologi ud fra det snarere end ud fra hvad der er mest omtalt. Vil du vende hvilken tilgang der passer til din situation, er du velkommen til at kontakte os.