Mobilapp-tjekliste til startups: 34 punkter fra MVP til App Store-godkendelse (2026)

Mobilapp-tjekliste til startups: 34 punkter fra MVP til App Store-godkendelse (2026)

Apples App Store Review-retningslinje 5.1.1(v) har dræbt flere lanceringsdatoer end nogen bug, vi nogensinde har sendt ud. Én manglende kontosletningsknap, indsendt natten før en demodag, og hele tidslinjen skrider med en uge. Denne mobilapp-tjekliste til startups findes, fordi den fejl er helt til at undgå, og næsten ingen skriver det retningslinjenummer ned, der forårsager den.

Nøglepointer:

• Apple afviser apps, der mangler kontosletningsflow og link til privatlivspolitik: retningslinje 5.1.1 og 1.5 nævner det præcist.
• Google Play kræver både en kontosletningsvej i appen og en offentlig web-URL, med håndhævelse efter den forlængede frist 31. maj 2024.
• Indsendelsestjeklisterne for iOS og Android er forskellige; at behandle dem som én samlet liste er den hyppigste årsag til lanceringsforsinkelser i sidste øjeblik.

Inden du skriver kode

Inden én eneste skærm bliver designet, skal tre ting være på plads: hvad din MVP faktisk er, om du har brug for en privatlivspolitik (det har du), og om GDPR eller Tyrkiets KVKK gælder for dine brugere. Springer du dette trin over, er det derfor, grundlæggere ender med at stresse rundt med juridiske sider den samme uge, som de egentlig ville indsende.

En MVP er, med én sætning, den mindste version af dit produkt, der tester din kerneantagelse med rigtige brugere. Det er ikke en nedskaleret version af din fulde vision. Er du stadig uafklaret om omfanget, så sørg for at afgrænse dit projekt ordentligt, inden du skriver én linje kode; det sparer dig for at skære funktioner væk midt i byggeriet i stedet for før det.

Apples egne retningslinjer er kontante om kravet til privatlivspolitikken: retningslinje 5.1.1(i) fastslår, at apps »skal inkludere et link til deres privatlivspolitik« i App Store Connect-metadataene og i mange tilfælde også inde i selve appen. Det er ikke et forslag. Den blokerer indsendelsen, hvis den mangler.

• Definér dit MVP-omfang med én sætning
• Bekræft, at du har brug for en privatlivspolitik (det har du næsten altid)
• Udarbejd en support-URL (Apple-retningslinje 1.5 kræver den)
• Tjek, om GDPR/KVKK gælder, hvis du har brugere i EU eller Tyrkiet
• Beslut dig for native eller cross-platform-stack

MVP-byggeugen

MVP-byggeugen er der, hvor du beslutter, hvad der faktisk kommer med, versus hvad der skæres væk, og det ærlige svar er: mere end grundlæggere forventer. Analytics og crashrapportering kommer ind under byggeriet, ikke bagefter. Eftermonterer du dem efter lancering, mister du præcis de data, du havde brug for at validere din første antagelse med.

Det, vi faktisk skærer væk fra et v1-omfang det meste af tiden, er alt, hvad der ikke er den ene ting, der testes. Push-notifikationer, socialt login, en indstillingsskærm med seks toggles, det hele kan vente. Grundlæggere stritter imod, forståeligt nok; det føles som at sende noget ufærdigt ud. Det er ufærdigt. Det er pointen.

Som én grundlægger, der har sendt flere apps ud, formulerede det i et tjekliste-indlæg på dev.to, så er det at springe en feedback-mekanisme over tidligt en fejl, han »har fortrudt hver gang«. Byg den ind nu, ikke efter at din første anmeldelse lander. Vil du sætte fart i selve afgrænsningssamtalen, er at bruge AI til at speede afgrænsningen op værd at kigge på, inden byggeriet starter.

