Native, hybrid eller webapp: hva passer bedriften?

Mobil apputvikling koker ned til tre valg: native, hybrid eller webapp. Ordene høres tekniske ut, men forskjellen er enkel nok. Den handler om hvor appen kjører, hvor nær telefonen den får komme, og hvor mye den koster å holde i live etterpå.

De fleste som tar kontakt sier bare "app". Så viser det seg i løpet av samtalen at de beskriver tre ganske ulike ting. Noen trenger noe som ligger i Google Play. Noen trenger et verktøy de ansatte åpner i nettleseren. Noen trenger ingen av delene, bare en bedre nettside.

Her går jeg gjennom hva de tre faktisk er, hva de koster å eie og hvilke funksjoner som avgjør valget. Jeg setter ingen kroner på det her, for det har jeg skrevet om i hva det koster å lage en app. Dette handler om noe annet: hva du får, og hva du gir fra deg.

Hva betyr native, hybrid og webapp?

En native app er bygget med plattformens egne verktøy. For Android betyr det Kotlin og Android sin egen verktøykasse. Appen installeres fra Google Play og har direkte tilgang til kamera, sensorer, varsler, lagring og alt annet telefonen kan. Den er også raskest, rett og slett fordi ingenting ligger imellom. Dette er native Android-apper, og det er dem jeg bygger.

Hybrid er en samlebetegnelse, og det er verdt å vite at den dekker to ganske ulike ting. Den ene varianten, som Flutter og React Native, skrives én gang og kjøres på begge plattformer, og grensesnittet tegnes nær native. Den andre varianten pakker rett og slett en nettside inn i et app-skall. Begge kalles hybrid i salgsmøter. Kvaliteten er ikke i nærheten av den samme.

En webapp er en nettside som oppfører seg som en app. Den åpnes i nettleseren, krever ingen nedlasting og er oppdatert i samme øyeblikk som du publiserer. Brukeren kan legge den på hjemskjermen, og da får den eget ikon og ser ut som alt annet på telefonen. Den ligger ikke i noen butikk, og det er både fordelen og begrensningen.

• Native: bor på telefonen, full tilgang til maskinvaren, publiseres i butikk.
• Hybrid med eget rammeverk: én kodebase for flere plattformer, raskere i gang, flere kompromisser.
• Webapp: ingen nedlasting, ingen butikk, oppdateres med én utrulling.
• Innpakket nettside: ser ut som en app, men er en nettside i et skall. Butikkene liker det dårlig.

Hva koster de tre, og hva koster de etterpå?

Byggekostnaden er bare halve regnestykket. Den andre halvparten er hva løsningen koster å eie. I en webapp kan du rette en feil om morgenen og ha den ute før lunsj. En app i butikk må bygges, lastes opp, gjennom kontroll, og så må brukeren faktisk installere oppdateringen. Rettelsen er den samme. Veien ut er ikke det.

Hybrid blir ofte solgt som den billige snarveien, og av og til stemmer det. Men du bytter ikke egentlig bort kostnad, du bytter bort kontroll. Du blir avhengig av et rammeverk som må følge med når Android endrer seg, og av tillegg som andre vedlikeholder. Når noe knirker, ligger feilen gjerne i laget du ikke eier. Det er helt greit å leve med, så lenge du vet at du har valgt det.

Fire ting som faktisk avgjør valget

Skreller vi bort teknologipraten, står det igjen fire spørsmål. Svarer du ærlig på dem, har du som regel svaret før vi har tegnet en eneste skjerm.

1. Varsler. Skal du nå kunden på telefonen uten å betale for annonser? Native gjør det best. En webapp kan sende varsler på Android, men på iPhone må brukeren først legge siden til på hjemskjermen, og i praksis faller de fleste av der.
2. Offline. Skal løsningen virke i en kjeller, i en bil eller på en byggeplass uten dekning? Native håndterer det ryddigst. En webapp kan mellomlagre en del, men du bør ikke bygge en arbeidsdag som er avhengig av det.
3. Kamera og sensorer. Å ta et bilde går fint i nettleseren. Skal du skanne strekkoder i tempo, lese NFC, bruke fingeravtrykk eller gjøre noe mens appen ligger i bakgrunnen, er du utenfor nettleserens komfortsone.
4. Betaling. Her blir det raskt regelstyrt. Selger du digitalt innhold inne i appen, må du bruke butikkens betalingsløsning, og butikken tar sin andel. Selger du en time, en vare eller en tjeneste som leveres utenfor appen, gjelder andre regler. Ta den samtalen før du velger plattform, ikke etter.

Legg merke til at ingen av de fire spørsmålene handler om hvor moderne noe ser ut. De handler om hva løsningen skal få lov til å gjøre på telefonen. Det er den grensen som styrer prisen, ikke designet.

Når webappen er riktig, og appen er feil

Det hender ofte at kunden beskriver en app, og at det riktige svaret er noe annet. Et internt verktøy der ansatte fører timer, sjekker lager eller fyller ut skjema trenger sjelden å ligge i Google Play. Det trenger å virke på mobil, på nettbrett og på maskinen inne på kontoret. Da er det egentlig et skreddersydd system du er ute etter, ikke en app.

Så finnes det en tredje variant: kunden trenger verken app eller webapp, bare en nettside som er rask og god å bruke på mobil. Den vurderingen har jeg skrevet mer om i app, nettside eller begge. Kort sagt henter en app folk tilbake, mens en nettside gjør at de finner deg i det hele tatt.

Hva Google Play og App Store krever

Å publisere er ikke bare å trykke opp. Begge butikkene har en kontroll før appen slippes ut, og begge krever en utviklerkonto. Google Play krever et engangsgebyr for kontoen, Apple krever en avgift som fornyes årlig. I tillegg må du ha personvernerklæring, en beskrivelse av hvilke data appen samler inn, og skjermbilder som viser hva appen faktisk gjør.

Så kommer det som overrasker flest: butikkene krever at du holder appen oppdatert. Google hever jevnlig kravet til hvilken Android-versjon appen må bygges mot, og apper som ikke følger med blir mindre synlige for nye brukere. Butikkene er heller ikke glade i apper som bare er en nettside i et skall. Gjør appen ingenting en nettside ikke kunne gjort, risikerer du å bli avvist i kontrollen.

Slik velger jeg sammen med kunden

Jeg bygger native for Android. Det er et bevisst valg, ikke en begrensning jeg prøver å pakke pent inn. Én plattform gjort skikkelig slår to plattformer gjort halvveis, særlig for en liten bedrift som skal eie koden etterpå. Vil du se hvordan jeg jobber med apputvikling, ligger hele løpet beskrevet steg for steg.

Samtalen starter alltid samme sted: hva skal brukeren gjøre, hvor ofte, og hva må telefonen klare for at det skal fungere. Peker svaret mot varsler, offline eller maskinvare, snakker vi om en native app for Android. Peker det ikke dit, sier jeg det, selv når det betyr et mindre prosjekt. Å bygge feil type løsning er dyrere enn å bygge ingenting.