Hva koster en React Native-app?
En React Native-app koster oftest mellom 500 000 kr og 3,1 millioner kr i 2026, avhengig av omfanget. Den felles kodebasen for iOS og Android sparer typisk 25–40 prosent sammenlignet med dobbel native utvikling. Besparelsen krymper når appen krever mange native-moduler, ekstrem ytelse eller mye plattformspesifikk design.
React Native er i dag den vanligste måten å bygge en app for både iOS og Android på uten å betale for to separate utviklingsløp. Prismessig lander de fleste React Native-prosjekter mellom 500 000 kr og 3,1 millioner kr, og hvor i spennet dere havner, avgjøres av omfanget, ikke av rammeverket. Her er prisnivået og logikken bak det.
Prisspenn per nivå
| Nivå | Typisk kostnad | Eksempel |
|---|---|---|
| Enkel app | 500 000–870 000 kr | Innlogging, noen få skjermbilder, innhold fra et eksisterende API |
| Middels kompleks app | 870 000 kr–1,7 millioner kr | Egen backend, pushvarsler, betaling, flere roller |
| Avansert app | 1,7–3,1 millioner kr | Sanntidsdata, integrasjoner mot ERP-system, høye sikkerhetskrav |
Spennene forutsetter begge plattformene. Det er selve poenget med React Native. Timeprisen hos byråer ligger vanligvis på 1 100–1 700 kr; det som skiller nivåene, er antall timer.
Hvor i spennet et prosjekt lander, styres av de samme faktorene som for apper generelt: omfanget av backend, antall integrasjoner, designambisjonene og kravene til sikkerhet. React Native endrer ikke disse faktorene. Rammeverket endrer hvor mange ganger dere betaler for dem.
Derfor gir en felles kodebase lavere pris
I et native oppsett bygges hver funksjon to ganger: én gang i Swift for iOS og én gang i Kotlin for Android. Med React Native skrives grensesnitt og forretningslogikk én gang og kjøres på begge plattformene. Den typiske besparelsen blir 25–40 prosent sammenlignet med dobbel native utvikling.
Hvorfor ikke 50 prosent? Fordi en del arbeid fortsatt må gjøres to ganger: publisering i appbutikkene, testing per plattform og enkelte tilpasninger per operativsystem. Men besparelsen stopper ikke ved utviklingen. Den gjentar seg hvert år. Vedlikehold anslås gjerne til 15–25 prosent av utviklingskostnaden per år, og med én kodebase er både grunnlaget lavere og arbeidet enklere: én oppdatering i stedet for to når Apple og Google lanserer sine årlige OS-versjoner.
Et regneeksempel
Tenk dere en bookingapp med kontoer, kalender, Vipps-betaling og pushvarsler for både iOS og Android. Bygget som to native apper havner den i størrelsesorden 1,7–2 millioner kr. Bygget i React Native koster den ofte 1,1–1,4 millioner kr. Samme funksjoner, samme appbutikker, én kodebase.
I tillegg kommer forvaltningen. Med tommelfingerregelen på 15–25 prosent per år gir den native varianten en årlig kostnad på rundt 260 000–500 000 kr, mens React Native-appen lander på rundt 168 000–342 000 kr. Over tre år vokser den samlede forskjellen til flere hundre tusen kroner, penger som kan gå til nye funksjoner i stedet for til parallelt dobbeltarbeid.
Når React Native ikke sparer penger
En ærlig varedeklarasjon: Det finnes prosjekter der besparelsen krymper eller forsvinner.
- Mange native-moduler. Enkelte plattformspesifikke funksjoner løses billig med native-moduler, men hvis halve appen består av spesialtilfeller (uvanlige sensorer, tunge SDK-er, dype OS-integrasjoner), bygges mye likevel to ganger.
- Ekstreme ytelseskrav. Spill, sanntidslyd og avansert bildebehandling må snakke direkte med plattformen. Der er native riktig fra starten.
- Svært plattformspesifikt brukergrensesnitt. Skal iOS- og Android-versjonene bevisst se forskjellige ut og følge hver sin designfilosofi i detalj, forsvinner gevinsten med et delt grensesnitt.
Ligner dette på appen dere planlegger, er det ikke noe galt med React Native. Det er feil verktøy for oppgaven, og en seriøs leverandør sier fra før tilbudet skrives.
Slik får du et treffsikkert tilbud
Prisen styres av omfanget, så det beste du kan gjøre, er å spikre det: hvilke brukerreiser som inngår i versjon én, hvilke integrasjoner som kreves og hva som kan vente. En kort forstudie eller kravgjennomgang lønner seg nesten alltid i form av færre overraskelser.
Et godt grunnlag inneholder tre ting: en liste over brukerreiser i prioritert rekkefølge, en ærlig beskrivelse av de eksisterende systemene appen skal snakke med og beskjed om hvem som har ansvaret for henholdsvis design og innhold. Med det kan en leverandør gi et prisspenn som holder. Uten det får dere enten luft i prisen eller tilleggsfakturaer.
React Native er hovedstacken vår for apputvikling i Weapp, så vi gir gjerne et konkret prisspenn for akkurat din idé. Les om tjenestene våre eller ta kontakt med en kort beskrivelse.
Ofte stilte spørsmål
Hvorfor er React Native billigere enn native utvikling?
Fordi iOS- og Android-appen deler én kodebase i stedet for å bygges som to separate prosjekter i henholdsvis Swift og Kotlin. Funksjoner bygges, testes og vedlikeholdes én gang. Besparelsen blir typisk 25–40 prosent, ikke 50. Årsaken er at publisering i appbutikkene og en del plattformtilpasning fortsatt må gjøres per plattform.
Blir appen dårligere enn en native app?
For vanlige forretningsapper: nei. React Native bruker plattformens egne UI-komponenter, så appen føles naturlig på både iPhone og Android. Ekstreme krav til grafikk, sanntid eller maskinvarenære funksjoner kan likevel gjøre native utvikling berettiget.
Hvilke kostnader kommer i tillegg til utviklingen?
Kontoer i appbutikkene (Apple Developer 99 USD/år, Google Play 25 USD i engangsavgift), drift av backend og tredjepartstjenester, samt løpende forvaltning. En vanlig tommelfingerregel er 15–25 prosent av utviklingskostnaden per år. Be alltid om at tilbudet spesifiserer hva som er inkludert.
Hvor lang tid tar det å bygge en React Native-app?
En enkel app tar ofte 2–3 måneder, en middels kompleks 3–6 måneder fra oppstart til lansering i appbutikkene. Tidsplanen styres av de samme faktorene som prisen: backend, integrasjoner og hvor tydelige kravene er når utviklingen starter.
Passer React Native også for en app til bare én plattform?
Ja, det kan det gjøre, særlig hvis den andre plattformen kan bli aktuell senere, eller hvis teamet allerede kan React. Skal appen derimot garantert bare finnes på én plattform og i tillegg ligge tett på maskinvaren, kan native utvikling være like fornuftig.