React Native eller native: Hva passer appen din?

Valget mellom React Native og native utvikling er i bunn og grunn et valg mellom én kodebase og to. Det høres teknisk ut, men konsekvensene er økonomiske: To kodebaser betyr nesten dobbelt utviklingsarbeid, dobbelt vedlikehold og ofte doble team, hvert år appen lever. Her er avveiingen, med kostnad og risiko i fokus.

Én kodebase i stedet for to

En native satsing innebærer at den samme funksjonen bygges to ganger: én gang i Swift for iOS og én gang i Kotlin for Android. To implementasjoner skal holdes synkronisert, testes hver for seg og slippes i takt. Med React Native skrives forretningslogikk, grensesnitt og brukerflyter én gang og kjøres på begge plattformene, med plattformens ekte komponenter i bunnen.

Det påvirker mer enn utviklingsbudsjettet. Ett felles team jobber mot én backlog i stedet for to, funksjoner slippes samtidig på iOS og Android, og feil rettes på ett sted.

Risikoen reduseres også på en mindre åpenbar måte: paritet. Med to kodebaser er det vanlig at plattformene glir fra hverandre. En funksjon finnes på iOS, men ikke på Android, eller en feil er rettet på det ene stedet, men ikke på det andre. Det gir dobbel testing, dobbel dokumentasjon og forvirrede brukere. Med felles kode finnes det per definisjon bare én sannhet.

Besparelsen: typisk 25–40 prosent

En vanlig besparelse med felles kodebase er 25–40 prosent sammenlignet med dobbel native utvikling. At det ikke blir 50 prosent, skyldes at en del arbeid forblir plattformspesifikt: publisering i appbutikkene, noe testing og enkelte tilpasninger per plattform.

Et regneeksempel: En middels kompleks app med kontoer, egen backend, push og betaling, som ville kostet rundt 1,9 millioner kr å bygge native for begge plattformene, havner med React Native ofte på 1,1–1,4 millioner. Og besparelsen gjentar seg etter lansering: Vedlikehold anslås gjerne til 15–25 prosent av utviklingskostnaden per år, så en lavere grunnkostnad og én enkelt kodebase gir lavere årskostnad gjennom hele appens levetid.

Når native vinner

React Native er ikke riktig svar overalt. Native utvikling er verdt prisen når noe av dette er kjernen i produktet:

• Tung grafikk og animasjon. Spill, avansert bildebehandling eller 3D-opplevelser må kunne snakke direkte med plattformens grafikk-API-er.
• Maskinvarenære funksjoner. Dyp integrasjon med Bluetooth-protokoller, bakgrunnssensorer, AR eller spesialisert periferiutstyr blir ofte enklere og mer stabil med ren native utvikling.
• Plattformspesifikk UX. Skal appen føles som en forlengelse av operativsystemet, med hver plattformkonvensjon perfekt gjengitt, gir to native kodebaser mest kontroll.
• Ekstreme ytelseskrav. Sanntidslyd, videopipelines og lignende nisjer måler forsinkelse i millisekunder og tåler ingen mellomlag.

Kjenner du ikke igjen appen din i listen, er det et sterkt tegn på at den felles kodebasen er riktig utgangspunkt.

Native-moduler: mellomveien de fleste glemmer

Valget er sjelden binært. React Native har en innebygd ventil: native-moduler. Krever en enkelt funksjon plattformkode, for eksempel et SDK for en betalingsterminal, en uvanlig sensor eller en ytelseskritisk beregning, skrives akkurat den delen i Swift og Kotlin og kobles inn i den delte appen.

For budsjettet betyr det at et spesialbehov blir en avgrenset post på kanskje noen ukers arbeid, i stedet for et argument for å doble hele prosjektet. I praksis avgjøres valget derfor av hvor tyngdepunktet i appen ligger. Består den av brukerflyter, lister og skjemaer med et og annet spesialtilfelle, er React Native med moduler riktig. Består den av spesialtilfeller, er native riktig.

Slik velger du

Tre kontrollspørsmål kommer du langt med: Skal appen ut på både iOS og Android? Er kjernefunksjonen noe en vanlig forretningsapp gjør, eller noe fra listen der native vinner? Hvordan ser den langsiktige bemanningen deres ut, ett team eller to? For de fleste forretningsapper peker svarene i samme retning, og når de ikke gjør det, er en kort teknisk forstudie billigere enn et feilvalg.

Vi i Weapp bygger apper i React Native nettopp fordi regnestykket for de fleste produktselskaper ender der, men vi anbefaler native når produktet krever det. Fortell om appen din via kontaktsiden, eller les mer om tjenestene våre, så får du en ærlig vurdering før du låser teknologien.