Hvordan velge riktig app- teknologi?
Native vs. Hybrid vs. Web En guide til hva man bør tenke på når man skal lage en app.
Vi i Shortcut elsker gode brukeropplevelser! Men vi vet at veien fra en idé om en digital tjeneste til et ferdig prosjekt som gir brukerne et smil om munnen kan være lang.
Vi i Shortcut elsker gode brukeropplevelser! Men vi vet at veien fra en idé om en digital tjeneste til et ferdig prosjekt som gir brukerne et smil om munnen kan være lang. Man må komme opp med en strategi, sette opp budsjetter og finne flinke folk som kan hjelpe deg. Man må også ta teknologivalg. Å ta teknologivalg er vanskelig av flere grunner. For å kunne ta gode valg rundt teknologi må man klare å se litt inn i glasskula, både med tanke på tjenesten man skal utvikle og hvordan teknologien vil utvikle seg.
Det er også vanskelig å vite hvem man kan stole på når man spør om råd rundt teknologivalg. Som regel pleier folk å anbefale det rammeverket og det språket de er kjent med, litt uavhengig av brukstilfelle. Vi i Shortcut har jobbet med forskjellig appteknologi i over 13 år. Vi prøver det meste av nye løsninger som kommer ut, nettopp fordi vi vil være pålitelige når folk spør oss om hvilken teknologi man skal bruke.
Før vi kommer inn på spesifikk teknologi må vi starte med dette; Det finnes ikke noe fasit- svar som er riktig for alle! Du må tenke igjennom hva din tjeneste er, hva den skal være og hva den kan bli, og så vurdere ut ifra det.
Hva vil du oppnå?
For å kunne ta et godt teknologivalg må du ha tenkt i gjennom strategien din og ambisjonene. Det første du må vite er om denne første versjonen er for å teste ut et konsept eller om det er noe du er sikker på at du vil ha. Om man kun ønsker å teste ut et konsept kan man vurdere å lansere på én plattform først (iOS, Android eller web), for å se om dette er noe man vil jobbe videre på, eller om man bør skifte retning.
Du må også tenke i gjennom levetiden på appen. Om appen lykkes – hvor viktig vil da appen være? Hvor vondt vil det være om man må skrive appen helt på nytt?
Du må også tenke over hvilke tekniske komponenter du trenger. Hvor kritisk er tilgang til sensorene i telefonen – som GPS, kamera eller noe annet?
Web eller app
Siden appenes inntog i 2008 har det vært mye diskusjon om hva som gjør en app til en skikkelig app, og hvorfor man trenger en app i stedet for, eller i tillegg til, en nettside. Og la oss starte med det – noen ganger holder det med å lage en nettside! Det fine med web- tjenester er at de er tilgjengelig for alle enheter med en nettleser, fra telefoner til kjøleskap. Samtidig er dette også en utfordring, ettersom at man må utvikle noe som fungerer på alle nettlesere og skjermstørrelser.
Det har aldri vært noe diskusjon om hvor det er lettest å skape en god brukeropplevelse. Å utvikle en enkel og forståelig app er lettere enn å utvikle en enkel og forståelig nettside. Innen interaksjonsdesign har man noe man kaller mentale modeller. Ved å bruke en etablert standard (gjerne ganske logisk) når man designer ting, forventer til slutt folk at det skal fungere sånn flere steder. At du ser etter et dørhåndtak på den ene siden, ca. midt på døra, og at du da kan dytte det håndtaket ned, er en slik mental modell. Med digitale produkter har vi det samme. Det er etablerte konvensjoner for blant annet navigering i en app, noe som gjør at man fort vet hvordan man kan bruke en app, allerede før man har begynt trykke seg rundt. Det er disse mentale modellene som gjør at to-åringer klarer å trykke seg rundt på nettbrett. På web er det ikke et like godt etablert formspråk som kan gjøre det vanskeligere å navigere, spesielt på mobil. I tillegg har man ikke like god kontroll på hvordan ting skal oppføre seg på forskjellige enheter.
Det største problemet folk har hatt med apper er at de faktisk må lastes ned. Dette problemet kan se ut til å forsvinne med hurtigapper. Hurtigapper, kalt App Clips på iOS og Instant Apps på Android, er deler av apper som lastes ned superkjapt. Man får en app- opplevelse like raskt som man kommer inn på en nettside. Man kan også dele disse appene via bla. meldinger, nettsider, QR-koder eller NFC-tagger.
En liten kommentar om PWA
Siden konseptet ble lansert for 5 år siden har Progressive Web Apps (PWA) blitt spilt inn som som et alternativ når man skal velge appteknologi. En PWA er en moderne nettside, og ikke en type app. PWAer har veldig få native egenskaper. De kan få tilgang til noen native funksjoner, som kamera og posisjon, men i det store og hele mangler det meste. Måten man spør om tilgang til native funksjonalitet i en PWA er også utfordrende, om man prøver å skape en god brukeropplevelse. Det som er spikeren i kista for de aller fleste er at PWA-er ikke støtter push-varsler på iOS-enheter.
Native- eller hybrid-app
For å lage iOS- og Android-apper har man en standard måte å lage apper. For å lage native iOS-apper bruker man Xcode, og for native Android-apper bruker man Android Studio. Helt siden de første native utviklingsverktøyene for apper ble lansert, har folk prøvd å lage apper med andre språk og teknologier. Det er to hovedgrunner til at folk har utviklet disse rammeverkene.
- Folk vil ha én kodebase å forholde seg til, i stedet for en på iOS og en på Android.
- Folk vil kode i det språket de kan.
Dette kalles abstraksjoner. Det er teknologi som er utviklet for at man skal slippe å forholde seg til alle detaljene nede i systemet. Dette gjør at man ofte kan komme raskere i gang med disse løsningene, ettersom at de gjør det enkelt å få opp enkle standardkomponenter. React Native (laget av Facebook) og Flutter (laget av Google) er kanskje de mest brukte og kjente eksemplene på denne type rammeverk. Med disse rammeverkene kan man skrive i andre språk (Dart og JavaScript henholdsvis) og få en app som fungerer på både iOS og Android. React Native er spesielt populært blant webutviklere ettersom at man skriver omtrent samme kode som man bruker når man lager nettsider. Man kan også bruke en del av de samme hjelpebibliotekene man bruker i webløsningene sine. En annen fordel med noen disse løsningene er at utviklerne får se appen “live”, mens man koder. Ved tradisjonell native-utvikling må man bygge hele appen for å se hvordan den oppfører seg. Denne “live”- funksjonaliteten kommer nå også til native kode med SwiftUI og Jetpack Compose, som vil effektivisere native utvikling de neste årene.
En utfordring med abstraksjoner (som React Native og Flutter) er at de i seg selv også må vedlikeholdes. Man blir avhengig av at noen følger med og fikser feil fortløpende. Det samme gjelder hjelpebibliotekene man bruker. En utfordring her er at man ved en feil, må starte med å finne ut av om feilen er i utviklerens kode eller rammeverkets kode. Denne type feil dukker oftere opp når det meste er på plass, og man skal prøve å optimalisere appen, og få den til å oppføre seg akkurat sånn som man ønsker at den skal oppføre seg.
Lignende rammeverk dukker opp relativt ofte, med noe forskjellig appell. Noen har lovnader om nye språk (som Ionic), mens andre kan appellere til hvor enkelt det er å begynne å bruke. Disse rammeverkene kommer og går, noe som kan bli et problem om man velger et rammeverk som slutter å bli oppdatert, eller som utviklere slutter å oppdatere seg på.
Native-teknologi i hybrider
Ettersom hybridapper abstraherer bort direkte tilgang til native komponenter, så kan man ikke forvente samme tilgang til funksjonalitet som i en native app. Widgeter, Apple/Google Pay, hurtigapp-funksjonalitet, tilgang til helse-data, Sign in with Apple, Augumented Reality, Machine Learning, beacons, Passes (billetter) og Bluetooth er ting som enten er vanskelig eller umulig å implementere i hybridapper. Man må i så fall ha en forståelse for både native kode og hybrid kode, eller stole på at et bibliotek gjør ting helt riktig og vil bli vedlikeholt.
Når Apple eller Google lanserer ny funksjonalitet vil ikke dette være tilgjengelig i hybridapper før de som vedlikeholder hybridrammeverket implementerer det, eller noen lager noe bibliotek som støtter det.
Hvor native er hybrid?
Forskjellige hybrid-løsninger bruker native teknologi forskjellig. Mens React Native oversetter koden til ekte native komponenter tegner bare Flutter opp noe som ligner. Et tekst-element i React Native skal oppføre seg likt som et tekst-element i en helt native app fordi det er det samme. Samtidig er det elementer i disse løsningene som er ikke lener seg på native kode på samme måte, som navigasjonen.
Det skal bare små ting til før en app skal kjennes litt feil, basert på de mentale modellene man har. Når man utvikler en hybrid-app må man derfor også ha plattform-spesifikk kode, så ting ser og oppfører seg riktig i forhold til hvilken plattform appen kjøres på. Android-apper må ha støtte for tilbake-knappen, og mens iOS apper bruker meny nederst (tab bar), bruker ofte Android-apper menyer på siden.
Det er også forskjell på hvor raske og energieffektive disse hybridløsningene er. Få hybridløsninger er like raske som native kode da de som regel må kjøre rammeverket og den applikasjonsspesifikke koden samtidig. Dette merker man spesielt når man starter opp appen.
Tilgjengelighet
Når man utvikler en digital tjeneste er man pålagt å utvikle den for folk med nedsatt funksjonsevne. En app må derfor være tilgjengelig for både blinde, svaksynte og folk med andre utfordringer. Man er lovpålagt å følge det som heter WCAG-standarden, som setter diverse krav til hvordan tjenesten skal oppføre seg. Forskjellige hybrid-rammeverk støtter dette i forskjellig grad, så om du vurderer å bruke et slikt rammeverk bør du sjekke opp hvor enkelt man støtte ting som endring av skriftstørrelse og opplesning av test.
Kryssplattform
Man bruker noen ganger kryssplattform for å beskrive hybridløsninger. Dette mener vi at begynner å bli litt utdatert siden også native apper nå kan kjøres på flere plattformer. iOS-apper kan kjøres samme kode på de aller fleste enhetene i Apples portefølje (fra telefoner til klokker til Macer), mens Android apper blant annet kan brukes på Chromebook-er.
Delt kode
En viktig grunn at at mange ønsker å bruke hybrid-teknologi er at de vil unngå å skrive samme kode to ganger, en for hver plattform. Men hvor mye kode er det egentlig som trengs? Koden på plattformen handler hovedsakelig om hvordan man skal navigere seg rundt i appen, hvordan elementer skal se ut og hvordan data skal hentes. Hvis vi er enige om at det er viktig å følge designkonvensjonene på plattformen, så sparer man hovedsaklig tid rundt datahenting.
Man trenger i de fleste tilfeller også en backend-utvikler, og med det – en gjennomgang av hvilken logikk som skal ligge i appen eller nettsiden, og hvilken logikk som skal ligge i baksystemene.
Kombinasjoner
Det er alltids mulig å kombinere hybridløsninger og native kode. Man kan f.eks. velge å lage moduler i hybridteknologi i native apper eller moduler i nativeteknologi i hybridapper. Om du bruker en hybridløsning kan det fort hende at du må gjøre dette for å få på plass funksjonalitet som ikke er støttet i rammeverket. Da trenger du folk som har kompetanse på hybridrammeverket og native kode.
Det er også mulig å vise websider i apper, som kan spare tid. Vi i Shortcut gjør dette noen ganger for bla. personvernsregler eller hjelpesider. Om man bruker dette i viktige sider i appen, som skal kunne navigere videre til native sider, kan du dog få problemer.
Tilgang på utviklere
Når man utvikler en løsning som skal leve over tid må man både tenke på hvor tilgjengelig utviklere med kompetansen på rammeverket er, både nå og senere. Vi vet at det vil finnes native utviklere om 5 år, men hvor mange Flutter-utviklere man får tak i kan være vanskeligere å vite.
Det er også annen kompetanse native utviklere sitter på, som man ikke nødvendigvis får fra hybrid-utviklere. En native utvikler kan designkonvensjonene på plattformen og vet hvordan man kan bruke teknologien plattformen tilbyr.
Konklusjon
Du kan kanskje tenke at vi vil konkludere med at du må lage en app i native kode, men det vil vi ikke. Du vet hva du skal lage, så du vet derfor mer enn vi gjør rundt hva du trenger. Det er også andre hensyn man må ta, som du har oversikt over. Men vi kan si det at den eneste grunnen til å velge en hybridløsning er utviklingskostnad og tilgang på kompetanse. Airbnb, som tidligere brukte mye energi på å utvikle sine React Native-apper valgte å gi opp på den løsningen ettersom at de måtte vedlikeholde tre forskjellige kodebaser i stedet for to, i tillegg til en rekke biblioteker. De tenkte at de kun skulle trenge å forholde seg til React Native- koden, men man må også ha noen som kan vedlikeholde native kode.
Det er spennende med apper. Folk bruker i snitt 4.5 timer hver dag på mobilen sin. 90% av tiden bruker de i native apper. 20 minutter av disse 4.5 timene om dagen i snitt – globalt – brukes på mobil web1. Det er altså liten tvil om hva brukerne av appene foretrekker. Hvis du klarer å komme forbi hindrene rundt å lage en strategi, sette opp budsjetter og finne flinke folk, så kan du sitte igjen med en tjeneste folk faktisk liker å bruke.
Å komme seg igjennom alt det, for å se sluttbrukerne bruke tjenesten din med et smil om munnen kan være lang, men verdt det.