Native eller React Native: vad ska ni välja?

Vad skillnaden är

Native betyder att appen byggs med plattformens egna verktyg: Swift och SwiftUI för iPhone, Kotlin och Jetpack Compose för Android. Två plattformar betyder två kodbaser, och oftast två utvecklare eller team.

React Native är ett ramverk där appen skrivs i TypeScript och ritas med plattformens riktiga komponenter. Det är alltså inte en webbsida i ett skal. En och samma kodbas ger en app för iPhone och en för Android. Med Expo blir bygge, test och publicering enklare. När något behöver skrivas i Swift eller Kotlin, till exempel en specialfunktion i hårdvaran, går det att lägga till som en egen modul.

Jämförelsetabell

Prestanda: när märks skillnaden?

I en typisk företagsapp, med inloggning, listor, formulär, bokning, betalning, kartor och push-notiser, märker användaren ingen skillnad. Den moderna arkitekturen i React Native har dessutom gjort kommunikationen mellan JavaScript och telefonen snabbare än tidigare.

Skillnaden märks i:

• Spel och appar med avancerade animationer i hög bildfrekvens.
• Förstärkt verklighet (AR) och 3D.
• Bild- och videobearbetning direkt i telefonen.
• Appar som ständigt kommunicerar med hårdvara via Bluetooth, till exempel mätinstrument, där tidskraven är hårda.

Även där kan React Native användas med native-moduler för de krävande delarna, men då minskar kostnadsfördelen.

Kostnad och tid

Den största skillnaden för en företagare är ekonomisk. Med React Native byggs varje funktion en gång. Exempel: en mellanstor app som i native skulle byggas två gånger kan med React Native landa 30–40 % lägre totalt, eftersom logik, design och de flesta skärmar delas. Det är ett räkneexempel; den faktiska skillnaden beror på hur mycket plattformsspecifik kod appen kräver.

Tidsmässigt gäller samma sak. En MVP på 6–10 veckor är realistisk med React Native för båda plattformarna; med native krävs antingen längre tid eller två utvecklare parallellt. Räkna på er app i priskalkylatorn.

Underhåll över tid

Båda alternativen behöver underhåll. Apple och Google släpper nya OS-versioner varje år och butikerna höjer sina krav.

• React Native: en kodbas att uppdatera, men ramverket och biblioteken behöver hållas aktuella. Uppdateringar av React Native-versionen kan kräva arbete.
• Native: inga externa ramverk mellan appen och plattformen, men varje ändring görs två gånger och testas på två plattformar.

För de flesta blir React Native billigare även i underhåll, eftersom en ändring görs på ett ställe. Underhåll Bas kostar 2 900 kr/mån och gäller oavsett teknikval.

Vanliga missförstånd

• "React Native är en webbsida i en app." Nej. Det är andra tekniker som visar en webbsida i ett skal. React Native ritar plattformens riktiga knappar, listor och textfält.
• "Native är alltid snabbare, så det är alltid bättre." I en app där användaren bokar en tid eller fyller i en rapport är skillnaden inte märkbar. Det som avgör upplevelsen är oftare hur snabbt servern svarar och hur väl flödet är designat.
• "Med React Native kommer vi inte åt kameran eller Bluetooth." Jo, via färdiga bibliotek eller egna moduler i Swift och Kotlin.
• "En kodbas betyder att appen ser likadan ut överallt." Det går att låta appen följa respektive plattforms mönster där det behövs, till exempel bakåtnavigering och datumväljare.

Exempel: tre appar och ett troligt val

Exemplen är hypotetiska och visar hur resonemanget går, inte ett facit. Det rätta valet beror på detaljerna i förstudien.

Kompetens och byte av leverantör

TypeScript, som används i React Native, är ett av de mest spridda språken bland utvecklare, vilket gör det lättare att hitta någon som kan ta över koden. Native kräver kompetens i två språk och två verktygskedjor. Oavsett val ska källkoden ligga i ert namn och vara dokumenterad, så att ni inte är bundna till en leverantör.

Vad som påverkar ett byte senare

Ett teknikval är inte för evigt, men det är dyrt att ändra. Att gå från React Native till native betyder i praktiken att appen skrivs om, medan backend, design och kravspecifikation kan återanvändas. Därför lönar det sig att lägga en timme extra i förstudien på frågan: vilka funktioner kan bli aktuella om två år, och kräver någon av dem native?

Så väljer ni

Välj React Native om:

• appen ska finnas på både iPhone och Android,
• funktionerna är typiska för företagsappar: konton, bokning, betalning, listor, kartor, push,
• budget och tid till lansering väger tungt.

Välj native om:

• appen bara ska finnas på en plattform, till exempel en intern app där alla har iPhone,
• appen kräver tung grafik, AR eller hårda tidskrav mot hårdvara,
• ni behöver plattformens nyaste funktioner samma dag de släpps.

Är ni osäkra är förstudien rätt ställe att avgöra frågan. Vi bygger i båda: se React Native-appar, iOS-appar och Android-appar. Behöver appen inte finnas i butikerna alls, läs app eller webbapp.