Hur kommer man igång med Kotlin Multiplatform Mobile? (KMM)

Kanske har tekniken skymtat förbi någonstans när du hängt på webben. Kanske har du läst våra tidigare artiklar? Vi pratar såklart om Kotlin Multiplatform Mobile. Sedan en tid tillbaka har vi på Mobile Interaction pratat om KMM rätt flitigt eftersom vi är så övertygade om kraften i ramverket. Och så har vi dessutom lanserat ett helt gäng appar byggda med KMM-teknik, så vi VET vad vi pratar om. Anledningarna till att vi använder KMM är många, men de främsta är tidsbesparing och kvalitén. Med KMM kan vi nämligen återanvända stora delar av bakomliggande affärslogik och kod när vi utvecklar appar till både Android och iOS.

Den här artikeln handlar om femstegsraketen för att komma igång med KMM om man redan har en eller flera appar som snurrar. Det kallar vi för KMM Transformation. Precis som alla viktiga resor så börjar även denna resan med att ta ett första steg. Men mer om det snart.

Cross-plattform har dåligt rykte. Med rätta. Genom åren har många tekniker lovat guld och gröna skogar i form av en (1) kodbas med mera; men levererat en låg användarupplevelse eller en mycket komplicerad miljö att förvalta och vidareutveckla. Med KMM skriver vi Kotlinkod (vilket är samma teknik som för alla moderna Androidappar) och vi bygger användargränssnittet i native (SwiftUI/JetpackCompose, precis som i alla moderna appar). Och vi har en (1) kodbas. Det betyder att samma app-scope kostar 30-50% mindre. Och kvalitén ökar då vi kan skriva fler tester och dessutom lägger all logik på ett ställe…och så vidare.

Men nu sitter du och invänder att det går ju inte att bara slänga all kod som man investerat tungt i bara för att börja om från blankt papper med KMM. Jag håller med.

Tillbaka till att alla resor börjar med att ta ett första steg. En bra början är att bygga din nästa funktion i din befintliga app i KMM. Det kan vara exempelvis en inloggningsskärm eller en inställningssida. Bara något litet att börja med. Så du får smaka på KMM i sig, men också på hur KMM jackar in i just DIN befintliga kodbas.

Nu till femstegsraketen för att snurra in KMM i dina appar!

(1) Skapa en lägesbild

Gör en inventering av vad du har i dagsläget. Har du exempelvis redan två separata appar, en för Android och en för iOS? Eller har ni redan en för Android och planerar att skapa en för iOS?

Det du behöver få koll på är:

Vilken typ av app är det? Har din app mycket affärslogik, regler och olika API:er? Eller är det en enklare app med mindre logik och mer UI (typ en app som typ visar en/flera webbsidor) Ju fler regler, API:er etc desto större möjlighet att återanvända kod = desto större nytta med KMM.
Vilken teknikstack har ni? Kotlin i backend? Mest webbappar? Vilka är era mål-devicer? (skärmstorlekar mm)
Finns det tillräcklig/rätt kompetens i teamet? Även om vi på Mobile Interaction tycker att alla borde lära sig KMM så måste ju nyttan överväga tröskeln man behöver ta sig över. Ni behöver mest troligt lära er några nya saker samt att tänka på ett litet annat sätt om ni skall igång med KMM. Det tar ett par tre veckor för en senior Andriodutvecklare att greppa, och troligen lite längre för iOS-experter.

Med denna nyvunna överblick över situationen har du förhoppningsvis förutsättningar för peka ut vart du ska gräva vidare!

(2) Definiera första lämpliga funktion

När du vet hur situationen ser ut just nu kan du börja fundera på nästa steg. Och då finns det olika vägar att välja. Antingen tar man en existerande funktion som redan finns för båda plattformar och gör om den till KMM. Eller så använder du dig av KMM när du ska bygga din nästa funktion. Funktionen behöver ha lagom omfattning, med någon typ av backend–anrop och logik som går att återanvända. Den ska även gå att kapsla in så att inte resten av appen beror på just den funktionen.

