Hur lång tid tar det att bygga en app?

Kort svar

En enkel första version av en app, en så kallad MVP, tar oftast ett par månader från idé till App Store. En större app med inloggning, betalning, många vyer och kopplingar till befintliga system kan ta ett halvår eller mer. Själva granskningen hos Apple går för det mesta snabbt: enligt Apple granskar App Review vanligtvis minst hälften av alla inskickade appar på under 24 timmar och 90 procent på under 48 timmar. Det som verkligen styr tidsplanen är omfånget, antalet integrationer, hur snabbt beslut fattas och om appen ska finnas på både iOS och Android. Om du också räknar på kostnaden, läs vår guide om vad det kostar att bygga en app.

Varför svaret varierar så mycket

Frågan om hur lång tid en app tar liknar frågan om hur lång tid en renovering tar. Att måla om ett rum och att bygga om ett kök är båda renoveringar. En app med några informationsvyer och ingen inloggning är något helt annat än en app där kunder beställer, betalar, får notiser och där varje beställning ska hamna i restaurangens kassasystem.

Därför är den viktigaste frågan inte “hur lång tid” utan “vad måste första versionen klara”. När det är bestämt går tidsplanen att uppskatta med rimlig säkerhet. Innan dess är varje siffra en gissning.

Projektets faser

Nästan alla appprojekt går igenom samma faser. Det som skiljer ett litet projekt från ett stort är hur länge varje fas pågår.

Fas	Vad som händer	Ungefärlig tid för en MVP
Förstudie	Mål, målgrupp, funktioner och prioritering	1 till 3 veckor
Design	Användarflöden, vyer och klickbar prototyp	2 till 6 veckor
Utveckling	App, server och integrationer	6 till 16 veckor
Test	Felrättning på riktiga enheter	2 till 4 veckor, delvis parallellt
Publicering	App Store och Google Play	Några dagar till ett par veckor

Siffrorna är planeringsintervall för en avgränsad första version, inga löften. I praktiken överlappar faserna: design av senare vyer kan pågå medan de första byggs, och testning sker löpande.

Förstudien

Förstudien är kort men avgör mest. Här bestäms vem appen är till för, vilket problem den löser och vad som ska ingå i första versionen, och lika viktigt, vad som inte ska ingå. Ett projekt som hoppar över förstudien betalar för det senare, när ändringar mitt i utvecklingen blir både dyra och tidskrävande.

Design

I designfasen blir besluten till vyer och en prototyp som går att klicka i. Apples Human Interface Guidelines beskriver hur en iOS-app förväntas bete sig, och en design som följer dem går snabbare att bygga och lättare att få godkänd. Prototypen är också det billigaste stället att upptäcka att en idé inte fungerar.

Utveckling

Utvecklingen är den längsta fasen. Här byggs appen, servern som lagrar data och kopplingarna till andra system. Det är också här de flesta överraskningarna dyker upp, särskilt i integrationerna. Ett kassasystem eller bokningssystem har ofta begränsningar som ingen kände till från början.

Test

Appen testas på riktiga telefoner, inte bara i simulatorn, eftersom vissa fel bara syns på vissa enheter eller iOS-versioner. Med Apples TestFlight kan testversioner delas med en grupp testare innan appen släpps, och det lönar sig att låta några blivande användare prova den där.

Den sista sträckan: App Store och Google Play

Många underskattar sista sträckan, eftersom den beror på andra än en själv.

App Store. Apples granskning går oftast fort, men en avvisning kostar tid. Apple uppger att över 40 procent av de olösta problemen gäller riktlinje 2.1 om att appen ska vara komplett, vilket omfattar krascher, platshållarinnehåll och ofullständig information. En app som känns färdig vid första inskickningen sparar därför ofta flera dagar. Dessutom krävs ett medlemskap i Apple Developer Program, och för företag kan registreringen ta tid eftersom företaget måste verifieras.

Google Play. Här finns en regel som många missar. Enligt Google måste utvecklare med personliga konton skapade efter den 13 november 2023 köra ett slutet test med minst 12 testare som varit anmälda utan avbrott i minst 14 dagar innan de kan ansöka om produktionsåtkomst. Det är minst två veckors extra kalendertid som måste planeras in. Google skriver också att vissa appar får en utökad granskning som kan ta upp till sju dagar eller längre i undantagsfall.

Ett exempel från verkligheten

Tänk dig en beställningsapp för en restaurangkedja i Göteborg. Gästerna ska kunna logga in, beställa, betala, hämta sin mat och samla poäng. Beställningarna ska gå direkt in i restaurangernas kassasystem.

Förstudien tar ett par veckor, och kedjan bestämmer att poängprogrammet får vänta till version två. Designen tar ungefär en månad, inklusive en prototyp som några stamgäster provar. Utvecklingen tar ett par månader, och en stor del av tiden går åt till kopplingen mot kassasystemet och betalningen. Test och publicering tar ytterligare ett par veckor. Totalt hamnar appen i App Store efter ungefär ett halvår, och en del av den tiden är väntan på beslut och behörigheter från kedjans sida.

