Checklista för mobilappar för startups: 34 punkter från MVP till godkännande i App Store (2026)

Checklista för mobilappar för startups: 34 punkter från MVP till godkännande i App Store (2026)

Apples App Store Review Guideline 5.1.1(v) har dödat fler lanseringsdatum för startups än någon bugg vi någonsin skeppat. En saknad knapp för kontoborttagning, inskickad kvällen före en demo day, och hela tidplanen skjuts en vecka. Den här checklistan för mobilappar för startups finns eftersom det misstaget går att undvika helt, och nästan ingen skriver ner det riktlinjenummer som orsakar det.

Viktiga slutsatser:

• Apple avslår appar som saknar flöden för kontoborttagning och integritetspolicyer: Riktlinjerna 5.1.1 och 1.5 nämner det exakt.
• Google Play kräver både en väg i appen och en publik webbväg för kontoborttagning, med tillsyn efter förlängningsdeadline den 31 maj 2024.
• Checklistor för inskickning till iOS och Android skiljer sig åt; att behandla dem som en gemensam lista är den vanligaste orsaken till förseningar i sista minuten.

Innan du skriver kod

Innan en enda skärm designas behöver tre saker vara låsta: vad din MVP faktiskt är, om du behöver en integritetspolicy (det gör du), och om GDPR eller Turkiets KVKK gäller för dina användare. Att hoppa över det här steget är varför grundare hamnar i att stressa skriva juridiska sidor samma vecka som de tänkt skicka in.

En MVP är, i en mening, den minsta versionen av din produkt som testar ditt kärnantagande med riktiga användare. Det är inte en nedbantad version av din fulla vision. Om du fortfarande är osäker på omfattningen, avgränsa ditt bygge ordentligt innan du skriver en rad kod, så slipper du klippa funktioner mitt i bygget istället för före det.

Apples egna riktlinjer är raka om kravet på integritetspolicy: Riktlinje 5.1.1(i) anger att appar "måste inkludera en länk till sin integritetspolicy" i App Store Connect-metadata och, i många fall, inne i själva appen. Det är inte ett förslag. Det är ett hinder för inskickning om det saknas.

• Definiera din MVP-omfattning i en mening
• Bekräfta att du behöver en integritetspolicy (det gör du nästan alltid)
• Utkasta en Support-URL (Apple Riktlinje 1.5 kräver det)
• Kontrollera GDPR/KVKK-tillämpning om du har EU- eller turkiska användare
• Bestäm nativ vs. plattformsoberoende stack

MVP-byggveckan

En MVP-byggvecka är där du bestämmer vad som faktiskt skeppas mot vad som klipps, och det ärliga svaret är: mer än grundare förväntar sig. Analys och kraschrapportering läggs in under bygget, inte efter. Att eftermontera dem efter lansering betyder att du förlorar exakt den data du behövde för att validera ditt första antagande.

Det vi faktiskt klipper från en v1-omfattning, för det mesta, är allt som inte är den enda sak som testas. Push-notiser, social inloggning, en inställningsskärm med sex reglage, allt det kan vänta. Grundare gör motstånd, förståeligt; det känns som att skeppa något oavslutat. Det är oavslutat. Det är poängen.

Som en grundare som skeppat flera appar uttryckte det i ett inlägg på dev.to, att hoppa över en feedbackmekanism tidigt är ett misstag han "ångrade varje gång." Bygg in det nu, inte efter att din första recension landar. Om du vill snabba upp själva avgränsningssamtalet, använda AI för att snabba upp avgränsningen är värt en titt innan bygget startar.

• Instrumentera analys före din första TestFlight/interna build
• Koppla upp kraschrapportering (Sentry eller Firebase Crashlytics)
• Bygg in en feedbackmekanism i appen
• Klipp varje funktion som inte är central för den sak du testar
• Skriv din första versionssträng (se versionshantering nedan)

Veckan innan du skickar in

Det här är steget som varje konkurrentchecklista hoppar över helt, och det är där de mest förebyggbara förseningarna sker. Semantisk versionshantering för appar följer ett MAJOR.MINOR.BUILD-mönster (1.0.0, sedan 1.0.1 för en patch, 1.1.0 för en funktionshöjning). Välj ett schema nu, eftersom inkonsekventa versionsnummer förvirrar både appbutikerna och ditt eget team.

En stegvis utrullning släpper din uppdatering till en liten andel användare först (ofta 1 %, sedan 10 %, sedan 50 %) innan den går till alla. Bara en av de tre konkurrentchecklistor vi granskade nämner det, och då bara i förbigående. Om en krasch slinker igenom begränsar en stegvis utrullning sprängradien istället för att träffa 100 % av användarna samtidigt.