• Instrumentér analytics inden din første TestFlight-/interne build
• Kobl crashrapportering på (Sentry eller Firebase Crashlytics)
• Byg en feedback-mekanisme ind i appen
• Skær enhver funktion væk, der ikke er kernen i den ene ting, du tester
• Skriv din første versionsstreng (se versionsstyring nedenfor)

Ugen inden du indsender

Det er det trin, alle konkurrenternes tjeklister springer helt over, og det er her, de mest forebyggelige forsinkelser sker. Semantisk versionsstyring for apps følger mønsteret MAJOR.MINOR.BUILD (1.0.0, så 1.0.1 til en patch, 1.1.0 til et funktionsløft). Vælg et system nu, for inkonsistente versionsnumre forvirrer både appbutikkerne og dit eget team.

En trinvis udrulning frigiver din opdatering til en lille procentdel af brugerne først (ofte 1 %, så 10 %, så 50 %), inden den rammer alle. Kun én af de tre konkurrenttjeklister, vi gennemgik, nævner det, og endda kun i forbifarten. Slipper et crash igennem, begrænser en trinvis udrulning skadesomfanget i stedet for at ramme 100 % af brugerne på én gang.

Spørgsmålene, vi stiller, inden vi giver grønt lys til en kundeindsendelse, er enkle: virker den kritiske sti ende-til-ende, lige nu, på en rigtig enhed? Ikke simulatoren. Er den crashfri rate acceptabel? Er materialerne til butiksoptegnelsen faktisk færdige, ikke placeholders?

• Bekræft, at dit versionsnummer følger et konsistent system
• Test din kritiske sti ende-til-ende én gang til
• Forbered din trinvise udrulningsprocent, hvis butikken understøtter det
• Bekræft, at den crashfri rate er acceptabel, inden du indsender
• Tag skærmbilleder og forbered alle materialer til butiksoptegnelsen

Indsendelsesdagen: iOS vs. Android

iOS- og Android-indsendelser fejler af forskellige årsager, og at behandle dem som én samlet tjekliste er den største enkeltårsag til de lanceringsforsinkelser i sidste øjeblik, vi ser. Apples App Store Review-retningslinjer og Google Plays udviklerpolitikker nævner hver især specifikke, kontrollerbare krav, og de fleste grundlæggere finder først ud af dem efter en afvisningsmail.

I vores egne appindsendelser er de to ting, der oftest fælder førstegangsgrundlæggere, kontosletningskravet og en support-URL, der ikke kan nås. Begge kan fikses med én linje, hvis du fanger dem, inden du indsender. Begge udløser automatisk afvisning, hvis du ikke gør.

Apples App Store Review-retningslinjer er specifikke: retningslinje 5.1.1(v) kræver, at apps, der understøtter kontooprettelse, også tilbyder kontosletning i appen, retningslinje 1.6 dækker oplysningerne om datasikkerhed, og retningslinje 1.5 kræver en fungerende support-URL. På Android kræver Google Plays udviklerpolitik både en slettevej i appen OG en offentlig web-URL til kontosletningsanmodninger. Google annoncerede kravet i april 2023, satte en frist den 7. december 2023 for datasletningsspørgsmålene i Data safety-formularen og tillod udsættelse til 31. maj 2024, hvorefter apps, der ikke overholder kravet, risikerer håndhævelse. Det er ikke en gammel regel, der er blevet udfaset eller fritaget for små apps; den gælder stadig.

De to indsendelsesflow adskiller sig også mekanisk, ikke kun på papiret. På iOS uploader du en build via Xcode eller Transporter, App Store Connect behandler den (det tager alt fra nogle minutter til over en time), og derfra sender du den enten videre til TestFlight for interne og eksterne testere eller direkte til App Review. TestFlight er ikke valgfrit pligtarbejde: det er sådan, Apple forventer, du fanger de bugs, en reviewer ellers ville afvise dig for. På Android fungerer Google Play Console i spor i stedet for én enkelt indsendelse, hvor du bevæger dig gennem intern test, så lukket eller åben test, så produktion, hvert med sit eget publikum og sit eget oprykningstrin. En trinvis udrulning dukker først op, når du opdaterer en eksisterende produktionsrelease. Som Googles egen udgivelsesdokumentation siger det: »Hvis du udruller din første release, ser du ikke muligheden for at vælge en udrulningsprocent«, så planlæg ikke din allerførste lancering omkring en procentvis optrapning, den kommer senere.

