Gå till innehåll

Att välja teknik för app-projekt

20 april, 2021

Vi på Mobile Interaction arbetar i skärningspunkten mellan människa och skärm för att skapa den absolut bästa användarupplevelsen i Appformat. Vi kan hjälpa dig med alla delar av Appens livscykel; definition, produktion, launch, support, hosting och vidareutveckling. Efter snart 20 år med mobil utveckling lär vi oss fortfarande nytt varje dag eftersom det kommer nya tekniker hela tiden; låt oss dela med oss av våra insikter.     

Innan vi går in på specifika teknikval måste man inse att det finns inget facit för vilken teknik som är bäst för alla projekt utan “det beror på”. Utgångspunkten måste istället vara en serie frågeställningar som tillsammans skapar en bild, från vilken man kan ta ett informerat beslut. Det är dessa frågeställningar denna artikel försöker belysa.

Det är alltid svårt att veta vem man skall lita på när man behöver råd om teknikval. Ett klassiskt tips är att välja ett ramverk eller en teknik som organisationen har erfarenhet av. Det borgar för att man känner till flera av de styrkor och svagheter som respektive teknik har. Men ibland finns det genuint bättre teknikval för din App, vilket det är kan vi på Mobile Interaction hjälpa dig att förstå.

 

Vad är första målet med appen?

Börja med att bestämma om den första versionen av Appen skall testa ditt koncept eller om du redan är säker på att Appen gör något som användaren vill ha. Om du kommer fram till att du i första läget vill testa ditt koncept så bör du överväga att börja med en (1) plattform (Android eller iOS eller Webb). Då får du till en mindre kostnad veta om din idé flyger i din testgrupp eller om du behöver tweaka själva konceptet innan du kör på med utveckling för alla plattformar.

För vissa funktioner och krav krävs att du väljer en specifik plattform. Vill du till exempel använda telefonens sensorer såsom GPS, gyro eller kamera, eller om användarna skall kunna växla obehindrat mellan olika skärmstorlekar och desktop, kan bara vissa plattformar erbjuda det. 

Om du ser att din App kommer få många användare kommer designen att behöva mer omsorg än om det är få användare som du ska utbilda innan lansering. Vid många användare bör man även addera tex felrapportering som en funktion i appen.

En annan faktor att analysera är Appens tänka livslängd, säg att appen lyckas bra hos användarna – ska du då bekosta att skriva om all kod för att du gjort ett begränsande teknikval? Kanske är det rätt strategi, kanske inte, beroende på ditt specifika projekt.

 

Webbtjänst eller App

Sedan 2007 har vi utvecklat det vi idag kallar appar. Och ända sedan dess har diskussionen gått varm om vad som gör en app till en riktig app, och varför du behöver en app istället för bara en webbplats. Svaret är att ibland så räcker det utmärkt med bara en webb. Den stora fördelen med webben är att den fungerar på alla enheter med webbläsare, allt från telefoner till bilar. Utmaningen med webben är att du behöver bygga något som är användarvänligt i alla skärmstorlekar och webbläsare om du inte vill begränsa användarupplevelsen.   

Det har aldrig varit någon diskussion om var det är lättast att skapa en bra användarupplevelse. Att utveckla en enkel och förståelig App är lättare än att utveckla en enkel och förståelig webbplats. Punkt. 

Inom interaktionsdesign pratar man ofta om mentala modeller. Genom att använda standarder för hur man utformar sin App blir den intuitiv att använda. Inom apputveckling har Google och Apple utvecklat sina respektive standarder, sk designsystem; Material Design respektive Human Interface Guidelines. Det är dessa riktlinjer som gör att du känner på dig hur du skall agera i en ny app – baserat på hur du brukar göra i andra appar du använder på din telefon.

På webben däremot är det mycket friare hur man bör designa sin lösning, många olika upplägg är “rätt” vilket ställer stora krav på designen, särskilt för användning på små skärmar som mobiler. Det saknas också motsvarande kontroll över hur din tjänst skall bete sig på olika enheter med olika förutsättningar – tänk exemplet “att hovra för att få se mer information i en tjänst gjord för pekskärm”. 

