Teknologivalget er det første store valget i et appprosjekt, og det er vanskelig å gjøre om senere. Det avgjør ikke bare hva appen koster å bygge, men hva den koster å eie i årene etterpå, og hvor raskt dere kan endre den når dere lærer noe nytt om brukerne.
Samtidig er valget mindre dramatisk enn diskusjonene rundt det kan gi inntrykk av. For de aller fleste forretningsapper finnes det ett riktig svar, og det er ikke det dyreste.
Hva som egentlig skiller alternativene
En native app er skrevet spesielt for én plattform, i Swift for iOS og Kotlin for Android. Koden snakker direkte med operativsystemet, og alt telefonen kan gjøre er tilgjengelig med én gang det lanseres. Prisen for det er at du bygger to apper. Hver funksjon spesifiseres én gang, men implementeres, testes og vedlikeholdes to ganger, hver eneste gang den endres.
Kryssplattform betyr at du skriver appen én gang og kjører den begge steder. React Native er det vi bruker, og det er i dag et modent valg som brukes av svært store aktører. Grensesnittet tegnes med ekte native komponenter, så resultatet er ikke en nettside i forkledning. Trenger du noe plattformspesifikt, kan du fortsatt skrive akkurat den delen native og la resten være felles.
En webapp er ikke en app i det hele tatt, men en nettside bygget for å oppleves som en. Den bor i nettleseren, kan legges til på hjemskjermen, og oppdateres i det øyeblikket du publiserer. Du slipper app-butikkene helt, både godkjenningen og ventetiden.
Hva dette betyr for kostnaden
Forskjellen mellom native og kryssplattform er ikke at det ene er litt dyrere. Det er at arbeidsmengden er nær dobbel gjennom hele produktets levetid.
Første versjon koster typisk 60 til 80 prosent mer med to native kodebaser enn med én felles. Men det er vedlikeholdet som gjør størst utslag over tid. Hver feilretting, hver justering etter brukertilbakemeldinger, og hver tilpasning til nye operativsystemversjoner må gjøres to steder. Over tre år er det der forskjellen samler seg opp.
En webapp er som regel rimeligst, både fordi det er én løsning og fordi du slipper app-butikkenes prosesser. Du kan lese mer om hva de ulike alternativene koster i priskalkulatoren.
Når native faktisk er nødvendig
Det finnes reelle grunner til å velge native, og de er greie å kjenne igjen.
Apper som behandler lyd eller video i sanntid, tunge spill med egen grafikkmotor, og løsninger som kjører avansert bildebehandling eller maskinlæring direkte på enheten, drar konkret nytte av å ligge så nær maskinvaren som mulig. Det samme gjelder apper som er dypt integrert i økosystemet, med klokkeapp, widgets, låseskjermaktiviteter og lignende.
En annen god grunn er hvis appen din er avhengig av en helt ny plattformfunksjon fra dag én. Native gir deg tilgang umiddelbart, mens kryssplattform ofte venter på at rammeverket tar den inn.
Hvis ingen av disse beskriver prosjektet ditt, er native sannsynligvis å betale dobbelt for noe brukerne ikke merker.
Når webapp er det smarteste valget
Webapp blir ofte avfeid for tidlig, og det er synd, fordi den løser en del oppgaver bedre enn en app gjør.
Skal løsningen brukes av ansatte i arbeidstiden, på maskiner de allerede sitter ved, er det lite som taler for å tvinge dem innom App Store. Det samme gjelder verktøy som først og fremst handler om å se på data, fylle ut skjemaer og behandle saker. Administrasjonsgrensesnitt bygges nesten alltid som webapp, også når hovedproduktet er en mobilapp.
Webapp er også riktig når du trenger å endre ting ofte. Du publiserer når du vil, alle får den nye versjonen umiddelbart, og du slipper å vente på Apples vurdering.
Begrensningene er verdt å kjenne til. Push-varsler fungerer ujevnt, særlig på iOS. Tilgangen til maskinvare er begrenset sammenlignet med en app. Og du er ikke synlig i app-butikkene, noe som betyr noe hvis folk skal finne deg der.
Spørsmålene som avgjør i praksis
Når vi hjelper kunder med dette valget, er det som regel fire spørsmål som bestemmer utfallet.
Trenger appen noe telefonen kan som en nettleser ikke kan? Push-varsler som må være pålitelige, kamera brukt aktivt, posisjon i bakgrunnen, offline-bruk. Hvis svaret er nei, vurder webapp først.
Hvem er brukerne, og hvor er de? Folk ute i felt med dårlig dekning trenger en app som fungerer uten nett. Folk på kontoret gjør ikke det.
Hvor ofte skal løsningen endres? Ukentlige endringer taler for web. Et stabilt produkt som oppdateres noen ganger i året taler for app.
Og til slutt: hva skal dere leve med? En kodebase krever ett team og ett sett rutiner. To native kodebaser krever kompetanse på begge plattformer, i mange år framover.
Du kan gjøre begge deler
Det vanligste oppsettet vi bygger er ikke enten eller. Det er en mobilapp i React Native for brukerne, en webapplikasjon for administrasjon og saksbehandling, og en felles backend som betjener begge.
Da bruker du hver teknologi til det den er god til, uten å betale for mer enn du trenger. Kundene får appen der den gir verdi, og dere slipper å bygge et tungvint administrasjonsgrensesnitt på en telefonskjerm.
Hvordan velge uten å gjette
Det mest nyttige rådet er å ikke ta valget i et vakuum. Beskriv først hva appen skal gjøre for én bruker fra start til slutt, og la teknologien følge av det. En prototype gjør denne samtalen konkret, fordi det er lettere å se hva som faktisk kreves når dere klikker gjennom løsningen sammen.
Er du usikker, er kryssplattform det trygge utgangspunktet for en mobilapp, og webapp det trygge utgangspunktet for et internt verktøy. Begge kan utvides senere, og begge er langt enklere å komme ut av enn to native kodebaser.
Vil du diskutere hva som passer for deres prosjekt? Se hvordan vi jobber med apputvikling og webapplikasjoner, eller ta kontakt for en uforpliktende vurdering.