Papirarbejde, ikke kode, er det, der faktisk blokerer de fleste førstegangsindsendelser. Apple kræver et privacy manifest for en defineret liste over ofte brugte tredjeparts-SDK'er (annoncenetværk, analytics, crashrapporterere), og deres egen vejledning er kontant om, hvem der hænger på den: »Når du bruger en tredjeparts-SDK i din app, er du ansvarlig for al den kode, SDK'en inkluderer i din app, og du skal være opmærksom på dens praksisser for dataindsamling og brug«, ifølge Apples side om tredjeparts-SDK-krav. Springer du manifestet over for en SDK på listen, kommer din build ikke gennem App Store Connect. Google Plays tilsvarende papirarbejdsport er Data safety-formularen, og den er obligatorisk for enhver app på ethvert spor undtagen rene intern-test-builds: »Alle udviklere, der har en app offentliggjort på Google Play, skal udfylde Data safety-formularen, inklusive apps på lukkede, åbne eller produktionstestspor«, ifølge Google Plays Data safety-dokumentation. Gør du det forkert, siger Google rent ud, at de »kan gribe til passende handling, herunder håndhævelsesforanstaltninger«, når en uoverensstemmelse mellem din erklærede og faktiske appadfærd dukker op.

Der er en tredje fejltilstand, der ikke har noget med politiktekst at gøre: revieweren kan bogstavelig talt ikke teste din app. Apples retningslinje 2.1 siger det direkte: »Inkluder demokontooplysninger (og slå din backend-tjeneste til!), hvis din app indeholder et login«. Ingen fungerende demologin, ingen live backend i gennemgangsvinduet, ingen support-URL, der kan nås, og du ryger tilbage uanset hvor compliant dit kontosletningsflow er. Hvis nogen del af din app ligger bag en betalingsmur eller et login, så skriv reviewernoter, der forklarer præcis, hvordan man når den. Det er et to-minutters trin, som førstegangsgrundlæggere springer over konstant.

Endnu en Android-only-port hører hjemme i samme samtale: mål-API-niveauet. Androids egen udviklerdokumentation fastslår, at »nye apps og appopdateringer skal målrette« det aktuelt krævede Android API-niveau »for at kunne indsendes til Google Play«, og at »forældede apps er utilgængelige for nye brugere af enheder, der kører nyere versioner af Android«. Det har intet med kontosletning eller Data Safety at gøre, men det blokerer en indsendelse lige så blankt, og det er den type krav, der ændrer sig hvert år, så tjek det aktuelle tal, inden du bygger din release.

Ingen af de højest rangerende tjeklister for præcis denne søgning citerer ét eneste retningslinjenummer fra App Store. Det gør vi, fordi gætteri om regeloverholdelse er sådan, lanceringer bliver forsinket en uge ad gangen. Bygger du din bredere datahåndteringspraksis ud, dækker din datahåndteringstjekliste inden lancering sikkerhedssiden, som vi ikke gentager her.

iOS-indsendelsestjekliste:

• Privatlivspolitikkens URL live og tilgængelig
• Kontosletningsvej i appen sendt ud (retningslinje 5.1.1(v))
• Support-URL live (retningslinje 1.5)
• Datasikkerhedsoplysninger udfyldt (retningslinje 1.6)
• TestFlight-build godkendt inden offentlig indsendelse

Android-indsendelsestjekliste:

• Data safety-formular udfyldt i Play Console
• Kontosletningsvej i appen sendt ud
• Offentlig web-URL til kontosletningsanmodninger live (Google Play-krav)
• Trinvis udrulningsprocent sat
• Mål-API-niveau opfylder det aktuelle Play-krav

