Native eller plattformsoberoende app?
Av CodexierPublicerad 5 min läsning
Native betyder att iPhone-appen skrivs i Apples verktyg och Android-appen i Googles, var för sig. Plattformsoberoende betyder en kodbas som ger båda. Avvägningen är inte kvalitet mot bekvämlighet, som den var för tio år sedan; moderna plattformsoberoende ramverk ger appar de flesta användare inte kan skilja från native. Avvägningen i dag handlar om en kort lista tekniska behov, och den listan får du här.
Vad native egentligen ger
- Omedelbar tillgång till varje nytt plattforms-API, utan att vänta på att ett ramverk ska stödja det.
- De sista procenten renderingsprestanda för krävande 3D, spel eller videoeffekter.
- Djup integration med plattformsspecifika funktioner som widgetar, klockappar, CarPlay eller Android Auto.
- Ett team som redan behärskar Swift eller Kotlin och ska underhålla appen i flera år.
Lägg märke till vad som inte står på listan: att se native ut, kännas snabb, klara granskningen i butikerna, pushnotiser, offlinestöd, biometri eller säker lagring. Plattformsoberoende ramverk hanterar allt det via det native lagret.
Vad plattformsoberoende ger
Ramverk som React Native, Flutter och Capacitor delar en kodbas mellan iOS och Android, och i Capacitors fall även webben. Mekanismen skiljer sig: React Native och Flutter ritar gränssnittet själva eller via native komponenter, Capacitor paketerar en webbapp i ett native skal med bryggor till enhetens funktioner. Alla tre levererar native binärer via samma appbutiker.
Ett team, en release
En funktion byggs en gång och släpps i båda butikerna samma vecka. Buggar rättas på ett ställe. Teamet kan vara mindre och behöver inte två specialister.
Native där det spelar roll
Kamera, BankID, push, kartor och betalningar nås via native moduler. Saknas något fyller ett litet native tillägg luckan utan att appen skrivs om.
Återanvändning av webben
Särskilt med Capacitor kan en befintlig webbprodukt bli en app med logiken intakt. Det är ofta den snabbaste vägen för ett företag som redan har en kundportal.
Den ärliga nackdelen är beroendet av ramverkets releasecykel och av tredjepartstillägg. Ett ramverk eller tillägg som hamnar efter en OS-uppdatering kan blockera er release tills det är rättat, vilket är ett skäl till att underhåll är en egen post och inte en eftertanke; se underhåll och skalning av appar.
Kostnad och tidsplan jämförda
| Faktor | Helt native, två appar | Plattformsoberoende, en kodbas |
|---|---|---|
| Byggarbete för samma funktioner | Nära det dubbla | Ett bygge plus test per plattform |
| Tid till båda butikerna | Längre, eller en plattform först | Båda samtidigt |
| Löpande underhåll | Två kodbaser, två uppsättningar OS-uppdateringar | En kodbas, ramverksuppdateringar ovanpå |
| Team | iOS- och Android-specialister | Ett team, ofta med webbkompetens |
| Toppresterande | Bästa möjliga | Omöjlig att skilja för företagsappar, efter vid tung grafik |
| Risk | Funktionerna glider isär mellan apparna | Ramverk eller tillägg släpar efter OS-släpp |
Våra fasta priser för den plattformsoberoende vägen finns på prissidan. Det som driver kostnaden inom båda vägarna är detsamma: skärmar, integrationer, offlinebehov och inloggning.
Kostnadsgapet krymper för mycket små appar, där butiksuppsättning, design och backend dominerar, och växer med varje funktion ni lägger till, eftersom varje funktion byggs två gånger på den native vägen.
Funktioner som kräver native kod
Även i en plattformsoberoende app skrivs vissa funktioner native som små moduler. Det är normalt och driver er inte mot en helt native app. Skillnaden som spelar roll är om native kod är undantaget eller hela produkten:
- Fungerar fint som native modul i en plattformsoberoende app: BankID, egna kameraflöden, Bluetooth-enheter, positionering i bakgrunden, specialiserad betalhårdvara.
- Driver mot helt native: video- eller ljudeffekter i realtid, 3D-rendering, AR, spel, allt där bildfrekvensen är produkten.
- Kontrollera före beslut: finns ett underhållet tillägg för varje hårdvarufunktion ni behöver? Ja för alla: plattformsoberoende. Saknas det för en kärnfunktion och skulle den utgöra det mesta av appen: native.
En checklista för beslutet
- Lista funktionerna. Markera de som är grafik, video, ljudbehandling eller AR. Inga markerade: plattformsoberoende.
- Lista enhetsfunktionerna. Bekräfta att ett underhållet tillägg finns för var och en. Alla finns: plattformsoberoende.
- Fråga vem som underhåller appen om tre år. Inga native specialister anställda: plattformsoberoende.
- Fråga om en webbversion önskas. Ja: plattformsoberoende, sannolikt Capacitor eller en delad kodbas.
- Fråga om appen måste släppas dag ett med varje ny OS-funktion. Ja, och det är centralt för produkten: native.
När ni inte behöver en app alls: är jobbet att läsa information och fylla i formulär gör en snabb mobil webbplats eller en progressiv webbapp ofta jobbet utan butiksgranskning eller underhåll, och det säger vi hellre än bygger något ni inte kommer att uppdatera. Pekar er checklista på native säger vi det, och då är vi inte rätt leverantör för det bygget. Pekar den på plattformsoberoende kommer valet av ramverk härnäst, som vi tar upp i React Native eller Flutter, och ett kort samtal med er funktionslista avgör båda.
Vanliga frågor
Känns plattformsoberoende appar långsammare eller mindre polerade?
Inte för företagsappar. Listor, formulär, kartor, betalningar och notiser körs via native komponenter eller optimerad rendering, och användarna märker ingen skillnad. Gapet syns bara vid krävande grafik eller realtidsmedia, där native fortfarande har övertaget.
Kan en plattformsoberoende app använda BankID?
Ja. BankID-integration görs via det vanliga app-växlingsflödet och native moduler som alla stora ramverk stöder. Det är ett vanligt krav i svenska appar och driver er inte mot ett helt native bygge.
Är det billigare att bygga för bara en plattform?
Det är billigare än två native appar, men inte billigare än en plattformsoberoende app som täcker båda. Att lansera på en plattform först är bara rimligt om era användare nästan helt finns där; i Sverige har både iOS och Android stora andelar, så de flesta företagsappar behöver båda från start.
Osäker på om din app kräver native kod?
Skicka oss din funktionslista före ett samtal på femton minuter. Vi säger om plattformsoberoende täcker den, vilket ramverk som passar och vad det fasta priset skulle bli, eller om ni bör leta efter ett native team i stället.
Boka ett kostnadsfritt 15-minuterssamtal