Native eller cross platform apps?

Mange af de projekter Axla udvikler, inkluderer en eller anden form for mobil app. Her oplever vi ofte, at kunder spørger ind til, om vi bygger apps native eller cross platform.

Dette udtrykkes ofte i et håb fra kundens side om at spare nogle penge, da man nemt kan antage, at man ved cross platform kan halvere udgiften ved kun at få udviklet appen én gang i stedet for to.

Desværre er virkeligheden ikke så ligetil, og der er flere faktorer der skal tages i betragtning, når man vælger, hvilken teknologi man vil benytte til en bestemt app. Hos Axla har vi tænkt meget over dette, og vi vil derfor prøve at uddybe, hvilke faktorer vi vægter højest for at få det bedste resultat for vores kunder.

Først vil vi dog kort ridse op, hvad forskellen er på de forskellige teknologier.

Native

Når man udvikler “native”, menes der, at man benytter det framework og programmeringssprog, som er stillet til rådighed af producenten. Dvs. man i princippet udvikler apps direkte med de værktøjer, som producenten har designet til deres platform. Da markedet domineres af to platforme (iOS og Android), som har hver deres framework og sprog, skal man altså udvikle to versioner af samme app.

Cross platform

Cross platform frameworks gør det muligt at udvikle én app, der i teorien kan “bygges om” til to native apps. Dvs. at man med den samme kodebase kan lave begge apps.

Hybrid og web

En helt 3. mulighed er at udvikle apps i html, som indbygges i en app, der i princippet bare viser en hjemmeside, eller man kan lave hjemmeside, der er tilpasset til mobile enheder. Vi har i denne artikel valgt at se bort fra disse, da anvendeligheden ikke direkte kan sammenlignes med de andre teknologier, og egentlig er målrettet helt andre behov.

Hvad er bedst?

Fortalere for native appudvikling fremhæver tit to punkter om native apps:

• De er hurtigere og mere responsive.
• Man får et look & feel der passer 100% til platformen.

Helt grundlæggende er der noget om det. På nogle områder vil det være svært at opnå samme hastighed og udtryk via en cross platform app, men når det kommer til stykket, kan man næsten altid udvikle en cross platform app der er så hurtig, at man ikke kan mærke forskel, og designet på en måde hvor man ikke kan se forskel.

Fortalere for cross platform appudvikling fremhæver tit dette punkt:

• Det er hurtigere (og derfor billigere) at udvikle en cross platform app.

Intuitivt giver det god mening at én app kan udvikles hurtigere end to, så hvorfor skulle man så overhovedet overveje at udvikle native apps? Svaret på dette skal bl.a. findes i hvad der skal til for at få en tilsvarende hastighed og udtryk i appen, samt et nærmere kig på de faldgruber der er ved cross platform udvikling.

Samme hastighed

Det giver god mening at man kan få optimal ydelse ud af platformen, når man udvikler direkte ned mod det framework der stilles til rådighed. Hvis man udvikler til et andet framework, som så selv skal oversætte til platformens framework, kan man ikke være sikker på det sker effektivt nok. I de fleste tilfælde er effektiviteten dog rigeligt god. En begrænsning kan komme til udtryk hvis man går til grænsen af hvad platformen kan præstere med mængden af komponenter og data. Skulle det ske at man oplever en flaskehals, kan man kombinere sin cross platform kode med specialiserede moduler til hver enkelt platform. Men så begynder man så småt at æde den tidsmæssige fordel.

Udtrykket

Et andet aspekt er at iOS og Android er forskellige. Eksempelvis er der markante forskelle i grafisk udtryk og brugeroplevelse. Derudover er der også forskelle i hvilken hardware funktionalitet der er understøttet, og hvordan den tilgås. iOS brugere og Android brugere har ofte vidt forskellige forventninger til hvordan et vist interface skal præsenteres, og hvordan en teknologi anvendes. Her vil cross platform appen ikke altid kunne dække begge dele, uden at man griber til et specialiseret modul.

Faldgruber