Frågorna vi ställer innan vi godkänner en klients inskickning är enkla: fungerar den kritiska sökvägen från början till slut, just nu, på en riktig enhet? Inte simulatorn. Är kraschfrihetsgraden acceptabel? Är butikens listningstillgångar faktiskt slutgiltiga, inte platshållare?

• Bekräfta att ditt versionsnummer följer ett konsekvent schema
• Testa din kritiska sökväg från början till slut en gång till
• Förbered din stegvisa utrullningsprocent om butiken stödjer det
• Bekräfta att kraschfrihetsgraden är acceptabel före inskickning
• Skärmdumpa och förbered alla listningstillgångar för butiken

Inskickningsdagen: iOS vs. Android

iOS- och Android-inskickningar misslyckas av olika anledningar, och att behandla dem som en gemensam checklista är den enskilt största orsaken till förseningar i sista minuten som vi ser. Apples App Store Review Guidelines och Google Plays utvecklarpolicyer nämner vardera specifika, kontrollerbara krav, och de flesta grundare får reda på dem först efter ett avslagsmejl.

I våra egna appinskickningar är de två saker som snubblar upp förstagångsgrundare oftast kravet på kontoborttagning och en oåtkomlig Support-URL. Båda är en-rads-fixar om du fångar dem innan du skickar in. Båda orsakar ett automatiskt avslag om du inte gör det.

Apples App Store Review Guidelines är specifika: Riktlinje 5.1.1(v) kräver att appar som stödjer kontoskapande också erbjuder kontoborttagning i appen, Riktlinje 1.6 täcker Data Security-avslöjanden, och Riktlinje 1.5 kräver en fungerande Support-URL. På Android kräver Google Plays utvecklarpolicy både en borttagningsväg i appen OCH en publik webb-URL för begäranden om kontoborttagning. Google meddelade kravet i april 2023, satte en deadline den 7 december 2023 för Data safety-formulärets frågor om databorttagning, och tillät förlängningar till den 31 maj 2024, efter vilket appar som inte uppfyller kraven riskerar tillsyn. Det här är inte en föråldrad regel som fasades ut för små appar; den gäller fortfarande.

De två inskickningsflödena skiljer sig också mekaniskt, inte bara på papper. På iOS laddar du upp en build via Xcode eller Transporter, App Store Connect bearbetar den (det tar allt från några minuter till över en timme), och därifrån antingen routar du den till TestFlight för interna och externa testare eller skickar in den direkt för App Review. TestFlight är inte valfritt merarbete: det är hur Apple förväntar sig att du fångar de buggar som en granskare annars skulle avslå dig för. På Android fungerar Google Play Console i spår istället för en enda inskickning, genom intern testning, sedan sluten eller öppen testning, sedan produktion, varje med sin egen publik och sitt eget befordringssteg. En stegvis utrullning dyker bara upp när du uppdaterar en befintlig produktionsrelease. Som Googles egen releasedokumentation uttrycker det, "om du rullar ut din första release ser du inte alternativet att välja en utrullningsprocent," så planera inte din allra första lansering kring en procentuell trappa, det kommer senare.

Pappersarbete, inte kod, är vad som faktiskt blockerar de flesta förstagångsinskickningar. Apple kräver en integritetsmanifest för en definierad lista av vanligt använda tredjeparts-SDK:er (annonsnätverk, analys, kraschrapporterare), och dess egen vägledning är rak om vem som är ansvarig: "när du använder ett tredjeparts-SDK med din app är du ansvarig för all kod som SDK:et inkluderar i din app, och behöver vara medveten om dess datainsamling och användningspraxis," enligt Apples sida om tredjeparts-SDK-krav. Hoppa över ett manifest för ett listat SDK och din build klarerar inte App Store Connect. Google Plays motsvarighet till pappersarbetshinder är Data safety-formuläret, och det är obligatoriskt för varje app på varje spår utom rena intern-testning-byggen: "alla utvecklare som har en app publicerad på Google Play måste fylla i Data safety-formuläret, inklusive appar på slutna, öppna eller produktionstestningsspår," enligt Google Plays Data safety-dokumentation. Gör fel och Google säger rakt ut att de "kan vidta lämpliga åtgärder, inklusive tillsynsåtgärder" när en diskrepans mellan ditt deklarerade och faktiska appbeteende dyker upp.

Det finns ett tredje felläge som inte har något att göra med policytext: granskaren kan bokstavligen inte testa din app. Apples Riktlinje 2.1 säger det rakt ut: "inkludera demokontoinformation (och slå på din backend-tjänst!) om din app inkluderar en inloggning." Inga fungerande demoinloggningar, ingen live-backend under granskningsfönstret, ingen åtkomlig Support-URL, och du blir avvisad oavsett hur efterlevlig din kontoborttagningsväg är. Om någon del av din app ligger bakom en betalvägg eller inloggningsgrind, skriv granskaranteckningar som förklarar exakt hur man når den. Det är ett två-minuterssteg som förstagångsgrundare hoppar över ständigt.