Ett stort problem med Appar är att de måste laddas ner innan användaren kan komma igång. Apple och Google har försökt lösa detta med App-Clips respektive Instant Apps. De brukar kallas en-funktionsappar och syftar till att användaren tex kan scanna en QR-kod för att ta ett könummer. Det triggar att en minimal “App” laddas ner på telefonen och visas på skärmen. När användaren är klar med det den i exemplet köade till så raderas appen från telefonen. Apple lanserade denna funktion relativt nyligen (funktionen har funnits på Android i flera år) så det återstår att se om de blir populära nu när de kan byggas för båda de dominerande plattformarna iOS och Android.

Förutom webb, App eller en-funktionsapp så kan man välja tekniken PWA – Progressive Web App. De liknar en-funktionsappar på det sättet att funktionen är begränsad, att man inte behöver ladda ner den och att de kan nyttja telefonens kamera eller GPS, men är egentligen en paketerad webb. PWA är smidiga att bygga tekniskt om teamet är webb-fokuserat, men saknar stöd för push-meddelanden på iOS-enheter vilket många tjänster vill ha. Dessutom är användargränssnittet svårare att få App-likt och de mobila OS:ens integritetshantering stöds inte.  

Ytterligare en möjlig lösning är att bygga en Wrapper kring en webbtjänst. Det är en teknik som kapslar in en webbtjänst i en nativeförpackning. I vissa fall är detta en utmärkt lösning för att tillgängliggöra en funktion på ett kostnadseffektivt sätt, men den är ofta förknippad med stora avkall på användarvänlighet. Dessutom har Apple på senare tid ställt högre krav på att appen bidrar med app-specifika funktioner, enklare wrapperappar tillåts numera sällan att bli publicerade på Apple App Store.    

 

Native, hybrid eller multiplatform?

När du valt att göra en App (och inte en webb som visas i en webbläsare på en mobil) så är du redo för nästa val; vilken App-teknik som passar bäst för ditt projekt: Native, hybrid eller multiplatform.

 

Native

Native-appar är appar som körs direkt på enhetens OS och skrivs numera med Swift i Xcode för iOS respektive med Kotlin i Android Studio för Android och har så gjorts sedan 2008. De är överlägsna i att erbjuda bästa användarupplevelse och det finns gott om tillgänglig kompetens bland utvecklare. Varför finns det då andra ramverk och teknikval?

Det finns två lösningar på dessa utmaningar; hybrid och multiplatform. Låt oss först analysera hybrid:

 

Hybrid

För att möjliggöra att skriva webbkod (Dart/Javascript) som landar i en App så används ett abstraktionslager, där två av de mest kända teknikerna idag är React Native (skapad av Facebook) och Flutter (skapad av Google). Principen är att utvecklaren inte skall behöva hantera detaljer nere i lösningen, vilket göra att teamet kommer igång snabbare och har kortare time-to-market. Användandet av standardkomponenter och 1 kodbas i stället för två bidrar i principen till tidsvinsten.

En utmaning med Hybridlösningar/abstraktionslager är att de själva också måste underhållas. Lösningen blir beroende av att någon uppdaterar och åtgärdar fel i ramverket självt och aktuella hjälpbibliotek. Som exempel måste man vid en felsökning först säkerställa om felet ligger i abstraktionslagret eller i själva appen. Det som komplicerar det hela ytterligare är att man först i slutskedet av projektet upptäcker fel som bygger på osync mellan app och abstraktionslager. 

 

Tillgänglighet i hybrid

Om man nyutvecklar en digital lösning idag så skall den ofta uppfylla WCAG-standarden vilket tryggar att personer med nedsatt funktion kan använda appen. Det är ett EU-direktiv som ännu så länge gäller för alla offentliga organisationers nya tjänster. Standarden syftar till att alla användare skall kunna ta del av tjänsten, att göra den enkel att konsumera, så det är en stor fördel för alla användare att tjänsten byggs enligt kraven från början. Det är idag inte klarlagt i hur stor utsträckning hybridramverken tillgodoser WCAG-kraven.

 

Känslan i hybrid

