React Native eller native: Hvad passer til din app?

Valget mellem React Native og native udvikling er grundlæggende et valg mellem én kodebase og to. Det lyder teknisk, men konsekvenserne er økonomiske: To kodebaser betyder næsten dobbelt så meget udvikling, dobbelt så meget vedligeholdelse og ofte to teams, hvert år appen lever. Her er afvejningen, med omkostninger og risiko i fokus.

Én kodebase i stedet for to

En native satsning betyder at den samme funktion bygges to gange: én gang i Swift til iOS og én gang i Kotlin til Android. To implementeringer skal holdes synkroniserede, testes hver for sig og udgives i takt. Med React Native skrives forretningslogik, brugerflade og flows én gang og kører på begge platforme, med platformens rigtige komponenter i bunden.

Det påvirker mere end udviklingsbudgettet. Ét fælles team arbejder ud fra én backlog i stedet for to, funktioner udgives samtidig på iOS og Android, og fejl rettes ét sted.

Risikoen mindskes også på en mindre åbenlys måde: paritet. Med to kodebaser er det almindeligt at platformene glider fra hinanden. En funktion findes på iOS, men ikke på Android, og en fejl er rettet det ene sted, men ikke det andet. Det giver dobbelt test, dobbelt dokumentation og forvirrede brugere. Med fælles kode er der per definition kun én sandhed.

Besparelsen: typisk 25–40 procent

En almindelig besparelse med en fælles kodebase er 25–40 procent sammenlignet med dobbelt native udvikling. At det ikke bliver 50 procent, skyldes at en del arbejde forbliver platformsspecifikt: udgivelser i butikkerne, noget af testen og enkelte tilpasninger pr. platform.

Et regneeksempel: En mellemkompleks app (konti, egen backend, push og betaling) der ville koste omkring 1,6 mio. DKK at bygge native til begge platforme, lander med React Native ofte på 960.000 DKK–1,2 mio. DKK. Og besparelsen gentager sig efter lanceringen: Vedligeholdelse anslås som regel til 15–25 procent af udviklingsomkostningen om året, så en lavere grundomkostning og én enkelt kodebase giver en lavere årlig omkostning i hele appens levetid.

Når native vinder

React Native er ikke det rigtige svar overalt. Native udvikling er prisen værd når noget af det her er kernen i produktet:

• Tung grafik og animation. Spil, avanceret billedbehandling eller 3D-oplevelser vil tale direkte med platformens grafik-API’er.
• Hardwarenære funktioner. Dyb integration med Bluetooth-protokoller, sensorer i baggrunden, AR eller specialiseret periferiudstyr bliver ofte enklere og mere stabil fuldt native.
• Platformsspecifik UX. Skal appen føles som en forlængelse af styresystemet, med hver eneste platformskonvention gengivet perfekt, giver to native kodebaser mest kontrol.
• Ekstreme krav til ydeevne. Lyd i realtid, videopipelines og lignende nicher måler latens i millisekunder og tåler ingen mellemlag.

Kan du ikke genkende din app på listen, er det et stærkt tegn på at den fælles kodebase er det rigtige udgangspunkt.

Native-moduler: mellemvejen de fleste glemmer

Valget er sjældent binært. React Native har en indbygget ventil: native-moduler. Kræver en enkelt funktion platformskode (et SDK til en betalingsterminal, en usædvanlig sensor, en ydeevnekritisk beregning), skrives netop den del i Swift og Kotlin og kobles ind i den fælles app.

For budgettet betyder det at et særligt behov bliver en afgrænset post på måske nogle ugers arbejde, i stedet for et argument for at fordoble hele projektet. I praksis afgøres valget derfor af hvor appens tyngdepunkt ligger: Består den af flows, lister og formularer med et enkelt særtilfælde eller to, er React Native med moduler det rigtige. Består den af særtilfælde, er native det rigtige.

Sådan vælger du

Tre kontrolspørgsmål rækker langt: Skal appen ud på både iOS og Android? Er kernefunktionen noget en almindelig forretningsapp gør, eller noget fra listen hvor native vinder? Hvordan ser jeres bemanding ud på lang sigt, ét team eller to? For de fleste forretningsapps peger svarene i samme retning, og når de ikke gør, er en kort teknisk forundersøgelse billigere end et forkert valg.

Vi hos Weapp bygger apps i React Native netop fordi regnestykket som regel ender dér for produktvirksomheder, men anbefaler native når produktet kræver det. Fortæl om din app via kontaktsiden eller læs mere om vores ydelser, så får du en ærlig vurdering før du lægger dig fast på teknologien.