Ytterligare ett Android-specifikt hinder hör till samma samtal: mål-API-nivån. Androids egen utvecklar-dokumentation anger att "nya appar och appuppdateringar måste rikta in sig på" den aktuella obligatoriska Android API-nivån "för att kunna skickas till Google Play," och att "föråldrade appar är otillgängliga för nya användare av enheter som kör nyare versioner av Android." Det har inget att göra med kontoborttagning eller Data Safety, men det blockerar en inskickning lika bestämt, och det är den typ av krav som ändras varje år, så kontrollera det aktuella numret innan du bygger din release.

Noll av de högst rankade checklistorna för exakt den här sökningen citerar ett enda App Store-riktlinjenummer. Vi gör det, eftersom att gissa om efterlevnad är hur lanseringar försenas en vecka i taget. Om du bygger ut din bredare datahanteringshållning, din datahanteringschecklista före lansering täcker säkerhetssidan som vi inte duplicerar här.

iOS-inskickningschecklista:

• Integritetspolicy-URL live och åtkomlig
• Kontoborttagningsväg i appen skeppad (Riktlinje 5.1.1(v))
• Support-URL live (Riktlinje 1.5)
• Data Security-avslöjanden ifyllda (Riktlinje 1.6)
• TestFlight-build godkänd före publik inskickning

Android-inskickningschecklista:

• Data Safety-formulär ifyllt i Play Console
• Kontoborttagningsväg i appen skeppad
• Publik webb-URL för begäranden om kontoborttagning live (Google Play-krav)
• Stegvis utrullningsprocent inställd
• Mål-API-nivå uppfyller aktuellt Play-krav

Lanseringsdagen

Lanseringsdagen är dagen då din app faktiskt går live till riktiga användare, åtskild från inskickning, som kan ske dagar eller veckor tidigare, och åtskild från vecka ett, som är efterspelet. Övervakning av stegvis utrullning dag ett är det som säger dig om du ska fortsätta expandera eller trycka på paus.

Titta på din App Store Connect- eller Play Console-panel varje timme, inte dagligen, under de första 24 timmarna. Om din kraschfrihetsgrad sjunker vill du veta det inom timmen, inte nästa morgon när hundra användare till har träffat samma bugg. Håll en rollback-build redo. Samma härd-stabilisera-driftsätt-disciplin vi använder för AI-funktioner gäller lika direkt här.

• Övervaka kraschfrihetsgraden varje timme under de första 24 timmarna
• Ha din supportkanal bemannad och redo
• Bekräfta att din stegvisa utrullning expanderar som planerat
• Håll en rollback-build redo vid en kritisk bugg

Din första vecka live

Den första veckan live är där det mesta av det faktiska arbetet sker, även om nästan ingen planerar för det. Daglig kraschrapportgranskning och att svara på dina första butiksrecensioner betyder mer än något du gjorde på själva lanseringsdagen.

"Själva lanseringen betyder mindre än du tror. Det som betyder något är vad du gör veckorna efter," som en grundare skrev i sin egen checklista efter lansering. Det är den ärliga versionen av vecka ett: patcha snabbt, svara personligen, och kontrollera faktiskt att ditt databorttagningsflöde fungerar innan en riktig användare testar det åt dig. Om du nu undrar vad allt det här kostar att bygga och underhålla, budgetera för underhåll och uppdateringar efter lansering är komplementet. Det här inlägget täcker redo; det täcker notan.

• Granska kraschrapporter dagligen under den första veckan
• Svara på dina första 10 butiksrecensioner personligen
• Triagera och patcha varje kritisk bugg inom 48 timmar
• Bekräfta att din process för databorttagningsbegäranden faktiskt fungerar från början till slut
• Sätt en kadens för att kontrollera analys mot din ursprungliga MVP-hypotes

Hur Techsy arbetar med det här

Vi behandlar granskning före inskickning på samma sätt för varje klientbygge: innan vi godkänner en inskickning frågar vi om den kritiska sökvägen fungerar på en riktig enhet, om kraschfrihetsgraden håller, och om varje riktlinje-mandat flöde (kontoborttagning, integritetspolicy, Support-URL) faktiskt fungerar, inte bara existerar i en mockup. Det är en kort lista, men det är listan som avgör om en app klarar granskningen på första försöket.

