Hvad koster en React Native-app?
En React Native-app koster i 2026 oftest mellem 430.000 DKK og 2,7 mio. DKK afhængigt af omfanget. Den fælles kodebase til iOS og Android sparer typisk 25–40 procent i forhold til dobbelt native udvikling. Besparelsen skrumper når appen kræver mange native moduler, ekstrem ydeevne eller meget platformsspecifikt design.
React Native er i dag den mest udbredte måde at bygge en app til både iOS og Android på uden at betale for to separate udviklingsspor. Prismæssigt lander de fleste React Native-projekter mellem 430.000 DKK og 2,7 mio. DKK, og hvor i spændet I ender, afgøres af omfanget, ikke af frameworket. Her er prisniveauet og logikken bag det.
Prisspænd pr. niveau
| Niveau | Typisk pris | Eksempel |
|---|---|---|
| Simplere app | 430.000–740.000 DKK | Login, nogle få skærmbilleder, indhold fra et eksisterende API |
| Mellemkompleks app | 740.000 DKK–1,5 mio. DKK | Egen backend, push-notifikationer, betaling, flere roller |
| Avanceret app | 1,5–2,7 mio. DKK | Realtidsdata, integrationer med ERP-systemer, høje sikkerhedskrav |
Spændene forudsætter begge platforme: Det er jo hele pointen med React Native. Hos et bureau ligger timeprisen normalt på 960–1.500 DKK. Det der adskiller niveauerne i tabellen, er antallet af timer.
Hvor i spændet et projekt lander, styres af de samme faktorer som for apps i almindelighed: backendens omfang, antallet af integrationer, designambitionen og kravene til sikkerhed. React Native ændrer ikke de faktorer. Det ændrer hvor mange gange I betaler for dem.
Derfor sænker en fælles kodebase prisen
I et native setup bygges hver funktion to gange: én gang i Swift til iOS og én gang i Kotlin til Android. Med React Native skrives brugerflade og forretningslogik én gang og kører på begge platforme. Den typiske besparelse bliver 25–40 procent i forhold til dobbelt native udvikling.
Hvorfor ikke 50 procent? Fordi en del af arbejdet forbliver dobbelt: releases i butikkerne, test på hver platform og enkelte tilpasninger pr. styresystem. Men besparelsen stopper ikke ved udviklingen: Den gentager sig hvert år. Vedligeholdelse anslås normalt til 15–25 procent af udviklingsomkostningen om året, og med én kodebase er både grundbeløbet lavere og arbejdet enklere: én opdatering i stedet for to når Apple og Google udgiver deres årlige OS-versioner.
Et regneeksempel
Forestil jer en booking-app med konti, kalender, MobilePay-betaling og push-notifikationer til både iOS og Android. Bygget som to native apps: i størrelsesordenen 1,5–1,7 mio. DKK. Bygget i React Native: ofte 960.000 DKK–1,2 mio. DKK. De samme funktioner, de samme butikker, én kodebase.
Læg dertil drift og vedligeholdelse. Med tommelfingerreglen på 15–25 procent om året giver den native variant en årlig udgift på omkring 220.000–430.000 DKK mens React Native-appen lander på omkring 144.000–292.000 DKK. Over tre år vokser den samlede forskel til flere hundredtusinde DKK, penge der kan gå til nye funktioner i stedet for til parallelt dobbeltarbejde.
Når React Native ikke sparer penge
Ærlig varedeklaration: Der findes projekter hvor besparelsen skrumper eller forsvinder.
- Mange native moduler. Enkelte platformsspecifikke funktioner løses billigt med native moduler, men hvis halvdelen af appen består af specialtilfælde (usædvanlige sensorer, tunge SDK’er, dybe integrationer med styresystemet), bliver meget alligevel bygget to gange.
- Ekstreme krav til ydeevne. Spil, lyd i realtid og avanceret billedbehandling har brug for at tale direkte med platformen. Her er native det rigtige fra starten.
- Meget platformsspecifik UI. Skal iOS- og Android-versionerne bevidst se forskellige ud og følge hver sin designfilosofi i detaljen, forsvinder gevinsten ved en fælles brugerflade.
Kan I genkende jeres app her, er der ikke noget galt med React Native. Det er det forkerte værktøj til opgaven, og en seriøs leverandør siger det før tilbuddet bliver skrevet.
Sådan får du et præcist tilbud
Prisen styres af omfanget, så det bedste du kan gøre, er at fastlægge det: hvilke flows der indgår i version et, hvilke integrationer der kræves, og hvad der kan vente. Et kort forprojekt eller en gennemgang af kravene betaler sig næsten altid i form af færre overraskelser.
Et godt grundlag indeholder tre ting: en liste over flows i prioriteret rækkefølge, en ærlig beskrivelse af de eksisterende systemer appen skal tale med, og en afklaring af hvem der har ansvaret for henholdsvis design og indhold. Med det kan en leverandør give et spænd der holder. Uden det får I enten luft i prisen eller ekstraregninger.
React Native er vores primære stack til app-udvikling hos Weapp, så vi giver gerne et konkret prisspænd for netop din idé. Læs om vores ydelser eller kontakt os med en kort beskrivelse.
Ofte stillede spørgsmål
Hvorfor er React Native billigere end native udvikling?
Fordi iOS- og Android-appen deler én kodebase i stedet for at blive bygget som to separate projekter i henholdsvis Swift og Kotlin. Funktioner bygges, testes og vedligeholdes én gang. Besparelsen bliver typisk 25–40 procent, ikke 50: Releases i butikkerne og en vis platformstilpasning skal stadig laves pr. platform.
Bliver appen dårligere end en native app?
For almindelige forretningsapps: nej. React Native bruger platformens rigtige UI-komponenter, så appen føles hjemme på både iPhone og Android. Ekstreme krav til grafik, realtid eller hardwarenære funktioner kan dog stadig tale for native udvikling.
Hvilke omkostninger kommer oveni udviklingen?
Konti til butikkerne (Apple Developer 99 USD/år, Google Play 25 USD i engangsgebyr), drift af backend og tredjepartstjenester samt løbende drift og vedligeholdelse. En almindelig tommelfingerregel er 15–25 procent af udviklingsomkostningen om året. Bed altid om at tilbuddet specificerer hvad der er inkluderet.
Hvor lang tid tager det at bygge en React Native-app?
En simplere app tager ofte 2–3 måneder, en mellemkompleks 3–6 måneder fra start til release i butikkerne. Tidsplanen styres af de samme faktorer som prisen: backend, integrationer og hvor klare kravene er når udviklingen går i gang.
Passer React Native også til en app på kun én platform?
Ja, det kan det, især hvis den anden platform kan blive aktuel senere, eller hvis teamet allerede kan React. Skal appen derimod med sikkerhed kun leve på én platform og desuden ligge tæt på hardwaren, kan native udvikling være lige så fornuftig.