React Native eller nativt: vad ska din app byggas i?

Ska appen byggas i React Native — en kodbas som blir app för både iPhone och Android — eller som två separata nativa appar? Det är den vanligaste tekniska vägvalsfrågan vid appbeställning, och den påverkar budget, tidplan, teamstorlek och din frihet som beställare i flera år framåt. Här är beslutsunderlaget, utan religionskrig.

Vad alternativen betyder

Nativ utveckling innebär att appen skrivs i respektive plattforms eget språk och verktyg — Swift för iOS, Kotlin för Android. Två appar, två kodbaser, ofta två kompetensspår i teamet.

React Native innebär att appen skrivs en gång i TypeScript/JavaScript och körs på båda plattformarna med nativa gränssnittskomponenter. En kodbas, ett team — med möjlighet att skriva enstaka delar nativt där det behövs.

Kostnaden över appens livstid — inte bara bygget

Prisskillnaden vid nybygge är välkänd: en gemensam kodbas kostar som tumregel 60–70 procent av två nativa appar, eftersom det mesta av logik, gränssnitt och testning delas. Men det är efter lanseringen som skillnaden växer.

Eftersom en app typiskt lever 5–10 år och förvaltningen ofta kostar 15–25 procent av utvecklingskostnaden per år, är det förvaltningsraderna som dominerar totalkalkylen. Varje funktion som byggs två gånger, varje bugg som rättas två gånger — det är dubbelkostnaden som gör att de flesta företagsappar i onödan blir dyrare som nativa.

Fallen där nativt fortfarande vinner

React Native är rätt default för de flesta verksamhets- och konsumentappar — men det finns tydliga undantag där nativ utveckling är värd merkostnaden:

• Tung grafik och avancerade animationer. Spel, 3D-visualisering, videoredigering och AR ställer krav som plattformarnas egna grafikstackar hanterar bäst.
• Hårdvarunära funktioner. Djup integration med Bluetooth-utrustning, sensorer, bakgrundsprocesser eller plattformsspecifika funktioner som ska utnyttjas samma dag de lanseras.
• Extrema prestandakrav. Realtidsbehandling av stora datamängder, millisekundkänsliga flöden.
• Enplattformsappar. Ska appen bara finnas på iOS försvinner huvudargumentet för cross-platform — då är nativt ofta enklast.

Gränsen är inte binär: ett vanligt mönster är React Native som bas med nativa moduler för de enstaka delar som kräver det. Kamerafunktionen kan vara nativ medan resten av appen delar kodbas. Det ger nativ kapacitet där den gör skillnad, utan att dubblera kostnaden för allt det andra — inloggning, listor, formulär och inställningar är desamma oavsett teknik.

Vad valet betyder för team och leverantörsbyten

Två konsekvenser av teknikvalet förbises ofta i beslutet:

Teamstorlek. En React Native-app kan drivas vidare av ett litet team — ibland en enda utvecklare i förvaltningsfasen. Två nativa appar kräver att båda kompetensspåren är bemannade även när utvecklingstakten är låg, vilket gör förvaltningen känsligare för uppsägningar och semestrar.

Framtida leverantörsbyten. JavaScript/TypeScript-utvecklare är en av världens största utvecklargrupper, och React Native-kompetens finns hos många svenska byråer och frilansare. Behöver du byta leverantör om tre år är marknaden stor. Nischade teknikval — åt båda hållen — krymper din förhandlingsposition. Be alltid leverantören motivera sitt teknikval utifrån din app, inte utifrån vad de råkar ha på bänken.

Så landar du beslutet

Lista dina fem viktigaste funktioner och fråga: kräver någon av dem tung grafik, hårdvarunära åtkomst eller extrem prestanda? Om nej — vilket gäller de flesta appar med flöden, formulär, listor och kartor — är en gemensam kodbas det ekonomiskt rationella valet över livstiden. Om ja, låt just de funktionerna styra mot nativt eller mot en hybridarkitektur.

Vi på Weapp bygger appar både i React Native och nativt för iOS/Android, och rekommenderar teknik efter appens behov — hör av dig om du vill ha en second opinion på teknikvalet, eller se våra tjänster för hur vi arbetar.