Det krävs väldigt lite för att man skall känna att det känns annorlunda/ovant i en specifik app jämfört med ens andra appar. Vanligast är att mentala modellerna (Material Design, Human Interface Guidelines) inte följts. Mycket av User Interface (UI) hanteras av hybridramverket men exempelvis navigationen i appar är känd för att vålla utmaningar inom hybridutveckling: jämför exempelvis Androids sidomeny respektive flikfältet på iOS-enheter, dessutom skall de testas så att de fungerar rätt på alla enheter. Vidare så tenderar hybridappar att vara långsammare, en utmaning som blir större ju mer komplex appen är. Detta märks framförallt i uppstart varje gång användaren skall använda appen. 

 

Kompetensförsörjning i hybrid

En stor utmaning för hybridteknik är att det är ramverk som kommer (React native, Flutter) och sedan minskar i popularitet (ex Ionic, Xamarin). Det innebär att det blir svårt att bibehålla kompetens i utvecklarteamet över tid. Man behöver ställa tidsperspektivet för sin app mot detta; hur lätt kommer det vara att hitta React Native-kompetens om fem år? 

Det är också svårt att vara mästare på allt; en hybridutvecklare måste kunna lite webb, lite iOS, lite Android, lite API, ha en känsla för hur designsystemen ser ut och förändras på respektive plattform och så vidare…

 

Multiplatform

Under 2020 har JetBrains lanserat Kotlin Multiplatform Mobile, vilket numera utgör ett seriöst alternativ till plattformsspecifik nativeutvecklig och hybridtekniker för appar som skall finnas på både webb, Apple App Store och Google Play Store. 

Tekniken bygger på separation av logik och UI, där logiken blir gemensam resurs och UI:t görs separat för Android respektive iOS. Logiken skrivs i Kotlin vilket är språket som för alla moderna Androidapplikationer, alla vyer (det som användarna ser) skrivs med native-kod.

 

 

Utmaningen med tekniken är att få utvecklare ännu så länge har kunskap om tekniken, och än färre har erfarenhet. Vidare så är communityn runt Kotlin Native ännu inte så stor, dvs svårt att få hjälp om man kör fast. Dessutom triggar uppdelningen av utvecklingsprojektet i logik / UI i stället för iOS/Android en annan styrning av utvecklingsprojektet och i förlängningen kanske annorlunda roller i teamet; logikutvecklare, iOS-UI-utvecklare och Android-UI-utvecklare?

Fördelarna med Kotlin Multiplatform är framförallt lägre kostnad för beställare jämfört med ren nativeutveckling, en renare felsökning, tillgång till alla native-features och att UI/designsystemen klarar WCAG-kraven.     

Vi har ännu inte identifierat något motsvarande ramverk som bygger på ren Swift/iOS-kod och som sedan kombineras med UI för Android.

 

Summering 

Applandskapet förändras. Med “Kotlin Multiplatform Mobile” kan vi återanvända stora delar av affärslogiken mellan plattformarna. Detta utan att tvingas kompromissa med användargränssnittet, prestandan eller känslan i apparna då UI implementeras med plattformsspecifika komponenter på respektive plattform. Priset vi betalar för detta är att vi jobbar med en ung teknik med allt vad det innebär.

Den största fördelen med hybrid-ramverk som React Native eller Flutter; att de sparar pengar, utmanas med Kotlin Multiplatform Mobile, dels genom en renare uppdelning som förenklar felsökning, dels genom att på riktigt ha en (1) kodbas. 

En tjänst på webben har fördelen att användare inte måste ladda ner en app och att den fungerar på alla plattformar. Främsta nackdelarna är att det är svårt att hitta en bra design för alla skärmstorlekar och att viss funktionalitet inte kan byggas så som i en app. 

Är då Kotlin Multiplatform Mobile svaret på allt? Nej, svaret är fortfarande att det beror på det specifika caset. Med utgångspunkt från svaren på frågorna nedan kan man i många fall definiera vilken teknisk lösning som passar för just din tjänst:

 

  1. Vad är appens tänkta livslängd och uppskattat antal användare?
  2. Vilka krav finns på design och tillgänglighet?
  3. Är appen tekniskt komplex och kräver integrationer mot andra system eller hårdvara?
  4. Vilken teknisk kunskap finns i förvaltningsorganisationen?
  5. Är appen du vill bygga ett provskott, PoC, MVP-app eller en helt färdig produkt?
  6. Skall appen vara tillgänglig på Apple App Store, Google Play Store, på webben eller alla tre? 

 

Tillbaka till nyheter

Se flera nyheter