Native, React Native eller PWA: hvilken type app bør du velge?

Det tradisjonelle valget har endret seg

For noen år siden var spørsmålet enkelt: "Skal vi bygge native eller hybrid?" Native ble ofte sett som det "ekte" valget, og hybrid som et kompromiss for de som ikke hadde råd.

Det stemmer ikke lenger.

I dag er React Native med Expo så modent at det gir samme følelse, samme ytelse, og samme funksjonalitet som native for de aller fleste B2B- og forbruker-apper. Vi bygger ca 90 prosent av appene våre i React Native og bruker native (Swift, Kotlin) bevisst der det er det rette valget, sjelden av nostalgi.

Her er hvordan vi tenker når kunder spør oss om hva som passer dem.

De tre alternativene i dag

React Native med Expo (default for de fleste)

Én kodebase som kjører på både iOS og Android. Native komponenter under panseret, ikke en webview, så følelsen er ekte native. Expo-pakken legger til en moderne utviklerflyt, automatiske oppdateringer, og dekker 95 prosent av plattform-funksjonene rett ut av boksen.

Når det passer best:

• B2B-apper for ansatte eller fagpersonell
• Forbruker-apper med standard funksjonalitet (innlogging, lister, skjemaer, varslinger)
• Apper som skal lanseres på iOS og Android samtidig
• MVP-er som skal valideres raskt og potensielt skaleres
• Apper som trenger jevnlige oppdateringer (Expo OTA-oppdateringer går rundt App Store-køen)

Når det ikke passer:

• Tung 3D-grafikk eller spillmotor-prosesser
• Direkte integrasjon med firmware eller spesiell maskinvare
• Krav om minimal start-tid eller minne-bruk

Native: Swift på iOS, Kotlin på Android

To kodebaser, én per plattform. Maksimal kontroll over hver plattform-funksjon, ingen ekstra abstraksjonslag, og direkte tilgang til alt OS-en tilbyr.

Når det passer best:

• Apper som snakker med spesiell maskinvare via Bluetooth, NFC eller USB
• Apper som styrer firmware eller IoT-enheter
• Medisinsk utstyr eller industriell prosesskontroll der ytelse og forutsigbarhet er kritisk
• BankID-app-integrasjon (sterke push-varsler med signering)
• Spillmotor-baserte apper eller tunge animasjons-prosesser
• Apper som krever spesielle plattform-funksjoner som ennå ikke har god React Native-støtte (Apple Vision Pro, CarPlay, Android Auto)

Når det ikke passer:

• Standard B2B-apper med vanlige skjermbilder og innlogging
• Apper som primært består av lister, skjemaer og rapporter
• Budsjetter som ikke har plass til både iOS- og Android-utviklere

PWA, app som kjører i nettleseren

En progressive web app er en webside som oppfører seg som en app: kan installeres på hjemskjermen, virker offline, sender push-varsler, og kjører i eget vindu uten nettleser-elementer.

Når det passer best:

• Interne verktøy for ansatte der dere vil slippe App Store-friksjon
• Pasient- eller borgerportaler som skal nå alle uten installasjon
• Apper som trenger raske oppdateringer (deploy = oppdatering, ingen App Store-godkjenning)
• Begrenset budsjett der dere må velge ett alternativ over to plattformer

Når det ikke passer:

• Apper som krever BankID-app for signering med push-varsel
• Apper som trenger avansert kamera, NFC eller bakgrunnsoppdatering
• Apper som skal være synlige i App Store eller Google Play

Konkret eksempel: hva ville vi anbefalt?

En pasient-app for et helseforetak

Pasienter skal kunne booke timer, se sin egen journal, kommunisere sikkert med behandler, og motta påminnelser.

Vår anbefaling: React Native med Expo, eventuelt kombinert med PWA for de som ikke vil laste ned en app.

Hvorfor: standard B2B-funksjonalitet, ingen spesielle maskinvarekrav, krever god ytelse på både iOS og Android. BankID-redirect-flow fungerer godt, BankID-app integreres via universal links uten å kreve native kode. To kodebaser ville doblet vedlikeholdet uten gevinst.

En operativ app for industrielt vedlikeholds-personell

Vedlikeholdsteknikere bruker appen til å lese av sensorer via Bluetooth, sjekklister på utstyr, og rapportere feil.

Vår anbefaling: Native (Kotlin på Android, eventuelt Swift på iOS hvis nødvendig).

Hvorfor: Bluetooth Low Energy-integrasjon krever direkte plattform-kontroll. Pålitelig bakgrunnskjøring og batteri-effektivitet er kritisk. Brukerne har ofte robuste Android-enheter, så ofte er Android alene tilstrekkelig.

En app for en kommunal etat med saksbehandlings-fokus

