Nya OS-versioner varje år – vad kräver det av din app?

En app är inte en produkt du bygger färdigt en gång. iOS och Android släpper nya versioner varje år, och marken under appen rör sig hela tiden. Många beställare budgeterar för bygget men glömmer det löpande underhåll som krävs bara för att appen ska fortsätta fungera. Här är den årliga cykeln du behöver planera för – och varför den förtjänar en egen rad i budgeten.

Butikernas krav på målversion – och vad som händer om du halkar efter

Både Apple och Google kräver att nya uppladdningar byggts mot en någorlunda färsk version av operativsystemet. På Android uttrycks det som ett lägsta target API level, på iOS som motsvarande SDK-krav. Kravet höjs varje år, ungefär ett år efter att en ny OS-version släppts.

Konsekvensen av att ligga kvar på gammalt är konkret och tråkig: når appen inte upp till kravet kan du inte längre publicera uppdateringar. Du kan alltså inte rätta buggar, inte täppa säkerhetshål, inte lägga till något. Befintliga användare kan ofta ha kvar appen ett tag, men den blir ett fruset skepp du inte längre kan styra. Att ta sig ur det läget kräver oftast ett större tekniskt omtag – dyrare än om appen hållits à jour hela vägen.

Ett årshjul för teknisk följsamhet

Underhållet blir hanterbart om det planeras som ett återkommande hjul snarare än en överraskning varje höst. Grovt ser året ut så här:

Kärnan är sommartestningen. När betaversionerna finns ute kan teamet köra appen mot dem och upptäcka det som annars hade slagit till samtidigt som miljontals användare uppdaterar i oktober. Det förvandlar höstsläppet från en brandkårsutryckning till en planerad punkt i kalendern.

Ett konkret räkneexempel

Säg att du lanserade en app för två år sedan och sedan lät den vara. Den fungerar fortfarande – tills en användare med en ny telefon hör av sig om att inloggningen kraschar. Ni tittar och upptäcker att autentiseringsbiblioteket inte längre stöds, att appen dessutom ligger under årets krav på målversion, och att ni därför inte ens kan ladda upp en fix utan att först uppgradera flera underliggande delar. Det som kunde varit några timmar per år har blivit ett projekt på flera veckor. Poängen: teknisk följsamhet är billig löpande och dyr att skjuta upp.

En egen budgetpost, skild från nyutveckling

Det vanligaste misstaget är att slå ihop underhåll med nyutveckling i samma pott. Då förlorar underhållet varje gång, för nya funktioner känns alltid mer angelägna än att hålla det som redan finns igång. Resultatet blir en app som sakta halkar efter tills den plötsligt inte går att uppdatera.

Håll därför isär två saker i budgeten. Teknisk följsamhet ser till att appen fortsätter fungera på nya OS och enheter – användaren märker sällan något, och det är själva poängen. Nyutveckling lägger till värde ovanpå. En vanlig tumregel är att räkna 15–25 procent av den ursprungliga utvecklingskostnaden per år för löpande förvaltning, där följsamheten är en del. Genom att ge den en egen rad ser du till att den faktiskt blir utförd.

Vad som konkret slutar fungera om du väntar

Det abstrakta “appen halkar efter” blir tydligare med exempel på vad som faktiskt går sönder. Behörigheter och integritetsregler skärps nästan varje år – en ny OS-version kan kräva att appen frågar om åtkomst på ett nytt sätt, och gör den inte det slutar en funktion att fungera. Tredjepartstjänster för betalning, kartor eller inloggning uppdaterar sina bibliotek, och en app som inte följer med tappar den funktionen. Nya skärmstorlekar och enheter kan bryta layouten om appen byggdes mot gårdagens format.

Inget av detta sker på lanseringsdagen. Det smyger sig på, en bit i taget, tills tillräckligt mycket gått sönder för att en användare hör av sig – och då är felen ofta flera samtidigt. Det är just därför löpande, planerad följsamhet är billigare än att vänta tills något tvingar fram ett stort omtag.

Vill du veta hur ett förvaltningsupplägg kan se ut för just din app, titta på våra tjänster eller hör av dig så skissar vi på en plan.