Som udvikler er det ikke uoverkommeligt at løse de problemer der måtte opstå med hastighed og udtryk ved cross platform udvikling. Det er da irriterende at skulle gå omveje, og det spiser af den fordel man er ude efter, men det er problemer der er håndgribelige og kan løses med den rette viden. Der hvor vi er mere bekymrede, er når der er afhængigheder til tredjepart, som er uden for vores kontrol. Et cross platform framework er netop et tredjeparts system, som vi ikke kan kontrollere.

Bag cross platform frameworks som Xamarin, React Native og Flutter står store selskaber, men det ændrer dog ikke på at de altid er et skridt bag efter den platform de arbejder imod. Det er Apple der bestemmer hvordan man udvikler til iOS og det er Google der bestemmer hvordan man udvikler til Android. Når de kommer med nyt, må man som cross platform udvikler pænt vente på at det valgte framework følger trop. Og når der bliver opdaget en fejl, må man vente på at den bliver rettet, og her er det ikke sikkert at tredjepart har samme prioritet som os. Der kan selvfølgelig også komme fejl i Apples og Googles frameworks, men man skal tænke sig godt om inden man tilføjer endnu en potentiel kilde til fejl.

Dertil kommer alle de andre tredjeparts værktøjer som vi udviklere benytter os så flittigt af. For ikke at opfinde den dybe tallerken hver gang, benyttes en lang række af værktøjer til at opnå kompleks funktionalitet i stedet for at udvikle den selv. Her kan nævnes værktøjer til at scanne QR koder, integrere med SoMe services, analytics, push beskeder og meget andet. Disse tredjeparts værktøjer skal også understøtte cross platform værktøjet, og de skal sørge for at holde det fejlfrit. Dvs. der er endnu en kilde til fejl eller mangler.

Erfaringer

I Axla har vi langt større erfaring med native udvikling end cross platform. De få gange vi har bevæget os over i cross platform verdenen, er altid endt i at vi har brændt fingrende på et eller andet problem, som tog lang tid at løse. Det har selvfølgelig også noget med erfaring at gøre. Når man arbejder meget med en platform løser man også problemer hurtigere på den end på en anden.

Airbnb prøvede

Vi vil henvise til en interessant artikelserie fra Airbnb, der har gennemgået et skifte til cross platform. De skiftede i 2016 til React Native, men endte 2 år senere med at gå tilbage til native udvikling. Ikke, fordi de var specielt utilfredse med React Native, men fordi det viste sig, at de brugte mere tid på at arbejde uden om mangler og problemer, end de sparede ved kun at have én kodebase.

Hele billedet

Når det handler om budgettet til et udviklingsprojekt, skal man huske at det indebærer mere end at programmere. Der bruges tid på at udarbejde kravspec, grafisk design, UX design, projektledelse, test, QA og udgivelse. Disse opgaver udgør en betydelig del af det samlede tidsforbrug, hvilket er med til at gøre en evt. forskel i udviklingstid mellem native og cross platform mindre betydelig.

Konklusion

Native vs. cross platform er et emne som tit er følelsesladet at diskutere blandt udviklere, da der er mange forskellige tilgangsvinkler og behov. Det er da også umuligt at vælge det ene frem for det andet på tværs af alle projekter. For meget simple projekter kan man helt sikkert spare tid på den korte bane, og måske også den lange. Men for os er det afgørende at undgå de mange usikkerheder, der er ved at vælge cross platform. Usikkerheder som vi hverken har kontrol over eller kan forudsige konsekvensen af. Samtidig er forskellen i tidsforbrug ikke så stor som man umiddelbart tror, hvis den overhovedet er der. Derfor har vi hos Axla valgt at fokusere på native udvikling. Hvis kunden på et nyt projekt insisterer på, at det skal være cross platform, så klarer vi naturligvis også det, men vores anbefaling vil næsten altid være native.

Komplekse problemstillinger som denne er en af årsagerne til at vi tilbyder 2 timers gratis sparring. Her hører vi om dine problemstillinger og deler ud af vores erfaring. Vi hjælper dig i den retning, der bedst opfylder dine behov, også selvom det ikke ender med at være os, der skal løse dem.