Lanseringsdagen føles som en mållinje. Appen ligger i App Store og Google Play, de første brukerne laster den ned, og prosjektet er levert.
I praksis er det starten på en ny fase. En app lever i et miljø som endrer seg hele tiden: operativsystemene oppdateres, butikkene endrer kravene sine, og brukerne finner ting ingen testet for. Det er ikke farlig, og det trenger ikke være dyrt. Men det må følges opp.
Denne artikkelen går gjennom hva drift av en app faktisk innebærer, hva som er nødvendig og hva som er valgfritt, og avslutter med en sjekkliste du kan bruke direkte.
Hvorfor trenger en app drift etter lansering?
En nettside kan i prinsippet stå urørt i årevis. En app kan ikke det.
Grunnen er at appen kjører på telefoner som eies av andre. Apple og Google gir ut nye versjoner av iOS og Android hvert år, og brukerne oppdaterer. Før eller siden slutter noe å fungere som før: en tillatelse spørres om på en ny måte, en skjerm ser feil ut på en ny telefonstørrelse, eller en funksjon appen brukte, blir faset ut.
I tillegg krever butikkene jevnlig at apper bygges med nyere verktøy for å kunne oppdateres eller bli liggende. En app som ikke vedlikeholdes, forsvinner ikke over natta, men den blir gradvis vanskeligere å holde i live, og dyrere å ta opp igjen.
Vi anbefaler å regne 10 til 20 prosent av utviklingskostnaden årlig til drift og vedlikehold. For en app som kostet 200 000 kroner betyr det 20 000 til 40 000 i året. Videreutvikling kommer i tillegg, og det er et valg, ikke et krav.
Feilretting og support fra ekte brukere
Ingen app er feilfri ved lansering, uansett hvor godt den er testet. Ekte brukere har andre telefoner, andre vaner og dårligere dekning enn testmiljøet.
Det viktigste er å få vite om feilene før brukerne gir opp. Tre ting gjør det mulig:
- Krasjrapportering. Verktøy som Sentry eller Firebase Crashlytics sender beskjed når appen krasjer, med informasjon om hvor i koden det skjedde og på hvilken telefon. De fleste krasj blir aldri meldt av brukerne, de bare slutter å bruke appen.
- En enkel vei for tilbakemeldinger. En lenke til e-post eller et skjema inne i appen, og noen som faktisk leser det som kommer inn.
- Anmeldelser i butikkene. Følg med på App Store og Google Play. Svar på kritikk, og legg merke til mønstre. Tre anmeldelser om samme problem er et funn.
Avtal også på forhånd hvordan feil prioriteres. En feil som hindrer innlogging eller betaling må rettes samme dag. En skjerm som ser litt rar ut på én modell, kan vente til neste planlagte oppdatering. Uten en slik avtale blir alt like hastende, og det er dyrt.
iOS-, Android- og bibliotekoppdateringer
Hver høst kommer nye store versjoner av iOS og Android. Apple slipper testversjoner i juni, og det er da det lønner seg å teste appen, ikke i september når brukerne allerede har oppdatert.
Som regel er endringene små: en justering i hvordan varsler eller posisjon fungerer, nye regler for personvern, eller nye skjermstørrelser. Noen ganger krever de litt arbeid. Sjelden krever de mye, så lenge appen er holdt jevnlig oppdatert.
I tillegg kommer bibliotekene. En moderne app er bygget på mange ferdige byggeklosser, for eksempel rammeverket (som React Native), betalingsløsninger, kart og innlogging. Disse oppdateres også, ofte med sikkerhetsrettelser.
Den viktigste regelen her er å oppdatere ofte og i små steg. En app som oppdateres hvert kvartal, krever litt arbeid hver gang. En app som står urørt i to år, krever ofte at mange ting oppdateres samtidig, og da kan en liten jobb bli et lite prosjekt.
App Store og Google Play-krav som endrer seg
Begge butikkene endrer kravene sine jevnlig, og det er her mange blir overrasket.
Google Play krever at apper retter seg mot en ny versjon av Android hvert år, med frist på sensommeren. Apper som ikke gjør det, kan ikke publisere oppdateringer, og blir etter hvert skjult for brukere med nye telefoner.
Apple krever med jevne mellomrom at apper bygges med en nyere versjon av utviklingsverktøyet Xcode for å kunne sendes inn. Gamle apper blir liggende, men du kan ikke rette en feil før appen er oppdatert til de nye kravene. Det er en dårlig situasjon å oppdage midt i en hastefeil.
I tillegg kommer krav om personvern. Begge butikkene krever at du beskriver hvilke data appen samler inn, og at beskrivelsen er oppdatert. Apper med brukerkontoer må la brukerne slette kontoen sin fra appen. Slike krav kommer med noen måneders varsel, og det er lurt at noen følger med på e-postene fra Apple og Google.
Et praktisk tips: sørg for at kontoene i App Store Connect og Google Play Console eies av bedriften din, ikke av en tidligere ansatt eller leverandøren. Det er overraskende vanlig at nettopp dette blir et problem.
Sikkerhet, backup og tilgangsstyring
De fleste apper har en backend: en database, en server eller en skytjeneste som lagrer data og håndterer innlogging. Det er der de største risikoene ligger.
Sikkerhetsoppdateringer. Hold rammeverk og biblioteker oppdatert, særlig når det kommer varsler om kjente sårbarheter. Mange verktøy kan varsle automatisk.
Backup. Sjekk at databasen tas sikkerhetskopi av, og test minst én gang at det faktisk går an å gjenopprette. En backup som aldri er testet, er en antakelse.
Tilganger. Lag en oversikt over hvem som har tilgang til hva: servere, databaser, butikkontoer, analyseverktøy og domener. Fjern tilganger når noen slutter eller et samarbeid avsluttes. Bruk tofaktorinnlogging overalt det går.
Nøkler og sertifikater. Push-varsler, betaling og innlogging bruker sertifikater og nøkler som utløper. Skriv ned når, og sett en påminnelse. En utløpt nøkkel er en av de vanligste grunnene til at varsler plutselig slutter å komme.
Personvern. Håndterer appen personopplysninger, må du kunne svare på hva som lagres, hvor, hvor lenge, og hvem som har tilgang. Det er et krav etter GDPR, og det er også det første en større kunde spør om.
Måling, analyse og prioritering av forbedringer
Drift handler ikke bare om å holde appen i live, men også om å vite om den gjør jobben sin.
Følg med på et fåtall tall som sier noe om verdien: hvor mange som er aktive hver uke, hvor mange som fullfører den viktigste oppgaven, og hvor de faller fra. Et analyseverktøy som PostHog eller Firebase Analytics gir dette uten mye arbeid, så lenge det er satt opp riktig fra start.
Bruk tallene sammen med tilbakemeldingene til å prioritere. En nyttig rekkefølge er å se på hvor mange det gjelder, hvor ofte det skjer, og hvor mye det hjelper. En liten forbedring i noe alle gjør hver dag slår en stor forbedring i noe få gjør sjelden.
Vi har skrevet mer om hvordan du leser hva brukerne gjør og prioriterer videre i fra MVP til fullverdig app.
Når bør du sette av fast videreutvikling?
Vedlikehold holder appen i gang. Videreutvikling gjør den bedre. Det første er nødvendig, det andre avhenger av hva appen skal gjøre for bedriften.
Fast videreutvikling, for eksempel noen dager i måneden, lønner seg når
- appen er en viktig del av forretningen, og brukerne forventer at den blir bedre
- dere har en liste med forbedringer som allerede er etterspurt
- konkurrenter jobber aktivt med sine løsninger
- appen fortsatt er i en tidlig fase, der det dere lærer de første månedene, bør bli til endringer raskt
Et internt verktøy som gjør jobben sin og har et stabilt antall brukere, trenger ofte bare vedlikehold, med en større oppdatering når behovet melder seg.
Fordelen med en fast avtale er rytmen. Små forbedringer annenhver uke gjør at appen føles levende for brukerne, og hver endring er liten nok til at det er lett å finne årsaken hvis noe går galt. Det er også billigere enn å samle opp ønsker i et år og så starte et nytt prosjekt. Se hvordan vi jobber med apputvikling og videreutvikling.
Sjekkliste for trygg appdrift
Bruk lista som utgangspunkt, og fordel ansvaret mellom dere og leverandøren.
Løpende
- Krasjrapportering er satt opp, og noen får varsel ved nye krasj
- Tilbakemeldinger og anmeldelser i butikkene leses og besvares
- Det er avtalt hvordan feil prioriteres, og hvor fort kritiske feil rettes
Hvert kvartal
- Rammeverk og biblioteker oppdateres, med sikkerhetsrettelser først
- Tallene for bruk gjennomgås, og forbedringslista prioriteres på nytt
- Tilgangslista ryddes for personer og leverandører som ikke lenger trenger tilgang
Hvert år
- Appen testes på nye versjoner av iOS og Android før de lanseres i høst
- Krav fra App Store og Google Play gjennomgås, med frister i kalenderen
- Personvernbeskrivelser i butikkene og personvernerklæringen sjekkes mot hva appen faktisk gjør
- Gjenoppretting fra backup testes
- Utløpsdatoer for sertifikater og nøkler sjekkes
Én gang, men viktig
- Butikkontoer, domener og skytjenester eies av bedriften
- Kildekoden ligger i et repository bedriften har tilgang til
- Det finnes en kort beskrivelse av hvordan appen er satt opp, slik at en ny utvikler kan ta over
Kort sagt
En app trenger jevnlig og forutsigbart vedlikehold, ikke konstant brannslukking. Oppdater ofte og i små steg, følg med på krasj og tilbakemeldinger, hold kontoer og tilganger i orden, og sett av 10 til 20 prosent av utviklingskostnaden årlig. Videreutvikling er et eget valg som avhenger av hvor viktig appen er for bedriften.
Har du spørsmål om drift og vedlikehold, eller vil du gå gjennom hva din app trenger? Snakk med utviklerne.