Nye OS-versjoner hvert år: Hva krever det av appen din?
iOS og Android slipper nye versjoner hvert år, og det krever løpende vedlikehold av appen. Butikkene hever kravet til laveste målversjon, eldre API-er fases ut, og funksjoner slutter å virke hvis du ikke følger med. Regn med en årlig budsjettpost for teknisk vedlikehold, atskilt fra nyutvikling. Ellers blir appen etter hvert umulig å oppdatere eller i det hele tatt installere.
En app er ikke et produkt du bygger ferdig én gang. iOS og Android slipper nye versjoner hvert år, og grunnen under appen flytter seg hele tiden. Mange som får laget en app, budsjetterer for utviklingen, men glemmer det løpende vedlikeholdet som kreves bare for at appen skal fortsette å fungere. Her er den årlige syklusen du må planlegge for, og hvorfor den fortjener en egen linje i budsjettet.
Butikkenes krav til målversjon, og hva som skjer hvis du henger etter
Både Apple og Google krever at nye opplastinger er bygget mot en noenlunde fersk versjon av operativsystemet. På Android uttrykkes det som et laveste target API level, på iOS som tilsvarende SDK-krav. Kravet heves hvert år, omtrent ett år etter at en ny OS-versjon er sluppet.
Konsekvensen av å bli liggende på en gammel versjon er konkret og kjedelig: Når appen ikke oppfyller kravet, kan du ikke lenger publisere oppdateringer. Du kan altså ikke rette feil, ikke tette sikkerhetshull, ikke legge til noe. Eksisterende brukere kan ofte beholde appen en stund, men den blir et frosset skip du ikke lenger kan styre. Å komme seg ut av den situasjonen krever som regel et større teknisk løft, og det blir dyrere enn om appen hadde vært holdt à jour hele veien.
Et årshjul for teknisk vedlikehold
Vedlikeholdet blir håndterbart hvis det planlegges som et årshjul som går igjen, snarere enn som en overraskelse hver høst. Grovt sett ser året slik ut:
| Periode | Hva som skjer |
|---|---|
| Vår–sommer | Apple og Google viser neste OS og slipper betaversjoner |
| Sommer | Test appen mot betaversjonene, finn og rett problemer i god tid |
| Høst | Endelige OS-lanseringer: Verifiser at appen fungerer for brukere som oppdaterer |
| Løpende | Juster når enkelte biblioteker, SDK-er eller tjenester endres |
Kjernen er sommertestingen. Når betaversjonene er ute, kan teamet kjøre appen mot dem og oppdage det som ellers ville ha dukket opp akkurat når millioner av brukere oppdaterer i oktober. Det forvandler høstlanseringen fra en brannutrykning til et planlagt punkt i kalenderen.
Et konkret regneeksempel
Si at du lanserte en app for to år siden og deretter lot den være. Den fungerer fortsatt helt til en bruker med ny telefon tar kontakt og sier at innloggingen krasjer. Dere ser på det og oppdager at autentiseringsbiblioteket ikke lenger støttes, at appen i tillegg ligger under årets krav til målversjon, og at dere derfor ikke engang kan laste opp en rettelse uten først å oppgradere flere underliggende deler. Det som kunne vært noen timer i året, har blitt et prosjekt på flere uker. Poenget: Teknisk vedlikehold er billig løpende og dyrt å utsette.
En egen budsjettpost, atskilt fra nyutvikling
Den vanligste feilen er å slå sammen vedlikehold og nyutvikling i samme pott. Da taper vedlikeholdet hver gang, for nye funksjoner føles alltid mer presserende enn å holde i gang det som allerede finnes. Resultatet blir en app som sakte henger etter til den plutselig ikke kan oppdateres.
Hold derfor to ting atskilt i budsjettet. Teknisk vedlikehold sørger for at appen fortsetter å fungere på nye OS og enheter. Brukeren merker sjelden noe, og det er nettopp poenget. Nyutvikling tilfører verdi på toppen. En vanlig tommelfingerregel er å regne 15–25 prosent av den opprinnelige utviklingskostnaden per år til løpende forvaltning, der det tekniske vedlikeholdet inngår. Ved å gi det en egen linje sørger du for at det faktisk blir gjort.
Hva som konkret slutter å virke hvis du venter
Det abstrakte «appen henger etter» blir tydeligere med eksempler på hva som faktisk går i stykker. Tillatelser og personvernregler strammes inn nesten hvert år. En ny OS-versjon kan kreve at appen ber om tilgang på en ny måte, og gjør den ikke det, slutter en funksjon å virke. Tredjepartstjenester for betaling, kart eller innlogging oppdaterer bibliotekene sine, og en app som ikke følger med, mister den funksjonen. Nye skjermstørrelser og enheter kan ødelegge layouten hvis appen ble bygget for gårsdagens format.
Ingenting av dette skjer på lanseringsdagen. Det sniker seg på, litt om gangen, til så mye har gått i stykker at en bruker tar kontakt, og da er det ofte flere feil samtidig. Det er nettopp derfor løpende, planlagt vedlikehold er billigere enn å vente til noe tvinger frem et stort løft.
Vil du vite hvordan et forvaltningsopplegg kan se ut for akkurat din app, kan du se på tjenestene våre eller ta kontakt, så skisserer vi en plan.
Ofte stilte spørsmål
Hva skjer hvis jeg aldri oppdaterer appen?
Først merkes ingenting. Så begynner ting å gå i stykker: Nye telefoner oppfører seg annerledes, et bibliotek slutter å fungere etter en OS-oppdatering, en integrasjon brytes. Til slutt når appen et punkt der butikken ikke lenger tillater oppdateringer fordi den er bygget mot et for gammelt API. Da kreves ofte et større løft i stedet for løpende små justeringer.
Hva er krav til målversjon (target API level)?
Butikkene krever at nye opplastinger er bygget mot en noenlunde ny versjon av operativsystemet, uttrykt som target API level på Android og tilsvarende SDK-krav på iOS. Kravet heves årlig. Ligger appen under grensen, kan du ikke lenger publisere oppdateringer. Eksisterende brukere kan ofte beholde appen en stund, men du kan ikke rette feil eller slippe noe nytt.
Hvor ofte må en app oppdateres av hensyn til operativsystemet?
Minst én gang i året, knyttet til de store høstlanseringene av iOS og Android. Mange team går dessuten gjennom appen om sommeren mens betaversjonene er ute. Da rekker de å finne problemer før den endelige lanseringen. I tillegg kommer mindre justeringer når enkelte biblioteker eller tjenester endres i løpet av året.
Er OS-vedlikehold det samme som å utvikle nye funksjoner?
Nei, og det er et viktig skille i budsjettet. Teknisk vedlikehold handler om at appen skal fortsette å fungere slik den allerede gjør, på nye OS og enheter. Brukeren ser sjelden noen forskjell. Nyutvikling tilfører verdi. Blander du dem sammen, forsvinner vedlikeholdet ofte fordi nye funksjoner alltid føles mer presserende.
Kan man teste mot nye OS-versjoner før de slippes?
Ja. Både Apple og Google slipper betaversjoner av kommende operativsystemer måneder før den endelige lanseringen, om våren og sommeren. Ved å kjøre appen mot betaversjonene rekker teamet å oppdage og rette problemer før brukerne oppdaterer. Det forvandler høstens OS-lansering fra en brannutrykning til en planlagt innsats.