Cross-Platform vs. Native Mobile Apps (Svenska)

(Jacob Muchow ) (15 okt 2020)

Design av

Inledning

Plattformsappar har blivit en go-to-market-lösning för många nystartade företag inom teknikbranschen. De lovar att enkelt kunna skriva en kodbas som distribueras till både iOS- och Android-enheter. Men många företag väljer fortfarande att gå den traditionella vägen och utveckla sig naturligt trots de potentiella fördelarna.

Båda lösningarna är giltiga – det finns inte ett enda “rätt” sätt att göra saker (åtminstone inte ännu! ). Att välja rätt väg framåt för ditt team beror på dina mål och begränsningar, och ditt val inom teknik bör komma från det mer än en personlig tro. Det här inlägget gör en jämförelse mellan de två alternativen som hjälper dig att fatta det bästa beslutet för ditt företag.

Tvärplattform

För närvarande finns det flera konkurrerande alternativ för plattformsutveckling : React Native, Flutter, Xamarin, Ionic för att nämna de vanliga. I det här inlägget kommer vi att undvika att förklara var och en och diskutera fördelar / nackdelar med plattformsutveckling som helhet.

Var och en av dessa plattformar gör att ditt team kan skriva koden för en app, som kan distribueras till både Google Play Store och App Store. Kostnadsbesparingspotentialen för detta är uppenbarligen enormt om det görs effektivt.

