Cross-Platform vs. native native apps

(Jacob Muchow ) (15. okt 2020)

Design av

Introduksjon

Apper på tvers av plattformer har blitt en go-to-market-løsning for mange nystartede selskaper i teknologibransjen. De lover å være i stand til enkelt å skrive en kodebase som distribueres til både iOS- og Android-enheter. Imidlertid velger mange selskaper fremdeles å gå den tradisjonelle ruten og utvikle seg til tross for potensielle fordeler.

Begge løsningene er gyldige – det er ikke en eneste “riktig” måte å gjøre ting på (i det minste ikke ennå! ). Å velge riktig vei fremover for teamet ditt avhenger av dine mål og begrensninger, og ditt valg innen teknologi bør komme fra det mer enn en personlig tro. Dette innlegget vil trekke en sammenligning mellom de to alternativene for å hjelpe deg med å ta den beste avgjørelsen for din bedrift.

Tverrplattform

For tiden er det flere konkurrerende alternativer for utvikling på tvers av plattformer : React Native, Flutter, Xamarin, Ionic for å nevne de vanlige. I dette innlegget skal vi unngå å forklare hver enkelt og diskutere fordeler / ulemper med utvikling av plattformer som helhet.

Hver av disse plattformene lar teamet ditt skrive koden for en app, som kan distribueres til både Google Play Store og App Store. Kostnadsbesparelsespotensialet med dette er åpenbart stort hvis det gjøres effektivt.

