Cross-Platform vs. Native Mobile Apps

(Jacob Muchow (15. okt 2020)

Design af

Introduktion

Apps på tværs af platforme er blevet en go-to-market-løsning for mange nystartede virksomheder i den tekniske industri. De lover at være i stand til nemt at skrive en codebase, der distribueres til både iOS- og Android-enheder. Imidlertid vælger mange virksomheder stadig at gå den traditionelle rute og udvikle sig på trods af de potentielle fordele.

Begge løsninger er gyldige – der er ikke en eneste “rigtig” måde at gøre tingene på (i det mindste ikke endnu! ). At vælge den rigtige vej frem for dit team afhænger af dine mål og begrænsninger, og dit valg inden for teknologi skal komme fra det mere end en personlig tro. Dette indlæg tegner en sammenligning mellem de to muligheder for at hjælpe dig med at træffe den bedste beslutning for din virksomhed.

Cross-Platform

I øjeblikket er der flere konkurrerende muligheder for udvikling på tværs af platforme : React Native, Flutter, Xamarin, Ionic for at navngive de almindelige. I dette indlæg vil vi undgå at forklare hver enkelt og diskutere fordele / ulemper ved udvikling på tværs af platforme som helhed.

Hver af disse platforme giver dit team mulighed for at skrive koden til en app, som kan distribueres til både Google Play Butik og App Store. Omkostningsbesparelsespotentialet ved dette er åbenlyst enormt, hvis det gøres effektivt.

Fordele på tværs af platforme

  • Det er muligt at levere til begge mobilmarkeder med et langt mindre budget end det ville tage to at udvikle to separate native apps. Cirka 60–70\% af koden kan deles, mens resten er tilpasset begge platforme.
  • Du kan have et enkelt mobiludviklingsteam, der forenkler din organisation. Dette kan også være en fordel ved at skabe en vis samhørighed i dine Android- og iOS-apps, som det ellers er svært at opnå.
  • Afhængigt af den valgte teknologi kan du have udviklere i huset, der allerede er fortrolige med sprogene og udviklingsformerne (JavaScript, C # /. NET, Dart). Du kan muligvis opbygge et team uden at skulle begynde at ansætte fra bunden.
  • Nye funktioner distribueres til dine iOS- og Android-brugere på samme tid i stedet for at have en “funktionsleder”.

Ulemper ved cross-platform

  • Det er meget sværere at ansætte udviklere, der har erfaring med denne teknologi sammenlignet med native.
  • Når du gør rammer en vejspærring, tager det ofte en rigtig højt kvalificeret ingeniør at løse problemet.
  • iOS- eller Android-specifikke funktioner (f.eks. Health Kit / Apple Watch) er ekstremt vanskelige eller umulige at arbejde med.
  • At udvikle indviklet UI / UX tager meget længere tid end Native. Hvis der ikke er en out-of-the-box-komponent, skal der oprettes en brugerdefineret til begge platforme, hvilket er tidskrævende.
  • Tværplatform er ofte ikke så effektiv som Native, hvilket undertiden forårsager noget jank, der ikke rigtig kan løses. Dette har større indvirkning, jo mere kompleks din applikation er.
  • Teknologierne har mindre modne økosystemer end oprindelige. Dette betyder færre værktøjer, som dit team kan bruge og mindre hjælp til rådighed, når de løber ind i problemer.
  • Apps “føles” ikke som iOS- eller Android-apps. De skaber ukendte oplevelser for brugeren, hvilket kan få appen til at føles utiltrækkende.
  • Der er risiko for, at den valgte teknologi dør ud og mister support fra community, skabere eller firma.

Når det giver mening at bruge cross-platform

  • Du vil målrette både Android- og iOS-markederne til din MVP.
  • Begrænset budget til mobil er et af dine primære begrænsninger.
  • Din mobilapp er ikke en central del af din virksomhed.
  • Brugeroplevelse skal være standard mellem dine apps, og du søger ikke at “føle” dig som en iOS eller Android app.
  • Din applikation er ligetil med hensyn til brugeroplevelse og funktioner.
  • Dine designs er næsten identiske på begge platforme.

Vores tanker

Krydsplatformteknologier er en fantastisk måde at komme hurtigt på markedet for et så bredt publikum som muligt og validere din idé. Hvis din app ikke kræver platformsspecifikke teknologier, indviklet UI / UX eller kompleks forretningslogik, bør du kraftigt overveje at gå med en platformsløsning. Efter MVP kan dette give dig mulighed for at fokusere helt på produkt iteration, mens det at gå native kan betyde, at du bliver nødt til at overveje at opbygge et helt nyt team / app til iOS eller Android. Native kan altid komme senere, hvis det er nødvendigt.

Native Development

“Native” udvikling henviser til den traditionelle stil med at udvikle en hel applikation ved hjælp af de første parts værktøjer leveret af Apple og Google til iOS og Android.Økosystemerne har udviklet sig, men i dag er industristandarden at bruge Android Studio & Kotlin-programmeringssproget til Android, og Xcode & Hurtigt programmeringssprog til iOS.

Denne tilgang kræver, at der er to separate kodebaser til hver app. Hold vil normalt have ingeniører, der fokuserer på den ene platform eller den anden, eller nogle gange har de to helt separate udviklingsteams til hver platform.

Mange gange frigiver virksomheder deres app enten til App Store eller Google Play først og fokus på iterering på produktet. Hvis levering af appen på den anden platform er en del af deres strategi, når de først har trækkraft eller succes og tilstrækkelig finansiering, vil de investere i at opbygge et team til at håndtere den anden platform.

Fordele ved native udvikling

  • Apps kan drage fordel af alle iOS- eller Android-specifikke funktioner.
  • Brugeroplevelsen kan skræddersys i større eller mindre grad til det, som en iOS- eller Android-bruger forventer.
  • Brugerdefineret, indviklet brugergrænseflade er meget lettere at udvikle generelt.
  • Hvis der er kompleks baggrundsbehandling, vil det køre jævnere end på tværs af platforme på grund af tekniske begrænsninger.
  • Indfødte apps gjort godt “føler sig bedre” på en måde, som apps på tværs af platforme ikke er i stand til lige nu.
  • Dit følgende hold skal være i stand til at indhente dit første hold temmelig hurtigt. De behøver ikke at gennemgå de samme fejl og erfaringer, som det første hold gjorde.
  • Med hensyn til jobmarkedet er der mange flere udviklere, der har erfaring med native iOS- eller Android-udvikling. Din ansættelse vil være meget enklere.
  • Værktøjerne og community support er blevet udviklet siden starten af ​​mobilapps og er langt mere robuste og modne.
  • Hvis du kan forestille dig det, det kan ofte gøres 99\% af tiden.

Ulemper ved native udvikling

  • Det kan være meget dyrt at finansiere native apps til både iOS og Android .
  • Du har i det væsentlige brug for to teams, der er udviklere værd at levere til begge.
  • Den følgende platform er ofte bagud med hensyn til funktioner, og det kan være svært at opnå paritet.
  • Det er udfordrende at opnå samhørighed mellem iOS- og Android-apps og -teams.

Når det giver mening at blive hjemmehørende

  • Du er ligeglad dybt om en finjusteret, høj kvalitet eller imponerende brugeroplevelse.
  • Du vil drage fordel af platformens funktioner (f.eks. Health Kit / Apple Watch-integration).
  • Du har beregningsintensive funktioner i tankerne såsom video eller live streaming.
  • Det er ikke hej meget vigtigt, at du leverer til et så bredt publikum som muligt i starten.
  • Du målretter mod en bestemt demografi, der har tendens til at bruge den ene eller den anden platform.
  • Når dit design stærkt udnytter indfødte komponenter og stilarter.

Vores tanker

Hvis du vil levere en app af meget høj kvalitet, der føles mest naturlig eller tilfredsstillende for brugeren, eller du skal integrere tæt med native APIer og funktioner til begge platforme, så er native den rigtige vej. Selv hvis du forventer dette i fremtiden, bør du overveje at gøre native. Når alt går glat, er det meget dyrere at udvikle to native apps. Hvis du løber ind i en vejspærring med hensyn til, hvilke funktioner du kan oprette, er disse ofte løselige i native, mens platformoverskridende muligvis efterlader dig at rive dit hår ud.

Konklusion

På QuarkWorks, vi har erfaring med at udvikle en række teknologier på tværs af platforme såvel som vores omfattende baggrund inden for naturlig udvikling siden App Store startede.

Der er ingen ”en ægte måde”, når det kommer til udvikling af mobilapps. Til udvikling af lette prototyper og MVPer kan vi godt lide konceptet med at bruge cross-platform når det er muligt for hurtigt at få vores ideer i hænderne på det bredeste publikum. Men når vi ønsker at skabe noget til perfektion og virkelig levere den brugerkvalitetsoplevelse af højeste kvalitet, foretrækker vi stadig at gå med native-udvikling.

Vi sætter pris på de apps, der bare ”føler” sig godt, og der er ingen måde at genskabe den følelse helt den samme med teknologi på tværs af platforme i øjeblikket. Vi er begejstrede for nogle af de nye løsninger som Flutter, der sigter mod at give ikke kun en enkelt codebase til mobil, men også at kunne dele kode mellem mobil og internet. Det gør alt dette, mens det er lige så effektivt som native apps. Selvom det ikke er perfekt, ser vi det som den metaforiske Holy Grail, som industrien en dag kunne opnå.

Lige nu lover mange af disse teknologier det, men de mangler på måder, der kan blive virkelig frustrerende for arbejde igennem.

Som altid er QuarkWorks tilgængelig til at hjælpe med ethvert softwareapplikationsprojekt – web, mobil og meget mere! Hvis du er interesseret i vores tjenester, kan du tjekke vores hjemmeside .Vi vil meget gerne besvare eventuelle spørgsmål, du har! Bare kontakt os på vores Twitter , Facebook , LinkedIn eller Instagram .

QuarkWorks – Hjem

Ren, veldokumenteret og testet kode er grundlaget for ethvert vellykket projekt. Vi arbejder tæt inden for dit …

quarkworks.co