Lanceringsdagen

Lanceringsdagen er den dag, din app faktisk går live til rigtige brugere, adskilt fra indsendelsen, som kan ske dage eller uger tidligere, og adskilt fra uge ét, som er efterspillet. Overvågning af den trinvise udrulning på dag ét er det, der fortæller dig, om du skal fortsætte udvidelsen eller trykke på pause.

Hold øje med dit App Store Connect- eller Play Console-dashboard hver time, ikke dagligt, de første 24 timer. Falder din crashfri rate, vil du vide det inden for timen, ikke næste morgen, hvor hundrede brugere mere har ramt den samme bug. Hav en rollback-build klar. Den samme hærde-stabilisér-deploy-disciplin, vi bruger til AI-funktioner, gælder lige så direkte her.

• Overvåg crashfri rate hver time de første 24 timer
• Hav din supportkanal bemandet og klar
• Bekræft, at din trinvise udrulning udvider som planlagt
• Hav en rollback-build klar i tilfælde af en kritisk bug

Din første uge live

Den første uge live er der, hvor det meste af det faktiske arbejde sker, selvom næsten ingen planlægger den. Daglig gennemgang af crashrapporter og besvarelse af dine første butiksanmeldelser betyder mere end alt det, du gjorde på selve lanceringsdagen.

»Selve lanceringen betyder mindre, end du tror. Det, der betyder noget, er, hvad du gør i ugerne efter«, som én grundlægger skrev i sin egen tjekliste efter lancering. Det er den ærlige version af uge ét: patch hurtigt, svar personligt, og tjek faktisk, at dit datasletningsflow virker, inden en rigtig bruger tester det for dig. Går du nu og tænker på, hvad alt det koster at bygge og vedligeholde, er budgettering for vedligeholdelse og opdateringer efter lancering det ledsagende indlæg. Dette indlæg dækker paratheden; det andet dækker regningen.

• Gennemgå crashrapporter dagligt den første uge
• Besvar dine første 10 butiksanmeldelser personligt
• Triagér og patch enhver kritisk bug inden for 48 timer
• Bekræft, at din datasletningsanmodningsproces faktisk virker ende-til-ende
• Sæt en fast rytme for at tjekke analytics op mod din oprindelige MVP-hypotese

Sådan griber Techsy det an

Vi behandler gennemgangen inden indsendelse på samme måde for alle kundebuilds: inden vi giver grønt lys til en indsendelse, spørger vi, om den kritiske sti virker på en rigtig enhed, om den crashfri rate holder, og om ethvert flow, retningslinjerne påbyder (kontosletning, privatlivspolitik, support-URL), faktisk fungerer, ikke bare eksisterer i en mockup. Det er en kort liste, men det er listen, der afgør, om en app klarer gennemgangen i første forsøg.

Vil du hellere have én, der har navigeret i de retningslinjer før, til at stå for din indsendelse, er vores mobilappudviklingsproces bygget op om præcis dette trin inden indsendelse. Det er ikke en erstatning for at lave dit eget hjemmearbejde, det er det, vi gør, efter at du har lavet det.

Ofte stillede spørgsmål

Hvad er en MVP, og hvorfor betyder den noget for en lanceringstjekliste?

En MVP er den mindste version af dit produkt, der tester én kerneantagelse med rigtige brugere. Den betyder noget her, fordi ethvert punkt på denne tjekliste skalerer med omfanget: en strammere MVP betyder færre ting, der kan gå galt ved indsendelsen, og færre funktioner, der skal instrumenteres, overvåges og patches i uge ét.

Hvorfor bliver apps afvist fra App Store?

De hyppigste forebyggelige årsager er manglende link til privatlivspolitik (retningslinje 5.1.1(i)), ingen kontosletning i appen (retningslinje 5.1.1(v)) og en support-URL, der ikke kan nås (retningslinje 1.5). Ingen af dem kræver en ingeniørindsats at fikse, det er tjeklistepunkter, ikke bugs.

