Cross-platform vs. native app: det strategiske valg
Cross-platform betyder én kodebase til både iOS og Android og bliver over tre år som regel klart billigere end to native kodebaser, som kræver dobbelt udvikling og dobbelt vedligeholdelse. Native kan begrundes med ekstreme krav til ydeevne, hardwarenære funktioner eller store teams med platformspecialister. For de fleste produktvirksomheder er cross-platform i dag standardvalget.
Før spørgsmålet “React Native eller Flutter?” kommer et vigtigere: Skal I overhovedet bygge med en fælles kodebase, eller skal I satse på native udvikling pr. platform? Det er et strategisk valg der styrer budget, teamstruktur og releasetempo i flere år. Her er beslutningsgrundlaget, uden teknologireligion.
Hvad valget egentlig handler om
Native udvikling betyder to parallelle apps: én i Swift til iOS og én i Kotlin til Android. Hver funktion bygges to gange, testes to gange og vedligeholdes to gange. Cross-platform betyder én kodebase der kører på begge platforme, med platformspecifik kode kun der hvor det virkelig er nødvendigt.
Valget handler altså mindre om hvad der er teknisk muligt (begge veje kan bygge næsten alt) og mere om hvad hver funktion skal koste at bygge og eje.
Totalomkostning over tre år
Udviklingsomkostningen er kun den første post. Vedligeholdelse anslås typisk til 15–25 procent af udviklingsomkostningen om året, og det er dér to kodebaser for alvor bliver dyre. Et regneeksempel for en app af middel kompleksitet:
| Post | Én kodebase (cross-platform) | To kodebaser (native) |
|---|---|---|
| Udvikling år 1 | ca. 1,1 mio. DKK | ca. 1,6–1,8 mio. DKK |
| Vedligeholdelse år 2 | ca. 160.000–270.000 DKK | ca. 270.000–430.000 DKK |
| Vedligeholdelse år 3 | ca. 160.000–270.000 DKK | ca. 270.000–430.000 DKK |
| I alt over tre år | ca. 1,4–1,6 mio. DKK | ca. 2,1–2,7 mio. DKK |
Tallene er et illustrativt eksempel, og hvert projekt har sit eget regnestykke, men strukturen holder: Forskellen vokser med tiden fordi hvert års vedligeholdelse og hver ny funktion betales én gang i stedet for to.
To poster ses ikke i tabellen, men de forstærker mønstret. Releases: Med én kodebase når hver ny funktion begge platforme samtidig, og med to kræves der koordinering for ikke at komme ud af takt. Og alternativomkostningen: De timer der går med at bygge det samme to gange, kunne have bygget den næste funktion. For en produktvirksomhed i konkurrence er den post ofte større end selve prisforskellen.
Beslutningsmatrix: målgruppe, funktionskrav, team
| Jeres situation | Rimeligt udgangspunkt |
|---|---|
| Forretningsapp: flows, lister, konti, betaling | Cross-platform |
| Begge platforme fra dag ét, begrænset budget | Cross-platform |
| Spil, tung grafik eller realtidsmedier | Native |
| Dyb hardwareintegration som kernefunktion | Native, eller cross-platform med native-moduler |
| Stor organisation med etablerede iOS- og Android-teams | Native kan være det rigtige at beholde |
| Lille team der også har ansvaret for web | Cross-platform, gerne React Native |
Matrixen er et udgangspunkt, ikke en dom. Grænsetilfælde afgøres bedst af et kort teknisk forprojekt hvor de tungeste funktionskrav testes mod hver af de to veje før hele budgettet låses.
Tre myter der ikke længere holder i 2026
“Cross-platform føles ikke native.” Det passede for hybridapps der kørte i en indlejret browser for ti år siden. Moderne frameworks bruger platformens rigtige komponenter (React Native) eller renderer med høj præcision (Flutter). En velbygget cross-platform-app kan ikke udpeges i en blindtest af almindelige forretningsapps.
“Ydeevnen rækker ikke.” For lister, formularer, kort, video og betalingsflows har ydeevnen længe været et ikke-problem. Frameworkenes nye arkitekturer har desuden gjort vejen mellem fælles kode og platform kortere. De tilfælde hvor ydeevnen faktisk er afgørende (spil, realtidslyd, tung billedbehandling), er reelle men få, og de er nemme at identificere på forhånd.
“Man ender alligevel i platformkode, så gevinsten forsvinder.” De fleste forretningsapps har brug for lidt eller slet ingen platformspecifik kode. Når behovet opstår, løses det med et afgrænset native-modul (nogle ugers arbejde) mens resten af appen forbliver fælles. Undtagelsen bekræfter modellen snarere end at vælte den.
Sådan lander du beslutningen
Start i produktet, ikke i teknologien: List de fem vigtigste funktioner, og spørg om nogen af dem kræver noget som kun platformene selv kan. Hvis ikke (og det er det almindelige), er en fælles kodebase det økonomisk rationelle udgangspunkt, og det næste spørgsmål bliver hvilket framework og hvilket team. Hos Weapp bygger vi apps i React Native og hjælper gerne med den vurdering før I låser jer fast. Læs om vores ydelser eller kontakt os for en uforpligtende gennemgang.
Ofte stillede spørgsmål
Hvad betyder cross-platform?
At appen bygges i et framework hvor en fælles kodebase kører på både iOS og Android, i stedet for at den udvikles separat pr. platform. De to dominerende frameworks i 2026 er React Native, der bygger på JavaScript og React, og Flutter, der bygger på Dart.
Har native apps højere kvalitet?
Ikke i sig selv. Kvaliteten afgøres af teamet, kravene og vedligeholdelsen, ikke af kategorien. En velbygget cross-platform-app slår en sjusket udviklet native app alle ugens dage. Native giver mest kontrol i tekniske ekstremtilfælde, og det er noget andet end generelt højere kvalitet.
Kan vi kombinere cross-platform og native kode?
Ja. Moderne cross-platform-frameworks har native-moduler: afgrænsede dele i Swift eller Kotlin til funktioner der kræver platformkode. Appen forbliver fælles mens specialtilfældene løses med native kode. Det er en mellemvej der dækker de fleste praktiske behov.
Betyder valget noget for brugerne?
Sjældent direkte. En veludført app føles god uanset kategori. Indirekte mærker brugerne forskel på releasetempoet: Med én kodebase får iOS- og Android-brugere nye funktioner samtidig, hvor to kodebaser let kommer ud af takt.
Hvad koster det at vedligeholde appen efter lanceringen?
En almindelig tommelfingerregel er 15–25 procent af udviklingsomkostningen om året, uanset teknologivalg. Forskellen ligger i grundlaget: To native kodebaser giver en højere udviklingsomkostning og dermed en højere årlig vedligeholdelse. Begge spor skal følge med ved hver OS-release.