Kort svar
Ska appen byggas native eller i React Native?
För de allra flesta affärsappar är React Native rätt val: en kodbas som täcker både iOS och Android, i praktiken likvärdig prestanda och 30–40 procent lägre kostnad än två separata native-appar.
Native i Swift och Kotlin är rätt när appen bygger på tung grafik, realtidsbildbehandling eller hårdvara som kräver nya system-API:er samma dag de släpps.
Frågan är inte vilken teknik som är bäst
Native och cross-platform beskrivs ofta som två läger. I praktiken är valet en avvägning mellan hur mycket kod som kan delas och hur nära hårdvaran appen behöver komma. För de flesta affärsappar är svaret en delad kodbas. För ett fåtal är det native. Här är hur vi resonerar.
De tre alternativen
Native — Swift och Kotlin
Två separata appar skrivna i respektive plattforms eget språk. Ger full tillgång till allt systemet erbjuder samma dag som det släpps, och högsta möjliga prestanda. Kostar i gengäld två kodbaser att bygga, testa och underhålla.
React Native och Expo
En kodbas i TypeScript som renderar riktiga native-komponenter på båda plattformarna. Det är inte en webbsida i en ram — knappar, listor och navigation är plattformens egna. Behövs native-kod för en enskild funktion skriver vi en modul för just den.
Webbapp eller PWA
Billigast, men kan inte publiceras i butikerna på samma villkor, har begränsad tillgång till notiser på iOS och saknar den känsla av app som användare förväntar sig. Ibland rätt svar, ofta ett dyrt omtag ett år senare.
Jämförelse
| Native | React Native | |
|---|---|---|
| Kostnad för två plattformar | Högst — två kodbaser | 30–40 procent lägre |
| Prestanda i vanliga appar | Mycket bra | I praktiken likvärdig |
| Tung grafik och spel | Bäst | Sämre lämpad |
| Nya OS-funktioner | Tillgängliga direkt | Ofta några månaders fördröjning |
| Snabba rättningar | Kräver ny granskning | Kan skickas direkt via Expo-uppdatering |
| Underhåll över tid | Dubbelt arbete | Ett projekt att hålla uppdaterat |
Välj native när
- Appen är ett spel eller bygger på tung 3D- eller bildbehandling i realtid.
- Appen behöver djup integration mot hårdvara, till exempel egna Bluetooth-protokoll.
- Ni bara ska lansera på en plattform och inte planerar den andra.
- Appen måste stödja nya OS-funktioner samma dag de släpps.
Välj React Native när
- Appen ska finnas på både iPhone och Android.
- Innehållet är data, formulär, listor, kartor, chatt eller bokning — alltså de flesta affärsappar.
- Ni vill kunna rätta buggar snabbt utan att vänta på granskning.
- Budgeten ska räcka till fler funktioner snarare än till två parallella kodbaser.
Vår standard är React Native med Expo, och vi skriver native-moduler där det behövs. Läs mer om hur vi arbetar med React Native och Expo.
Vad valet betyder för priset
Två native-appar innebär i praktiken två projekt. Delad kodbas ger vanligtvis 30–40 procent lägre totalkostnad för samma funktionalitet, och skillnaden växer över tid eftersom underhållet också halveras. Hur prisnivåerna ser ut i övrigt går vi igenom i guiden om vad det kostar att utveckla en app.
Backend är ett eget val
Oavsett hur appen byggs behöver den oftast en backend för konton, data och notiser. Vi använder normalt Supabase — databas, inloggning, filer och realtid i ett — eller kopplar mot ett API ni redan har. Att välja en färdig plattform i stället för att bygga allt själv är oftast den enskilt största besparingen i ett appprojekt.
Osäker på vad som passar er? Läs om iOS-apputveckling och Android-apputveckling, eller hör av dig så resonerar vi tillsammans.