Native, cross-platform eller webb? Så väljer du plattform för mobilen

”Ska vi bygga native eller cross-platform?” är nästan alltid den första frågan, och den kommer nästan alltid för tidigt. Svaret beror på tre saker som inte handlar om teknik: om appen måste ligga i en butik, vad den behöver från telefonen, och vem som ska ta hand om den om tre år.

Fråga ett: måste appen ligga i en butik?

Ett vanligt skäl till att bygga app är att någon vill ha en ikon på hemskärmen. Det får du utan app. En webbapp kan läggas på hemskärmen och öppnas utan webbläsarens ramar. Bygger du för det fungerar den offline. Och när den ligger på hemskärmen kan den skicka notiser, även på iPhone från iOS 16.4, om användaren tillåter det.

Butiken är rätt svar när du behöver något av det här:

• Synlighet. Folk söker efter appar i butiken, och för en konsumenttjänst är det en kanal du annars inte har.
• Bakgrundskörning. Positionering, bluetooth eller synkning som ska fungera när appen inte är öppen. Webben har svagt stöd för det, och även en butiksapp får bara göra det inom de ramar operativsystemet sätter.
• Styrd utrullning. Ska appen bara ut till personalens telefoner finns egna vägar för det hos både Apple och Google. Vilken som passar beror på vem som äger telefonerna och hur du vill begränsa åtkomsten.

Väljer du butiken följer villkoren med. Säljer du digitalt innehåll inne i appen kräver butikerna i många fall att du använder deras betalning, med den avgift det innebär. Reglerna skiljer sig mellan marknader och har ändrats flera gånger, så kontrollera vad som gäller för dig. Är svaret nej på alla tre är det värt att stanna upp: en webbapp slipper granskning, släpps när du vill och har ingen butikspolicy som kan ändras under fötterna på dig.

Fråga två: vad behöver appen från telefonen?

Det här är det som styr valet mellan native och cross-platform. Prestanda är den debatt som brukar föras, men för de flesta appar som visar data och formulär räcker moderna cross-platform-ramverk. Har du spel eller tung realtidsgrafik är det en annan diskussion. Det som betyder mest är hur djupt ned i plattformen du behöver:

• Vanliga funktioner. Kamera, kartor, notiser, filer och biometrisk upplåsning har färdiga bibliotek i de stora ramverken.
• Funktioner som ofta kräver egen kod. Bluetooth, NFC, bakgrundspositionering och kontinuerlig synkning går, men räkna med att skriva plattformsspecifik kod. Då behöver du någon som kan läsa både Swift och Kotlin.
• Funktioner nära operativsystemet. Realtidsanalys av kameraströmmen, hårdvarunära ljud och video, widgets och annan systemintegration. Där blir ramverket ett extra lager mellan dig och plattformen, och native är ofta enklare. Prototypa den riskabla delen innan du bestämmer dig.

Tumregeln är enkel: ju mer av appen som ändå måste skrivas per plattform, desto mindre sparar du på cross-platform. Vid någon punkt har du kvar komplexiteten utan vinsten. Var den punkten ligger beror på appen, så räkna på det innan du väljer.

De tre vägarna

Cross-platform

En kodbas, två butiker. Passar de flesta verksamhetsappar och de konsumentappar som i grunden visar data, låter användaren fylla i saker och synkar. Den största vinsten är att samma team kan bygga och underhålla båda versionerna. Priset är ett extra lager att felsöka i, och att du följer ramverkets uppgraderingstakt i stället för din egen.

Native

Två kodbaser, en per plattform. Du kommer åt allt plattformen erbjuder, inom de gränser operativsystemet sätter, och du behöver inte vänta på att ett ramverk ska hinna ikapp. Rätt när appen behöver mycket plattformsspecifik kod. Räkna då med att underhålla två kodbaser. Fel när appen är ett komplement till ett webbsystem och budgeten egentligen bara räcker till en.

Webb

Snabbast att ändra, inget släpp att vänta in, samma kod för alla. Rätt för verksamhetsstöd, för det mesta som används sittande, och för att ta reda på om appen behövs innan du bygger den. Begränsningarna sitter i bakgrundskörning och i vissa funktioner i telefonen. Stödet skiljer sig mellan webbläsare, så kontrollera det du behöver innan du lovar något.

Att bygga appen är den första kostnaden. Att hålla den installerbar år efter år är den som fortsätter.

Underhållet du måste räkna med

En app som redan är installerad fortsätter oftast att fungera. Men för att den ska gå att uppdatera, och för att nya användare ska kunna ladda ner den, finns det arbete som kommer oavsett om du ändrar något i produkten:

• Butikerna kräver nya SDK-versioner. Apple och Google höjer med jämna mellanrum kravet på vilken version du bygger mot. Missar du ett sådant datum kan du inte skicka in nya versioner förrän du uppgraderat.
• Certifikat och profiler behöver underhållas. Går de ut kan du inte släppa. Vad som händer med redan installerade appar beror på hur de distribueras: via butiken fortsätter de fungera, men appar som delats ut på andra sätt kan sluta starta.
• Butikspolicyn ändras. Nya regler gäller från nästa gång du skickar in, och ibland även för appar som redan ligger ute.
• Ramverket rör sig. Cross-platform-ramverken släpper ofta nya versioner, och gamla versioner slutar få stöd. Att ligga långt efter gör nästa uppgradering dyrare.

Ta med det underhållet i den första kalkylen. Hur mycket det blir beror på appens beroenden och plattformar, men noll blir det aldrig. Annars står du med en hög uppgraderingar att göra den dag du behöver släppa något viktigt.

Så brukar vi svara

1. Behöver appen varken butiken eller djup tillgång till telefonen: bygg webb.
2. Behöver den butiken men är i grunden ett gränssnitt mot ett system du redan har: cross-platform. Kolla först hur mycket plattformsspecifik kod som behövs.
3. Behöver den mycket plattformsspecifik kod, eller sitter värdet i hårdvaran: native. Planera för att underhålla båda versionerna.
4. Vet du inte: bygg webben först, om den klarar det du vill testa. Servern och API:et kan du oftast behålla om du bygger en app senare.

Omfattas tjänsten av tillgänglighetskraven följer de med in i appen, oavsett väg. Och det är billigare att bygga in dem från början än att rätta i efterhand.

Vi bygger både apparna och systemen de pratar med. Så jobbar vi med systemutveckling. Ska appen logga in användare? Läs om BankID-flödena. Läs också om vad en automatisk tillgänglighetsskanning missar. Samma tänk gäller i en app.