Fördelar med plattformar

  • Det är möjligt att leverera till båda mobilmarknaderna till en mycket mindre budget än det skulle ta två att utveckla två separata inbyggda appar. Cirka 60–70\% av koden kan delas med att resten är anpassad för båda plattformarna.
  • Du kan ha ett enda mobilutvecklingsteam som förenklar din organisation. Detta kan också gynna att skapa en viss sammanhållning i dina Android- och iOS-appar som annars är svåra att uppnå.
  • Beroende på vald teknik kan du ha utvecklare som redan känner till språk och utvecklingsstilar (JavaScript, C # /. NET, Dart). Du kanske kan bygga ett team utan att behöva börja anställa från grunden.
  • Nya funktioner distribueras till dina iOS- och Android-användare samtidigt, snarare än att ha en ”funktionsledare”.

Nackdelar med plattformar

  • Det är mycket svårare att anställa utvecklare som har erfarenhet av denna teknik jämfört med native.
  • När du gör träffar en vägspärr krävs det ofta en riktigt skicklig ingenjör för att lösa problemet.
  • iOS- eller Android-specifika funktioner (t.ex. Health Kit / Apple Watch) är extremt svåra eller omöjliga att arbeta med.
  • Att utveckla invecklad UI / UX tar mycket längre tid än Native. Om det inte finns en out-of-the-box-komponent måste en egen skapas för båda plattformarna vilket är tidskrävande.
  • Plattformsöverskridande är ofta inte lika effektivt som Native, vilket ibland orsakar någon jank som inte riktigt kan lösas. Detta har större inverkan ju mer komplex din applikation är.
  • Teknikerna har mindre mogna ekosystem än inhemska. Det betyder färre verktyg för ditt team att använda och mindre hjälp tillgänglig när de stöter på problem.
  • Apparna känns inte som iOS- eller Android-appar. De skapar okända upplevelser för användaren, vilket kan göra att appen känns oattraktiv.
  • Det finns risk för att den valda tekniken dör ut och förlorar support från community, skapare eller företag.

När det är vettigt att använda plattformar

  • Du vill rikta in både Android- och iOS-marknader för din MVP.
  • Begränsad budget för mobil är en av dina primära begränsningar.
  • Din mobilapp är inte en viktig del av ditt företag.
  • Användarupplevelsen bör vara standard mellan dina appar och du vill inte ”känna” dig som en iOS eller Android app.
  • Din applikation är enkel när det gäller användarupplevelse och funktioner.
  • Dina mönster är nästan identiska på båda plattformarna.

Våra tankar

Tvärplattformsteknik är ett utmärkt sätt att snabbt komma ut på marknaden för en så bred publik som möjligt och validera din idé. Om din app inte kommer att kräva plattformsspecifik teknik, invecklad UI / UX eller komplex affärslogik bör du starkt överväga att gå med en plattformslösning. Efter MVP, kan detta låta dig fokusera helt på produkt iteration, medan att gå native kan innebära att du måste överväga att bygga ett helt nytt team / app för iOS eller Android. Native kan alltid komma senare om det behövs.

Native Development

”Native” -utveckling hänvisar till den traditionella stilen för att utveckla en hel applikation med de första partverktygen som tillhandahålls av Apple och Google för iOS och Android.Ekosystemen har utvecklats, men idag är industristandarden att använda Android Studio & Kotlin-programmeringsspråket för Android, och Xcode & Snabbt programmeringsspråk för iOS.

Detta tillvägagångssätt kräver att man har två separata kodbaser för varje app. Team har vanligtvis ingenjörer som fokuserar på en eller annan plattform, eller ibland har två helt separata utvecklingsteam för varje plattform.

Många gånger kommer företag att släppa sin app antingen till App Store eller Google Play först och fokusera på iterering på produkten. Om att leverera appen på den andra plattformen är en del av deras strategi, så snart de har dragkraft eller framgång och tillräckligt med finansiering, kommer de att investera i att bygga ett team för att hantera den andra plattformen.

Fördelar med naturlig utveckling

  • Appar kan dra nytta av alla iOS- eller Android-specifika funktioner.
  • Användarupplevelsen kan skräddarsys i mer eller mindre grad till vad en iOS- eller Android-användare förväntar sig.
  • Anpassat, invecklat användargränssnitt är mycket lättare att utveckla generellt.
  • Om det finns komplex bakgrundsbehandling kommer det att gå smidigare än plattformsplattform på grund av tekniska begränsningar.
  • Inbyggda appar gjort bra ”må bättre” på ett sätt som plattformsappar inte kan just nu.
  • Ditt följande team borde kunna komma ikapp ditt första lag ganska snabbt. De kommer inte att behöva gå igenom samma misstag och lärdomar som första laget gjorde.
  • När det gäller arbetsmarknaden finns det många fler utvecklare som har erfarenhet av utveckling av iOS eller Android. Din anställning kommer att bli mycket enklare.
  • Verktygen och gemenskapsstöd har utvecklats sedan starten av mobilappar och är mycket mer robusta och mogna.
  • Om du kan föreställa dig det, det kan ofta göras 99\% av tiden.

Nackdelar med naturlig utveckling

  • Det kan vara mycket dyrt att finansiera inbyggda appar för både iOS och Android .
  • Du behöver i princip två utvecklarvärden för att leverera till båda.
  • Följande plattform saknar ofta efter när det gäller funktioner och det kan vara svårt att uppnå paritet.
  • Det är utmanande att uppnå sammanhållning mellan iOS- och Android-appar och -lag.

När det är vettigt att bli hemma

  • Du bryr dig djupt om en finjusterad, högkvalitativ eller imponerande användarupplevelse.
  • Du vill dra nytta av plattformsfunktioner (t.ex. Health Kit / Apple Watch-integration).
  • Du har beräkningsintensiva funktioner i åtanke som video eller direktuppspelning.
  • Det är inte hej väldigt viktigt att du levererar till en så bred publik som möjligt först.
  • Du riktar dig mot en specifik demografi som tenderar att använda den ena eller den andra plattformen.
  • När din design kraftigt utnyttjar inbyggda komponenter. och stilar.

Våra tankar

Om du vill leverera en mycket högkvalitativ app som känns som den mest naturliga eller tillfredsställande för användaren, eller om du behöver integrera nära med inbyggda API: er och funktioner för båda plattformarna, då är native vägen att gå. Även om du förväntar dig detta i framtiden bör du överväga att göra native. När allt går smidigt är det mycket dyrare att utveckla två inbyggda appar. Om du stöter på en vägspärr i termer av vilka funktioner du kan skapa, är de ofta lösbara på infödda, medan plattformsövergripande kan göra att du sliter håret.

Slutsats

Vid QuarkWorks, vi har erfarenhet av att utveckla en mängd plattformsöverskridande teknologier samt vår omfattande bakgrund inom naturlig utveckling sedan App Store startade.

Det finns inget ”ett riktigt sätt” när det gäller utveckla mobilappar. För att utveckla lätta prototyper och MVP: er gillar vi konceptet att använda plattformar när det är möjligt för att snabbt få våra idéer i händerna på den bredaste publiken. Men när vi vill skapa något till perfektion och verkligen leverera den högsta kvaliteten på användarupplevelsen, föredrar vi fortfarande att gå med inbyggd utveckling.

Vi uppskattar apparna som bara “känns” bra och det finns inget sätt att återskapa den känslan på samma sätt med plattformsteknik för närvarande. Vi är glada över några av de nya lösningarna som Flutter, som syftar till att inte bara tillhandahålla en enda kodbas för mobil utan också att kunna dela kod mellan mobil och webb. Det gör allt detta samtidigt som det är lika effektivt som inbyggda appar. Även om det inte är perfekt, ser vi att det är den metaforiska Holy Grail som industrin en dag skulle kunna uppnå.

Just nu lovar många av dessa teknologier det, men det saknas på sätt som kan bli riktigt frustrerande för arbeta igenom.

Som alltid finns QuarkWorks tillgängliga för att hjälpa till med alla programvaruprojekt – webb, mobil och mer! Om du är intresserad av våra tjänster kan du kolla in vår webbplats .Vi vill gärna svara på alla frågor du har! Kontakta oss bara på vår Twitter , Facebook , LinkedIn eller Instagram .

QuarkWorks – Hem

Ren, väldokumenterad och testad kod är grunden för varje framgångsrikt projekt. Vi arbetar nära ditt …

quarkworks.co