Om du hellre vill ha någon som navigerat de här riktlinjerna tidigare att hantera din inskickning, vår process för mobilappsutveckling är byggd kring exakt det här steget för granskning före inskickning. Det är inte en ersättning för att göra din egen läxa, det är vad vi gör efter att du har gjort den.

Vanliga frågor

Vad är en MVP och varför spelar det roll för en lanseringschecklista?

En MVP är den minsta versionen av din produkt som testar ett kärnantagande med riktiga användare. Det spelar roll här eftersom varje punkt på den här checklistan skalar med omfattningen, en tajtare MVP betyder färre saker som kan gå fel vid inskickning och färre funktioner att instrumentera, övervaka och patcha under vecka ett.

Varför avslås appar från App Store?

De vanligaste förebyggbara anledningarna är saknade integritetspolicylänkar (Riktlinje 5.1.1(i)), ingen kontoborttagning i appen (Riktlinje 5.1.1(v)), och en oåtkomlig Support-URL (Riktlinje 1.5). Inget av dessa kräver ingenjörsarbete att fixa, de är checklistpunkter, inte buggar.

Vad händer om jag inte lägger till ett alternativ för kontoborttagning i min app?

På iOS gör Riktlinje 5.1.1(v) det till en automatisk avslagsanledning om din app stödjer kontoskapande. På Android kräver Google Play både en väg i appen och en publik webbväg för borttagning, med appar som inte uppfyller kraven som riskerar tillsyn efter förlängningsdeadlinen den 31 maj 2024, och att utelämna det blockerar inskickning på båda plattformarna.

Behöver startups en integritetspolicy för en mobilapp?

Ja, nästan alltid. Apple kräver en länkad integritetspolicy under Riktlinje 5.1.1(i), och Google Play kräver en inne i Data Safety-formuläret. Om du samlar in någon användardata, till och med bara en e-post för registrering, behöver du en innan du skickar in.

Vad är skillnaden mellan att skicka in till App Store vs. Google Play?

Apples granskning är riktlinjedriven med namngivna klausuler (5.1.1, 1.5, 1.6) och en mänsklig granskare; Google Play lutar sig mot Data Safety-formuläret och automatiserade kontroller. Kravet på kontoborttagning liknar i andan men skiljer sig i mekaniken; se jämförelsetabellen ovan.

Hur lång tid tar app store-granskning faktiskt?

Ingen butik publicerar en garanterad svarstid, så behandla varje nummer du läser som en ungefärlig förväntan snarare än ett löfte. I våra egna klientinskickningar har Apple-godkännanden generellt landat inom en dag eller två, med allt som rör kontoborttagning eller dataavslöjanden som tar längre tid. Google Play har vanligtvis varit snabbare. Planera ditt lanseringsdatum med marginal oavsett.

Vad är en stegvis utrullning och ska jag använda en?

En stegvis utrullning släpper en uppdatering till en liten andel användare först, och expanderar sedan gradvis, istället för att gå till 100 % på en gång. Använd en när butiken stödjer det; den begränsar hur många användare som träffar en bugg innan du kan pausa och fixa den.

Behöver jag en Support-URL för att skicka in min app?

Ja. Apples Riktlinje 1.5 kräver en fungerande Support-URL som del av inskickningen, och Google Play förväntar sig också en supportkontakt. En död länk eller en obevakad inkorg här är en enkel, undvikbar avslagsanledning.

Vad ska jag övervaka under min apps första vecka live?

Kraschrapporter dagligen, dina första tio butiksrecensioner, och om din process för databorttagningsbegäranden faktiskt fungerar från början till slut. Det är också nu du börjar kontrollera riktig användningsdata mot det antagande din MVP byggdes för att testa.

Är GDPR eller KVKK relevant för en liten startups app?

Om du har användare i EU gäller GDPR oavsett ditt företags storlek. Om du har användare i Turkiet gäller KVKK på samma sätt. Ingen av lagarna har ett undantag för små startups, så kontrollera tillämpningen under avgränsningen, inte efter att du har riktig användardata att skydda.

Slutsats

En checklista för mobilappar för startups förtjänar sin plats bara om den är specifik nog att agera på idag: definiera din MVP i en mening, instrumentera analys före du bygger, granska ditt versionsschema veckan före inskickning, och dela upp dina iOS- och Android-checklistor istället för att behandla dem som en lista. Kontoborttagnings- och integritetspolicy-punkterna ensamma står för de flesta av de undvikbara avslag vi ser.

Skriv ut checklistan, arbeta igenom den steg för steg, och hoppa inte över den första veckan live, det är delen som varje konkurrentchecklista utelämnar, och det är delen som faktiskt avgör om din lansering håller. Om du hellre vill ha ett extra par ögon på din inskickning innan du skickar den, boka en gratis konsultation →.