Hvad sker der, hvis jeg ikke tilføjer en kontosletningsmulighed til min app?

På iOS gør retningslinje 5.1.1(v) det til en automatisk afvisningsårsag, hvis din app understøtter kontooprettelse. På Android kræver Google Play både en slettevej i appen og en offentlig web-slettevej, og apps, der ikke overholder kravet, risikerer håndhævelse efter den forlængede frist den 31. maj 2024, og udelader du den, blokerer det indsendelsen på begge platforme.

Har startups brug for en privatlivspolitik til en mobilapp?

Ja, næsten altid. Apple kræver en linket privatlivspolitik under retningslinje 5.1.1(i), og Google Play kræver en inde i Data safety-formularen. Indsamler du nogen form for brugerdata, bare en e-mail til tilmelding, har du brug for en, inden du indsender.

Hvad er forskellen på at indsende til App Store og Google Play?

Apples gennemgang er retningslinjedrevet med navngivne klausuler (5.1.1, 1.5, 1.6) og en menneskelig reviewer; Google Play læner sig op ad Data safety-formularen og automatiske tjek. Kontosletningskravet minder om hinanden i ånden, men adskiller sig mekanisk; se sammenligningstabellen ovenfor.

Hvor lang tid tager en appbutik-gennemgang faktisk?

Ingen af butikkerne offentliggør en garanteret ekspeditionstid, så behandl ethvert tal, du læser, som en omtrentlig forventning frem for et løfte. I vores egne kundeindsendelser er Apple-godkendelser generelt landet inden for en dag eller to, mens alt, der rører kontosletning eller dataoplysninger, har taget længere. Google Play har typisk været hurtigere. Planlæg din lanceringsdato med luft i, uanset hvad.

Hvad er en trinvis udrulning, og skal jeg bruge en?

En trinvis udrulning frigiver en opdatering til en lille procentdel af brugerne først og udvider så gradvist i stedet for at gå ud til 100 % på én gang. Brug en, når butikken understøtter det; den begrænser, hvor mange brugere der rammer en bug, inden du kan pause og fikse den.

Har jeg brug for en support-URL for at indsende min app?

Ja. Apples retningslinje 1.5 kræver en fungerende support-URL som del af indsendelsen, og Google Play forventer også en supportkontakt. Et dødt link eller en indbakke, ingen holder øje med, er her en nem, undgåelig afvisningsårsag.

Hvad skal jeg overvåge i min apps første uge live?

Crashrapporter dagligt, dine første ti butiksanmeldelser og om din datasletningsanmodningsproces faktisk virker ende-til-ende. Det er også her, du begynder at tjekke rigtige brugsdata op mod den antagelse, din MVP var bygget til at teste.

Er GDPR eller KVKK relevante for en lille startups app?

Har du brugere i EU, gælder GDPR uanset din virksomheds størrelse. Har du brugere i Tyrkiet, gælder KVKK på samme måde. Ingen af lovene har en små-startup-undtagelse, så tjek anvendeligheden under afgrænsningen, ikke efter at du har rigtige brugerdata at beskytte.

Konklusion

En mobilapp-tjekliste til startups gør sig kun fortjent til sin plads, hvis den er specifik nok til at handle på i dag: definér din MVP med én sætning, instrumentér analytics, inden du bygger, gennemgå dit versionssystem ugen inden indsendelse, og opdel dine iOS- og Android-tjeklister i stedet for at behandle dem som én liste. Punkterne om kontosletning og privatlivspolitik alene står for de fleste af de undgåelige afvisninger, vi ser.

Print tjeklisten, arbejd dig igennem den trin for trin, og spring ikke den første uge live over, det er den del, alle konkurrenternes tjeklister udelader, og det er den del, der faktisk afgør, om din lancering holder. Vil du hellere have et ekstra par øjne på din indsendelse, inden du sender den, så få en gratis konsultation →.