Saksbehandlere skal kunne se saker, oppdatere status, ta bilder av befaringer, og signere dokumenter.

Vår anbefaling: PWA eller React Native, avhengig av om saksbehandlerne har personlige enheter eller dedikerte jobbtelefoner.

Hvorfor: PWA dropper App Store-friksjon, oppdateringer ruller ut sentralt. Hvis BankID-signering er nødvendig som push-varsel, går vi over til React Native. Native gir ikke ekstra verdi her.

En forbruker-app for å styre smart-hjem-enheter

Brukere skal styre lys, varme, og sensorer i hjemmet, både fra app og når de er borte.

Vår anbefaling: React Native med Expo, eventuelt native moduler for spesielle protokoll-integrasjoner.

Hvorfor: standard skjermbilder og brukerflyt for det meste, men noen ganger trengs det native moduler for spesielle radio-protokoller (Zigbee, Z-Wave, Matter). React Native gir flexibilitet til å skrive native der det trengs, uten å bygge hele appen native.

Hva som ikke lenger er gyldige argumenter

Mye av det folk har hørt om native vs hybrid stemmer ikke i 2026:

"Native gir bedre ytelse." Bare for spesifikke tilfeller. For standard B2B-apper med lister, skjemaer og innlogging, er forskjellen ikke merkbar. React Native bruker native UI-komponenter, ikke webview.

"Hybrid-apper føles billige." Det stemmer for de gamle webview-baserte hybridene (Cordova, Ionic). React Native er ikke det. Vi har levert React Native-apper som brukere mener er native, og bevisene er på App Store og Google Play.

"Native gir tilgang til alle funksjoner." React Native med Expo dekker 95 prosent av plattform-funksjonene rett ut av boksen. For de siste 5 prosentene kan vi skrive native moduler og koble dem på, uten å bygge hele appen native.

"Hybrid sparer 50 prosent av kostnadene." Vi sparer typisk 40–60 prosent på utviklingsfasen, ja, men reelt vinner vi mer langsiktig på vedlikehold. Én kodebase oppdateres én gang, deployes til begge plattformer.

"PWA er ikke ekte apper." PWA-er kan installeres, virke offline, sende push-varsler (også på iOS siden 2023), og kjøres i eget vindu. For mange bruksområder er det funksjonelt likeverdig med en native app, uten App Store-friksjon.

Det viktigste spørsmålet å stille

Når dere vurderer hva slags app dere skal bygge, prøv først å svare på dette:

1. Skal appen snakke direkte med maskinvare, firmware eller spesielle sensorer?
2. Trenger appen App Store-synlighet og branding via Apple eller Google?
3. Er hyppige oppdateringer (en gang i måneden eller oftere) viktig?
4. Hvilke plattformer trenger dere å nå, iOS, Android, eller begge?
5. Hva er budsjett-rammen og tidshorisonten?

Hvis svaret på spørsmål 1 er ja, går dere til native. Hvis svar på 2 er ja og 3 er nei, er React Native trygt. Hvis dere trenger å nå alle uten App Store-friksjon, vurder PWA.

For 90 prosent av appene vi får henvendelser om, ender vi opp med React Native med Expo. Det er ikke et dovent default, det er et resultat av å analysere hva som er rett.

Konkrete tall

Som tommelfingerregel:

• Native (begge plattformer): 1,5x til 2x kostnad av React Native, lengre tid til lansering, høyere løpende vedlikehold
• React Native med Expo: Basisreferansen, én kodebase, jevnt vedlikehold
• PWA: 60–80 prosent av React Native, ingen App Store-publisering, ingen sertifikat-håndtering

Et MVP i React Native for B2B koster typisk 400 000 til 800 000 NOK avhengig av kompleksitet. Samme app native ville lagt på 200–500k og 4–8 ekstra ukers utviklingstid. PWA ville ligget på 250–500k.

Vår tilnærming

Vi diskuterer dette på første møte, basert på hva appen skal gjøre. Vi anbefaler ikke alltid React Native, men vi anbefaler det ofte, fordi det er rett for det meste vi blir spurt om.

Når dere ser etter en utviklingspartner, spør konkret:

• Hvilke konkrete plattformkrav avgjør valget mellom native og React Native?
• Har dere bygget native der det trengs, eller alltid React Native uansett?
• Hvordan håndterer dere overgangen fra React Native til native moduler når det blir nødvendig?

En partner som sier "vi gjør alltid native" eller "vi gjør alltid hybrid" er enten dyr eller har ikke vurdert prosjektet ditt skikkelig. En partner som diskuterer trade-offs konkret er vanligvis riktig.

Snakk med oss om hva slags app dere vurderer, eller les mer om vår tilnærming til apputvikling og PWA.