Har du råd til native mobilutvikling?

Det finnes hovedsaklig tre måter å utvikle digitale løsninger for mobil på:

1. Native apputvikling med Swift (iOS) eller Kotlin (Android)
2. Kryssplattform, f. eks React Native eller Flutter
3. Hybridapper, med mobiltilpassede webløsninger i et nativeskall

La det være ingen tvil. Native mobilapplikasjoner gir, på sitt beste, knallgode brukeropplevelser.

Dessverre er det også dyrt og relativt komplisert.

Altfor ofte velges native teknologi ukritisk der kryssplattform eller hybridapper kunne gitt en billigere og raskere vei til mål.

I denne teksten ønsker jeg å rette søkelys på noen problematiske sider ved nativeutvikling som vi snakker for lite om.

Fart og flyt

Utviklingsfart er ikke en kvalitetene nativeutvikling kan skryte av. Både web- og backendutvikling har hatt langt mer tid på å modnes og har følgelig kommet lenger i utviklingen. Feedbackloopene er kortere, det er flere etablerte konvensjoner og arbeidet går rett og slett mer effektivt.

I tillegg har vi det kvelende faktum at det må utvikles separat til hver plattform. Se for deg at du trengte et webteam med én Chrome-utvikler, én Safari-utvikler, en Firefox-utvikler?

Senest forrige uke hørte jeg i en presentasjonen at «denne funksjonaliteten blir nok i et webview — da vi ikke har tid til å lage det i native» (implisitt at det tar lenger tid).

At tech-gigantene Google og Meta satser hardt på sine kryssplattformløsninger Flutter og React Native er også verdt å merke seg.

Tilgang på kompetanse

Nativeutvikling bruker dedikerte kodespråk og IDE-er. Dette er spesialistkompetanse som en liten andel av det norske utviklermarkedet besitter. Som i bransjen forøvrig, er det rett og slett for mange jobber og for få kvaliserte folk.

Skal du rekruttere dyktige iOS- eller Android-spesialister på det åpne markedet bør du dermed ha stor lommebok eller en helt rå merkevare — eller helst begge deler.

Jeg har selv snakket med teknologiledere i store, norske virksomheter som strever med å finne kvalifiserte apputviklere. Det oppleves som enda vanskeligere enn den allerede krevende rekrutteringssituasjonen i bransjen for tiden.

iOS-utvikler vs Android-utvikler vs apputvikler

I tillegg er det gjerne ofte slik at mobilutviklere er gode på enten iOS- eller Android-utvikling, og svært sjelden behersker begge plattformer.

Det resulterer ofte i dedikerte utviklingsteam for hver plattform. Dette gir flere konsekvenser:

1. For å unngå høy trikkefaktor trenger du en kritisk mengde utviklere på hver plattform. Det er dyrt i drift, og krevende bemanningsmessig.
2. Hver feature blir utviklet av minst to forskjellige personer.
3. Det er ikke nødvendigvis sånn at funksjonaliteten blir sluppet samtidig på begge plattformer.
4. Du risikerer forskjeller i oppførsel mellom plattformene. Plattformene er forskjellige og appen bør selvfølgelig tilpasses lokale forhold, men oftere enn man skulle tro ender man opp med forskjeller også i forretningslogikk.

I min erfaring er også ofte sånn at mobilspesialistene verken har motivasjon for eller kompetanse til å gjøre web- eller backendarbeid. Da er du avhengig av at organisasjonen din har en konstant strøm av mobiloppgaver for å unngå periodevis tomgang.

Akkurat som bransjen bør bort fra dedikerte backend- og frontendutviklere som ikke ønsker eller evner å se helheten vi som utviklere leverer — bør vi bort fra spesialiserte mobilutviklere som kun bryr seg om den dyre duppedingsen kunden har i lomma.

Hvordan implementere produktteam?

En annen utfordring flere større organisasjoner sliter med er hvordan man unngår et sentralt appteam som mottar bestillinger fra andre produktteam.

Det er en seriøs torpedo i siden på strategien om tverrfaglige, autonome produktteam dersom all utvikling ut mot sluttbrukerne dine skjer i et separat team som fokuserer hovedsaklig på kanalen (appen) og ikke produktet.

De fleste er enige at det ikke er heldig med et webteam som konsumerer endepunkter laget av backendteamet, som igjen leverer bestillinger til databaseteamet.

Sånn jobber vi ikke lenger. Det er vi ferdige med. Men i mobilverdenen blir det likevel ofte sånn.

React Native som alternativ

I noen tilfeller kan det være riktig å likevel velge nativeutvikling. Caset styrkes f.eks hvis du har helt unike krav til ytelse eller brukeropplevelse (les: du skal lage en ny Snapchat, Tik-Tok eller Candy Crush). Eller hvis du har så store budsjetter at økonomi og fleksibilitet i teamriggen ikke spiller noen rolle.

For oss andre finnes det heldigvis gode alternativer.

Selv har jeg gode erfaringer med React Native. La oss se litt på utfordringene nevnt over, sett i kontekst av kryssplattformutvikling med JavaScript og React Native:

Fart
I min erfaring sparer man nærmere 45% av arbeidet med React Native. Man må fremdeles påregne noe plattformspesifikk kode, men hoveddelen av arbeidet kan nå gjøres én gang og ikke to.

Besparelsen i både tid og penger som dette utgjør med et stort utviklingsteam over tid er vanskelig å overdrive!

Tilgang på kompetanse
Det er dramatisk mange flere i markedet med kompetanse på JavaScript/TypeScript og React. Med en langt større pool av ressurser blir rekrutteringen enklere. Mange webeksperter uten mobilerfaring synes kanskje det er et spennende karrieresteg å prøve seg på mobilutvikling, uten å måtte omskoleres totalt..?

Jeg har personlig onboardet et titalls webutviklere til mobilutvikling på denne måten og sett på kloss hold hvor raskt folk kan bli produktive i det som tross alt er et helt nytt univers.

Spesialister vs generalister
Når en habil utvikler kan bli effektiv på mobilplattformen på uker og dager, medfører det en praktisk fleksibilitet inn i teamriggen. Trenger man litt ekstra krutt på mobil et halvår? Kanskje finnes det et team som kan avse en utvikler en periode.

Det er også fordelaktig at dem som utvikler appfunksjonalitet også har erfaring fra andre applikasjoner i sjappa. Kanskje den samme personen kan skrive både frontend- og backendkoden?

Produktteamorganisering
Når mobilutvikling bare blir enda en disiplin den moderne utvikler kan beherske, kan i teorien hele teamet bidra på mobilutviklingen heller enn at separate utviklere gjør dette alene.

Avsluttende ord

På mitt forrige oppdrag, bidro 25 utviklere på tvers av 5 team inn i en felles appkodebase. React Native som verktøy bidro til høyere utviklingsfart, mer kompetansedeling, enklere onboarding og rekruttering. Kort sagt, var det som teknologi avgjørende for at vi lykkes med digital produktutvikling.

I den norske tekniske debatten har det de senere årene blitt skrevet noen kritiske tekster om kryssplattform generelt og React Native spesielt. Felles for disse innleggene er at skribenten ofte kommer fra spesialiserte nativeapp-miljøer. Disse selskapenes forretningsmodell står og faller på at det er store behov for dyr og treg nativeutvikling i markedet.

Det er uheldig når teknologien i seg selv blir et middel, heller enn å velge riktig verktøy for å oppnå sine mål på en tids- og kostnadseffektiv måte.

Det taper vi alle på.