Med “funktion” menas t.ex. en ytterligare skärm som man kan navigera till i appen. En funktion löser ett nytt problem. Exempelvis “visa på karta” om du tidigare bara har kunnat “visa i lista”.

(3) Kompetensutveckling

För att ditt team ska kunna göra sitt jobb behöver de rätt kompetens och resurser. Att börja med något nytt, vad det än är, kräver att man lägger tid och engagemang. Dels för att lära sig, men även för att börja tänka på ett annat sätt.

När det gäller KMM har utvecklare som redan programmerat för Android försprång. Men internet är så gott som översvämmat av källor för kunskap. Kotlins egna kunskapsbank, stackoverflow som är go-to community för utvecklare, och mängder av andra tutorials. Och såklart, icke att förglömma, konsultbolags kunskaper inom olika områden.

(4) Arkitektur och affärsbehov

När man ska fundera över framtiden för sin app är det bra att göra en scenarioplanering och lyfta blicken till affären som helhet. Genom att förstå ditt företags affärsstrategi ordentligt, innan du börjar med utvecklingen, kan du lättare sätta KMM–utvecklingen i kontext till affärsmålen. Det gör att du får tydligare ramar, och lättare kan avgöra storleken på ditt KMM utvecklingsprojekt.

För att få denna förståelse så kan du utgå från dessa frågor om din organisation:

Hur ser roadmappen för appen ut över tid?

Är målet att hela appen tillslut ska migreras till KMM?

Ska alla nya och tillkommande funktioner byggas i KMM och de som redan är byggda fortsätta vara native?

Kommer er affärsstrategi kräva fler komplexa funktioner i framtiden? Är det viktigt att ha en snabb process mellan marknad och utveckling? Kanske kan KMM vara byggstenen som gör att cheferna låter apputvecklingen ligga kvar i Sverige, nära affären, istället för att överväga låg-kostnadsländer?

Vår rekommendation är att börja implementera KMM i nya funktioner som byggs i er app, och sedan noga utvärdera utfallet, för att först därefter göra ett större projekt med att lyfta över allt till KMM. Tänk hur Cloud gått från att vara nått litet till att vara det nya normala för de flesta verksamheter, vartefter hinder har identifierats har de hanterats när nyttan överstigit kostnaden.

(5)Team-sammansättning och arbetssätt

Så som det ofta ser ut idag är att man arbetar i två olika team, ett för iOS- och ett för Android. När man börjar arbeta med KMM förskjuts gränserna lite och det kommer behövas en omorganisering i teamen. Det finns såklart många olika sätt att organisera på, men det som ska göras är:

Affärslogik (KMM)
Native Android UI
Native iOS UI

Det leder till att teamen kan, och kommer behöva, jobba mer tillsammans. De kan dela kunskap vilket ger mer möjlighet till bredare diskussioner i teamet om lösningar. Däremot kommer det såklart fortfarande att behövas expertkunskaper inom alla områden.

Teststrategi

När man endast har en kodbas för logiken så har man större möjligheter att effektivisera testningen.

Roadmap mot full KMM!

Nu har vi pratat om att utvidga en existerande app med en eller flera KMM-moduler som ligger lite vid sidan av. Då är nästa steg att slå ihop alla delar och bygga om de bitar som inte är isolerade, det vill säga de bitar som inte är inte enskilda funktioner, utan själva kärnan i appen. Kanske göra så att hela navigationslogiken eller nätverkslagret är i KMM. Det blir ett större projekt som mer handlar om att bygga om mer än att bygga nytt.

Det kommer alltid vara jobbigt att skriva om saker, men se det som en möjlighet att städa upp i koden. Det är även en möjlighet att inventera koden. Då ser vi alla misstag, vi ser vilka delar som är gemensamma, och vi ser alla tester som aldrig skrevs… Men det är när man gjort hela resan till KMM som den verkliga affärsmöjligheten uppstår – att både bygga och lansera nya funktioner effektivt, förvaltningsbart och med kvalité!

Lycka till!

Marcus Ödling