Tenk deg at bedriften din trenger både nett- og mobilapper. Det er mange alternativer tilgjengelig, og valget er noen ganger vanskelig. Det er mange faktorer som må vurderes, for eksempel:
- Er nett- eller mobilapper din prioritet?
- Hva er hovedfunksjonene i appene dine?
- Hva er produktstrategien din? Kortsiktig, for eksempel for en hendelse eller et langsiktig system?
- Har du en god eksisterende løsning for nettet og trenger bare mobilapper?
- Bygger du fra bunnen av?
- Har du et eksisterende utviklingsteam med erfaring innen en bestemt teknologi?
- Bruker du entreprenører til å bygge løsningen?
Native vs plattformskamp har pågått i mange år. Det har vært flere plattformløsninger: React Native, Xamarin, Cordova, Phonegap, Flutter, etc.
React Native ser ut til å være kongen nå ettersom både JavaScript (som er det mest populære programmeringsspråket i dag) og React er mye brukt.
Flutter kan være den nye utfordreren i økosystemer på tvers av plattformer.
Native utvikling støttes fortsatt sterkt, utvikles og moderniseres av plattformseiere: moderne språk (Kotlin/Swift), deklarative brukergrensesnittmønstre med Swift UI og Jetpack Compose introduseres.
Nettet er et så stort tema at det fortjener flere artikler på egen hånd. Derfor fokuserer vi bare kort på det. I de fleste prosjekter er det en eksisterende backend tilgjengelig med API-er mot webfrontend og apper. De viktigste webteknologiene er basert på Javascript: React, Angular, Vue. Fra disse er React (DOM) den mest interessante siden den ligner veldig på React Native. PWA blir heller ikke vurdert her. Vi fokuserer heller ikke på hybridtilnærmingen der native og cross-platform code brukes sammen i samme app. Disse kan bli diskutert i fremtidige artikler.
Native apputvikling
iOS
Programmeringsspråk er Objective-C (legacy) og Swift. Du kan blande dem i eldre prosjekter. Swift ble opprettet av Apple i 2014 og åpen kildekode siden. Swift er et moderne, stabilt språk. Utviklerverktøyet, XCode, leveres av Apple. Nylig lagt til Swift UI og deklarativ, moderne UI-rammeverk. Alle enhetsfunksjoner som Apple har gjort tilgjengelig for tredjeparter er tilgjengelige. Gir det virkelige plattformens opprinnelige utseende og raskeste ytelse. Utvikling for iOS krever Apple HW, så på grunn av prislappen og motstanden fra noen utviklere mot Apple er det vanskeligst å finne gode iOS-utviklere.
Å lære språket og iOS-programmeringsparadigmer er også litt tidkrevende. Offisielle retningslinjer for dokumentasjon er svært foreldet og mange anledninger sitert som 'ikke gjør dette' (det berømte MVC-mønsteret). Det er imidlertid fortsatt et stort fellesskap som tilbyr tredjepartsbiblioteker, verktøy og hjelp. Tilpasning av iOS-nye versjoner er den høyeste, nye OS-versjonene som vanligvis støttes av minst 5+ år gamle enheter.
Android
Den støtter både Java og Kotlin som morsmål. Kotlin regnes som det primære valget når du lager en ny app og anbefales også av Google.
Kotlin er fullt kompatibel med Java (kjører på JVM), og de to kan brukes sammen i de samme prosjektene. Kotlin er utviklet av JetBrains og åpen kildekode. Hovedutviklerverktøyet er Android Studio (åpen kildekode) bygget på toppen av JetBrains' IntelliJ-verktøy. Google introduserte et nytt deklarativt brukergrensesnittverktøysett kalt Jetpack Compose. Å bygge Android-apper i Java eller Kotlin vil gi naturlig utseende og best ytelse. Det regnes som billigere og enklere å starte enn iOS, mer tiltalende for folk ettersom mange utviklere allerede er kjent med Java og verktøyene. Offisiell dokumentasjon holdes oppdatert, og Google gir gode og moderne mønstre for å bygge opp apper. Mange tredjepartsbiblioteker, verktøy er tilgjengelige. Enhetsfragmentering er et problem, mange leverandører, versjonsenhetskombinasjon, blindveier (som Huawei). Google vil erstatte Android med et nytt operativsystem kalt Fuchsia. Kotlin er også et tverrplattformspråk i seg selv, det kan kompileres for å kjøre naturlig iOS, macOS, Linux, Windows, etc... og kan brukes på hvilken som helst plattform som kjører JVM, for eksempel for backend-utvikling. Dette tverrplattformaspektet av Kotlin diskuteres ikke her.
React Native
React native er utviklet av Facebook og åpen kildekode. Det er et rammeverk på tvers av plattformer som støtter Android, iOS, desktop OS og mange andre. Programmeringsspråk er Javascript eller Typescript (utvidelse av Javascript som tilbyr en form for typesikkerhet). React native apper på enheten kjører på toppen av en Javascript-motor som bygger bro mellom Javascript-operasjonen og plattformhendelsene frem og tilbake mellom den underliggende native koden. Dette legger til et ekstra lag og kjøretidskompleksitet som i noen tilfeller kan påvirke ytelsen. Brukergrensesnittet kan se det samme ut som et native, siden det bruker native elementer til å gjengi. Når det gjelder React Native er det stort sett ikke målet. Husk noen av de tidligere iOS-appene på tvers av plattformer som ønsket å se ut som native, men Apple fornyet brukergrensesnittet, og disse appene ser rare ut da de kjørte på en eldre versjon av iOS. Native kode kan brukes fra en React Native-app. Det er mange store apper som er skrevet delvis eller helt i React Native, inkludert Facebook. JavaScript er et av de mest populære programmeringsspråkene per i dag, med et stort antall utviklere med mange verktøy, åpen kildekode-biblioteker og stor samfunnsstøtte, etc. Det er ganske greit for frontend-utviklere som er kjent med React DOM (web) å begynne å bygge React Native-apper. Det er den største driveren for det.
UI-kodedeling (ved bruk av samme React-komponent på React web og React Native) er imidlertid ikke mulig, React web gjengir HTML-elementer, mens React Native definerer sine egne elementer. Så hvis noen allerede har en webapp, må React UI-komponentene forkes (kopieres) og refaktoriseres og to UI-kodebaser bør opprettholdes. Ikke brukergrensesnitt, forretningslogikkkode kan imidlertid deles (mye bedre hvis denne koden er på backend skjønt). Den støtter varm omlasting som kan spare utviklingstid.
React Native avslører ikke alle native funksjoner som plattformer da er i stand til, native brobygging er imidlertid mulig. De lider også av enhetsfragmentering og rare feil på visse enhets- og OS-kombinasjoner.
flagre
Flutter er et UI-rammeverk utviklet av Google og er åpen kildekode. Flutter er for utvikling på tvers av plattformer som støtter mobil, desktop og web. Det bruker dart-språket. Dart er også utviklet av Google og open source. Dart er et moderne typesikkert språk syntaktisk likt JavaScript, Kotlin og Swift. Flutter-apper er kompilert til native kode på mobile plattformer, Google implementerte UI-komponentene naturlig for både iOS og Android. Derfor kan ytelsen og utseendet være det samme som for native apper. Det er også mulig å bruke native UI-komponenter direkte i en Flutter-app. Flutter kan også bygges for nettet, men utgangen er ikke den vanlige JavaScript + HTML + CSS men noen blackbox JavaScript-kode som direkte trekker piksler til HTML-lerretet som ligner på spill som kjører i nettlesere. Dette har en stor ulempe, siden det ikke er noen meningsfull HTML, kan webappene ikke støtte SEO for øyeblikket. Dette kan imidlertid endre seg, siden det eies av Google, det største nettsøkeselskapet, så de kan komme med en løsning. For utvikling kan Android Studio eller Visual Studio Code brukes. Flutter støtter hot reload som er en stor hjelp under utviklingen, og kan spare mye tid for utviklerne sammenlignet med native-utvikling. Flutter er sannsynligvis det første rammeverket på tvers av plattformer som gir løftet om å være virkelig på tvers av plattformer ved å kjøre den samme kodebasen på nettet, og native apper. Det er ikke mange utviklere med praktisk Flutter-erfaring nå. Men siden språket ligner mange populære. Det er lett å lære og det deklarative UI-konseptet ligner SwiftUI, Android JetpackCompose, React. Flutter har sannsynligvis en av de beste utviklerveiledningene og opplæringsprogrammene for å hjelpe læring, det er allerede mange tredjepartsbiblioteker og fellesskap bak det. Mange Googles egne tjenester er implementert i Flutter eller Dart, så støtten vil være der spesielt, Flutter vil være UI-rammeverket for Googles nye mobile OS (Fuchsia) som vil følge Android.
Sammenligning
Etter en oppsummering av hver teknologi, la oss prøve å oppsummere i tabellen under våre anbefalinger.
Konklusjon
Native apper
Native apper tilbyr den beste ytelsen og de fleste funksjoner, men de er dyrere å utvikle. I noen tilfeller bør de være førstevalget, spesielt hvis appen din trenger funksjoner som avansert kamera, AR, tung app-CPU-bruk, spill, navigasjon, bakgrunnsdatabehandling, posisjonssporing, etc. og du har et langsiktig mål med appene dine. Det er mer utfordrende å bygge et anstendig native apputviklingsteam.
For å oppsummere betyr det å velge native apps at du vil ha tre forskjellige apper: web (i hvilken som helst teknologi), Android og iOS. Du kan oppnå det beste resultatet på alle plattformer; appen din på hver plattform kan tilpasse seg plattformen, men utviklings- og vedlikeholdskostnadene er høyere. Native apper bør også justeres årlig når Apple og Google gjør endringer i plattformene.
React Native
Å velge React Native som apputviklingsplattform er et attraktivt alternativ for mange, spesielt hvis du har et utviklingsteam med JavaScript og React-erfaring. React Native er for de fleste webutviklere det første trinnet inn i utviklingsdomenet for mobilapper. Dette betyr at du trenger et enkelt team for å bygge nett- og mobilapper også. Det er vanligvis lettere å finne et team av React-ingeniører enn å ha Android, iOS og webkompetanse. App-utvikling kan være rask. Hvis du allerede har et React-nett, sannsynligvis kan mange komponenter brukes som base for din opprinnelige app. Imidlertid er full UI-kodedeling mellom React DOM (web) og React Native ikke mulig. Så du vil fortsatt ende opp med å ha to kodebaser, en for nettet og en for appene. React Native kan være et godt valg hvis du har et tilgjengelig React-team, mobilappfunksjonene er ikke for komplisert da det kan være ytelsesproblemer, og du hovedsakelig tenker på kort eller mellomlang sikt.
flagre
Flutter kan virkelig levere på tvers av plattformspromis, noe som betyr implementere en gang og kjøre overalt. Flutter-mobilapper kjøres som innebygd kode, ytelse og utseende er sammenlignbart med native apper. Bortsett fra de få nisjefunksjonene der native kode er nødvendig, kan det være et veldig godt valg for apper. På nettet er mangelen på SEO-støtte sannsynligvis ikke mulig i noen tilfeller, men for webapper som logger på brukere er det ikke nødvendig. For MVPer eller raske å markedsføre fullskala-løsninger (web og app) kan det være et perfekt valg. Hvis du holder web- og app-brukergrensesnittet det samme eller nært, vil du ha en kodebase. Separate nett- og Flutter-apper kan imidlertid være et bedre alternativ på lengre sikt. Hvis den første mottakelsen er lovende, kan nettet erstattes senere med en egen webløsning (React, Angular, Vue, etc..). Det er ikke mange praktiske Flutter-utviklere der ute ennå, men læringskurven er bratt med gode opplæringsprogrammer og dokumentasjon.
I de fleste tilfeller vil mobilapper skrevet i Flutter og web utviklet i hvilken som helst webteknologi gi de beste resultatene.
Tommelfingerregel
- Velg egen app hvis du trenger ytelse og enhetsfunksjoner
- Velg React Native hvis du har React front-end utviklere
- Velg Flutter for de fleste mobilapper der native ikke er nødvendig