Fordeler med plattformoverskridende

  • Det er mulig å levere til begge mobilmarkedene med et langt mindre budsjett enn det ville ta to å utvikle to separate native apps. Cirka 60–70\% av koden kan deles, mens resten er tilpasset begge plattformene.
  • Du kan ha et enkelt mobilutviklingsteam som forenkler organisasjonen din. Dette kan også være til nytte for å gi noen sammenheng i Android- og iOS-appene dine som det ellers er vanskelig å oppnå.
  • Avhengig av valgt teknologi, kan det hende du har utviklere som allerede er kjent med språk og utviklingsstiler. (JavaScript, C # /. NET, Dart). Du kan kanskje bygge et team uten å måtte begynne å ansette fra grunnen av.
  • Nye funksjoner distribueres til dine iOS- og Android-brukere samtidig, i stedet for å ha en «funksjonsleder».

Ulemper med plattformoverskridende

  • Det er mye vanskeligere å ansette utviklere som har erfaring med denne teknologien sammenlignet med native.
  • Når du gjør det treffer en veisperring, tar det ofte en veldig dyktig ingeniør å løse problemet.
  • iOS- eller Android-spesifikke funksjoner (f.eks. Health Kit / Apple Watch) er ekstremt vanskelige eller umulige å jobbe med.
  • Å utvikle intrikate UI / UX tar mye lenger tid enn Native. Hvis det ikke er en out-of-the-box-komponent, må det opprettes en egendefinert for begge plattformene som er tidkrevende.
  • Tverrplattform er ofte ikke så effektiv som Native, og forårsaker noen ganger noe jank som egentlig ikke kan løses. Dette har større innvirkning jo mer kompleks applikasjonen din er.
  • Teknologiene har mindre modne økosystemer enn innfødte. Dette betyr mindre verktøy for teamet ditt å bruke og mindre hjelp tilgjengelig når de får problemer.
  • Appene «føles» ikke som iOS- eller Android-apper. De skaper ukjente opplevelser for brukeren, noe som kan gjøre at appen føles uattraktiv.
  • Det er risiko for at den valgte teknologien dør ut og mister støtte fra fellesskap, skapere eller selskap.

Når det er fornuftig å bruke flere plattformer

  • Du vil målrette både Android- og iOS-markedet for MVP.
  • Begrenset budsjett for mobil er et av dine primære begrensninger.
  • Mobilappen din er ikke en sentral del av virksomheten din.
  • Brukeropplevelsen bør være standard mellom appene dine, og du ønsker ikke å «føle» deg som en iOS eller Android app.
  • Søknaden din er grei når det gjelder brukeropplevelse og funksjoner.
  • Designene dine er nesten identiske på begge plattformene.

Våre tanker

Tverrplattformsteknologier er en fin måte å raskt markedsføre for et bredest mulig publikum og validere ideen din. Hvis appen din ikke krever plattformspesifikke teknologier, intrikate UI / UX eller kompleks forretningslogikk, bør du sterkt vurdere å gå med en plattformløsning. Etter MVP, dette kan tillate deg å fokusere på produkt iterasjon helt, mens å gå native kan bety at du må vurdere å bygge et helt nytt team / app for iOS eller Android. Innfødte kan alltid komme senere om nødvendig.

Innfødt utvikling

«Innfødt» utvikling refererer til den tradisjonelle stilen for å utvikle en hel applikasjon ved hjelp av førstepartsverktøyene levert av Apple og Google for iOS. og Android.Økosystemene har utviklet seg, men i dag er industristandarden å bruke Android Studio & Kotlin-programmeringsspråket for Android, og Xcode & Raskt programmeringsspråk for iOS.

Denne tilnærmingen krever at du har to separate kodebaser for hver app. Teamene vil vanligvis ha ingeniører som fokuserer på den ene plattformen eller den andre, eller noen ganger har to helt separate utviklingsteam for hver plattform.

Mange ganger vil selskaper gi ut appen sin enten til App Store eller Google Play først og fokusere på å gjenta produktet. Hvis levering av appen på den andre plattformen er en del av strategien deres, når de har trekkraft eller suksess og nok finansiering, vil de investere i å bygge et team for å håndtere den andre plattformen.

Fordeler for naturlig utvikling

  • Apper kan dra nytte av alle iOS- eller Android-spesifikke funksjoner.
  • Brukeropplevelsen kan skreddersys i større eller mindre grad til det en iOS- eller Android-bruker forventer.
  • Tilpasset, intrikat brukergrensesnitt er mye lettere å utvikle generelt.
  • Hvis det er kompleks bakgrunnsbehandling, vil det kjøre jevnere enn plattform på grunn av tekniske begrensninger.
  • Innfødte apper gjort bra, «føler seg bedre» på en måte som apper på tvers av plattformer ikke er i stand til akkurat nå.
  • Det følgende teamet ditt skal være i stand til å innhente ditt første lag ganske raskt. De trenger ikke å gjennomgå de samme feilene og læringene som førstelaget gjorde.
  • Når det gjelder arbeidsmarkedet, er det mange flere utviklere som har erfaring med utvikling av iOS eller Android. Ansettelsene dine vil være mye enklere.
  • Verktøyene og fellestøtten er utviklet siden starten av mobilapper og er langt mer robuste og modne.
  • Hvis du kan forestille deg det, det kan ofte gjøres 99\% av tiden.

Ulemper med naturlig utvikling

  • Det kan være veldig dyrt å finansiere native apps for både iOS og Android .
  • Du trenger i hovedsak to team verdt av utviklere for å levere til begge.
  • Følgende plattform henger ofte etter når det gjelder funksjoner, og det kan være vanskelig å oppnå paritet.
  • Det er utfordrende å oppnå samhørighet mellom iOS- og Android-appene og teamene.

Når det er fornuftig å bli hjemme

  • Du bryr deg dypt om en finjustert, høy kvalitet eller imponerende brukeropplevelse.
  • Du vil dra nytte av plattformfunksjoner (f.eks. Health Kit / Apple Watch-integrering).
  • Du har beregningsintensive funksjoner i tankene, for eksempel video eller live streaming.
  • Det er ikke hei veldig viktig at du leverer til et bredest mulig publikum til å begynne med.
  • Du målretter mot en spesifikk demografi som har en tendens til å bruke den ene eller den andre plattformen.
  • Når designene dine sterkt utnytter innfødte komponenter. og stiler.

Våre tanker

Hvis du vil levere en app av meget høy kvalitet som føles mest naturlig eller tilfredsstillende for brukeren, eller du må integrere tett med innebygde APIer og funksjoner for begge plattformene, så er native veien å gå. Selv om du forventer dette i fremtiden, bør du vurdere å gjøre innfødt. Når alt går greit, er det mye dyrere å utvikle to innfødte apper. Hvis du støter på en veisperring når det gjelder hvilke funksjoner du kan opprette, er de ofte løsbare på innfødte, mens plattform på tvers kan føre til at du river håret ut.

Konklusjon

På QuarkWorks, vi har erfaring med å utvikle en rekke teknologier på tvers av plattformer, så vel som vår omfattende bakgrunn innen naturlig utvikling siden begynnelsen av App Store.

Det er ingen «en sann måte» når det gjelder utvikle mobilapper. For å utvikle lette prototyper og MVP-er, liker vi konseptet med å bruke plattform på tvers når det er mulig for å få ideene våre raskt i hendene på det bredeste publikum. Men når vi ønsker å skape noe til det perfekte og virkelig levere den brukeropplevelsen av høyeste kvalitet, foretrekker vi fortsatt å bruke naturlig utvikling.

Vi setter pris på appene som bare «føles» bra og det er ingen måte å gjenskape den følelsen ganske likt med plattformteknologi for tiden. Vi er glade for noen av de nye løsningene som Flutter, som har som mål å gi ikke bare en enkelt kodebase for mobil, men også å kunne dele kode mellom mobil og nett. Det gjør alt dette mens det er like effektivt som innfødte apper. Selv om det ikke er perfekt, ser vi det som den metaforiske Holy Grail som industrien en dag kan oppnå.

Akkurat nå lover mange av disse teknologiene det, men kommer til kort på måter som kan bli veldig frustrerende for jobbe deg gjennom.

Som alltid er QuarkWorks tilgjengelig for å hjelpe deg med ethvert programvareprosjekt – nett, mobil og mer! Hvis du er interessert i tjenestene våre, kan du sjekke ut nettstedet .Vi vil gjerne svare på spørsmål du har! Bare kontakt oss på Twitter , Facebook , LinkedIn , eller Instagram .

QuarkWorks – Hjem

Ren, veldokumentert og testet kode er grunnlaget for hvert vellykket prosjekt. Vi jobber tett i ditt…

quarkworks.co