Når du skal lage en Android- eller iOS-app, har to først og fremst to valg:
- Du kan lage en native app. Disse kodes til det spesifikke operativsystemet, og du må i stor grad utvikle to helt separate apper; en til Android, en til iOS.
- Eller du kan lage en hybridapp. Disse kan dele mye av den samme koden til både Android- og iOS-versjonen. React Native er én av mange løsninger til dette.
Men da kode24 møtte et av Norges største apphus, Shortcut, fortalte de at de nærmest aldri utvikler hybridapper. Og noen virker å mene at hybridapper, på sett og vis, ikke er skikkelige mobilapper.
Så hva er egentlig greia med hybridapper? Når fungerer det, når fungerer det ikke? Vi tok en prat med apputvikler Petter Holstad Wright hos Shortcut.
Ja, Petter; hva er egentlig en hybridapp?
Om man ønsker å definere hybrid ut i fra det ferdige produktet du finner i App Store eller Google Play Store, så skiller hybridapper seg ut ved at de enten:
- Kjører i en rammeløs nettleser direkte fra nett (faktisk bare en nettside, webapp)
- Kjører i en rammeløs nettleser hvor koden ligger lokalt (hybridapp)
- Har en interpreter som oversetter koden til native i sanntid når appen kjøres (interpreted-app)
- Bruker en kombinasjon av disse teknikkene.
Dette er apper som ofte er utviklet delvis eller utelukkende med standard web-teknologier, gjennom mobil-optimaliserte nettsider, med verktøy som React Native, Ionic, PhoneGap og så videre.
Å definere hybrid på denne måten utelukker derimot apper som er utviklet med verktøy og programmeringsspråk som på forhånd oversettes til native kode — altså plattformens eget språk. For eksempel Kotlin, Xamarin og så videre.
Når jeg svarer på disse spørsmålene inkluderer vi disse, og definerer dermed hybrid som alle apper som utvikles i et språk eller verktøy som offisielt ikke er direkte støttet av plattformen hvor appen skal kjøre.
Og hva er din egen holdning til hybridapper, helt generelt?
Hybridløsninger er jo drømmen. Det å kunne sitte med én kodebase og spytte ut apper til alle mulige plattformer uten videre hadde jo vært veldig greit!
På norsk heter det visst «plattformavhengig app»
Språkrådet har noen råd.
Man leser at med hybridteknologi, så skal du få skrive i språket du kan, i tillegg til at det er lettere å utvikle og oppdatere. Det vi ser er at dagens hybridløsninger lover mer enn de kan holde.
Fellesnevneren, uavhengig av hvordan man definerer hybrid, er at man introduserer et ekstra lag med kompleksitet i løsningen, for så å gi noe tilbake til utvikleren til slutt.
Det ender allikevel opp med hovedsakelig to problemer: Vedlikehold og begrensinger.
Uffda, hva slags konkrete problemer skaper dette?
Målet er å gjøre utviklingsløpet enklere, men som Airbnb påpekte da de valgte å gå bort fra React Native, så ender man opp med å vedlikeholde minst tre kodebaser i stedet for én per plattform.
Man får jobben med å holde iOS- og Android-versjoner oppdatert, i tillegg til biblioteker og rammeverk, om de blir vedlikeholdt. Man må holde kunnskapen om alle disse lagene ved like. Ved å ha flere lag, får man også flere steder koden kan feile, noe som kan føre til at man må feilsøke gjennom flere lag med forskjellig teknologi.
«Man ender opp med å vedlikeholde minst tre kodebaser, i stedet for én.»
Det vil også alltid være begrensninger når man jobber hybrid. Det er alltid ett lag mellom deg «ekte native», som fører til at man er alltid er et steg bak.
Man er avhengig av at de som vedlikeholder rammeverket velger å implementerer støtte for de nye tingene, noe som ikke er garantert. Widgets, rike varsler, håndtering av data i bakgrunnen, taleassistent, wearable-støtte og andre native-funksjoner vi tror kommer til å bli viktigere og viktigere fremover, er som som regel ikke er støttet.
Mer kritiske ting, som å støtte nye typer formfaktorer, som vi så da iPhone X ble introdusert, kan også føre til store problemer for brukeropplevelsen.
Om det er funksjonalitet som ikke støttes i rammeverket, har man som regel tredjeparts-biblioteker som tilgjengeliggjør dem. Men da er vi tilbake til problemet med vedlikehold.
Såpass. Flere problemer med hybridapper?
Ja. Flere hybridløsninger er ulovlig dårlige, da flere biblioteker ikke nødvendigvis er lagt opp til å støtte tilgjenglighetskravene som er satt opp i WCAG 2.0.
Derfor lagde SOL hybridapp med React Native
- Det var et enkelt valg.
Retningslinjene for design på plattformen blir dessuten ofte oversett, da rammeverket ikke nødvendigvis har lagt opp til at de følges. Dette merker man spesielt når det gjelder navigasjon. Pluss:
- Man er alltid et steg bak native.
- Alle utviklere må ha oversikt over veldig mye forskjellige teknologi, språk, biblioteker og verktøy.
- Det er kritisk at rammeverket man bruker blir vedlikhold.
- Endel utdatert dokumentasjon.
- Utydelige feilmeldinger.
- Stabilitet.
- Javascript.
Men noen fordeler er det vel, også?
Den største fordelen er at om du kan noe web-utvikling, så klarer du ganske raskt å lage enkle apper til to plattformer.
Man kommer veldig raskt i gang med språk man kjenner til. Og man må i første omgang kun forholde seg til ett språk.
Så bruker dere i Shortcut hybridløsninger av og til?
Vi bruker det når vi ser det som nyttig, eller når kunden allerede har tatt et valg om teknologi før de kommer til oss. Når det er web-avdelingen som får ta en bedrifts teknologivalg, havner valget ofte på Javascript-baserte løsninger, så de kan vedlikeholde løsningen selv uten å lære seg et nytt språk.
«Vi har også flere native apper der deler av appen viser web-innhold.»
Vi har også flere native apper der deler av appen viser web-innhold, framfor native.
Om det kommer et nytt og lovende hybrid-rammeverk pleier vi som regel å teste det ut på en eller annen måte, om det ender i en app i App Store eller ikke. Den eneste måten vi kan være en rådgivende når det gjelder app-teknologi er å ha kunnskap på de forskjellige teknologiene.
Hvem vet, kanskje det en dag kommer en løsning som faktisk er bedre enn å jobbe native? For oss er det uansett viktig å ta diskusjonen om hva man vil oppnå, før man tar diskusjonen om hvilken teknologi man skal bruke.
Hva er et godt eksempel på når man bør lage en hybridapp, da?
Om man ønsker å utvikle enkle apper, uten altfor mye innhold og som ikke er forretningskritiske, så kan kan godt bruke hybrid-teknologi. Kampanje-apper som kun skal leve noen måneder er et eksempel på det.
Johannes har vært med på de fleste, store appene
Ukas Koder lager apper med Kotlin og Firebase.
Det kan også brukes som et verktøy for å utvikle høynivå prototyper, så man kan få svar på om dette er noe brukerne er interessert i. Man bør dog være sikre på at appen ikke trenger noe funksjonalitet utover det som er støttet av rammeverket.
Man kan også velge å utvikle undersider eller funksjoner i en app med hybrid-teknologier, mens appen i bunn kan være native. Det er lettere å ha native i bunn og heller bruke hybrid-teknologi på toppen, enn å ha låse alt inne hybrid-teknologien.
Og når bør man ikke bruke hybridløsninger?
Om appen er, eller kan bli, hovedflaten til tjenesten din.
Til slutt; har du noen anbefalinger til hybridløsninger som fungerer bedre enn andre?
Vi har laget flere apper i React Native som har fungert fint. Vi har blant annet en app i App Store som har fått 4 av 5 stjerner. Flere av tilbakemeldingene sier at det eneste som mangler er en widget, som man ikke får til uten videre.
Uansett hva man velger, er det viktigste at man har dedikerte utviklere som bryr seg om gode brukeropplevelser.