Om poängprogrammet hade varit med från början hade tidsplanen blivit betydligt längre. Så styrs de flesta tidsplaner i praktiken: genom att välja vad som inte ska med.

Vad som förlänger och förkortar tiden

Förlänger	Förkortar
Otydliga krav och många ändringar	En tydlig, prioriterad funktionslista
Många integrationer med befintliga system	Få eller inga integrationer
Både iOS och Android från start	En plattform först
Långsamma beslut och många beslutsfattare	En ansvarig med mandat hos beställaren
Innehåll och behörigheter som saknas	Texter, bilder och åtkomst klara från start
Specialdesign av allt	Plattformens standardkomponenter

Många förseningar uppstår inte i koden utan mellan besluten. En vecka då utvecklarna väntar på svar om en funktion är en förlorad vecka, även om ingen har gjort fel. Det är därför en snabb beslutsprocess hos beställaren ofta betyder mer för tidsplanen än hur många utvecklare som arbetar i projektet.

Så håller du själv tidsplanen

En stor del av tidsplanen ligger hos beställaren. De här punkterna gör störst skillnad:

1. Utse en ansvarig. En person som kan fatta beslut om funktioner och design och som svarar inom en dag eller två.
2. Skriv ned vad första versionen inte ska kunna. Listan över bortval skyddar mot att omfånget växer under projektets gång.
3. Ha innehållet klart. Texter, bilder, priser, villkor och integritetspolicy tar ofta längre tid att få fram än man tror.
4. Ordna behörigheter tidigt. Åtkomst till befintliga system, testmiljöer och dokumentation bör finnas innan utvecklingen börjar.
5. Skapa konton i företagets namn. Apple- och Google-kontot ska ägas av företaget, inte av byrån, och verifieringen kan ta tid. Läs mer i vår guide om vem som äger koden till appen.
6. Planera testare. Hitta testarna i god tid, särskilt om Googles krav på ett slutet test med minst 12 testare gäller dig.

Efter lanseringen

Lanseringen är inte slutet på tidsplanen, snarare början på nästa del. Under de första veckorna kommer det nästan alltid små rättelser, eftersom riktiga användare gör saker som ingen testade. Sedan följer version två med de funktioner som sköts upp, nu prioriterade efter hur appen faktiskt används.

Uppdateringar går oftast snabbare än första publiceringen, eftersom grunden finns och appbutikerna redan känner till appen, men de måste fortfarande granskas av Apple och Google. Därför är det klokt att samla rättelser i planerade versioner i stället för att skicka in en ny version för varje litet fel. Appen behöver också underhållas löpande i flera år, och vår guide om vad det kostar att underhålla en app förklarar vad du bör räkna med.

iOS och Android samtidigt eller efter varandra

En vanlig fråga är om appen ska släppas på båda plattformarna samtidigt. Att bygga för båda från start förlänger första versionen och dubblerar en del av testningen, men når alla användare direkt. Att börja med en plattform ger en snabbare lansering och lärdomar som gör den andra versionen bättre. Vilket som passar beror på vem användarna är. Vänder sig appen till en bred svensk publik är båda plattformarna ofta viktiga, medan en intern företagsapp kanske bara behöver den plattform som de anställda redan använder.

Snabbare utan att tumma på kvaliteten

Det mest effektiva sättet att få ut en app snabbare är att bygga mindre. Det är hela idén med en MVP: att släppa den minsta version som löser kärnproblemet och lära sig av verklig användning innan man bygger vidare. Läs mer i vår guide om vad en MVP är.

Andra bra genvägar är att använda plattformens standardkomponenter, att börja med en plattform och att ha innehåll och åtkomst klara innan utvecklingen börjar. Den genväg som nästan aldrig fungerar är att pressa utvecklarna att göra samma arbete fortare. Det ger fler fel, fler avvisningar och en längre väg till lansering.

Var vaksam på väldigt korta tidsplaner

Lovar en byrå en komplett app med inloggning, betalning och integrationer på några veckor finns det skäl att fråga varför. Antingen är omfånget mindre än du tror, eller så sparas det på test och kvalitet. Båda delarna syns senare, ofta som en avvisning i App Store eller fel hos de första användarna. Hos AJBU uppskattar vi tidsplanen först när första versionens omfång är klart, och vi visar den fas för fas så att det syns var tiden går. Exempel på appar vi har byggt finns under vårt arbete.

När det går fortare än väntat

Vissa appar kan faktiskt byggas snabbt. En intern app för några få medarbetare, utan betalning och utan integrationer, eller en enkel kampanjapp kan vara klar på betydligt kortare tid än siffrorna ovan. Detsamma gäller om designen redan finns eller om appen bygger vidare på en befintlig plattform. Ju färre rörliga delar, desto kortare tidsplan.