Mobilapp-sjekkliste for startups: 34 punkter fra MVP til App Store-godkjenning (2026)

Mobilapp-sjekkliste for startups: 34 punkter fra MVP til App Store-godkjenning (2026)

Apples App Store Review-retningslinje 5.1.1(v) har drept flere lanseringsdatoer for startups enn noen bug vi noensinne har sendt ut. Én manglende kontoslettingsknapp, sendt inn natten før en demodag, og hele tidslinjen sklir en uke. Denne mobilapp-sjekklisten for startups finnes fordi den feilen er fullstendig unngåelig, og nesten ingen skriver ned retningslinjenummeret som forårsaker den.

Nøkkelpunkter:

• Apple avviser apper som mangler kontoslettingsflyt og lenke til personvernerklæring: retningslinjene 5.1.1 og 1.5 nevner det eksplisitt.
• Google Play krever både en kontoslettingsvei i appen og en offentlig web-URL, med håndheving etter utsettelsesfristen 31. mai 2024.
• Sjekklistene for innsending til iOS og Android er ulike; å behandle dem som én felles liste er hovedårsaken til lanseringsforsinkelser i siste liten.

Før du skriver kode

Før én eneste skjerm blir designet, må tre ting være på plass: hva MVP-en din faktisk er, om du trenger en personvernerklæring (det gjør du), og om GDPR eller Tyrkias KVKK gjelder for brukerne dine. Det er å hoppe over dette steget som gjør at gründere sitter og haster med å skrive juridiske sider samme uke som de egentlig skulle sende inn.

En MVP er, med én setning, den minste versjonen av produktet ditt som tester kjerneantakelsen din med ekte brukere. Det er ikke en nedskalert versjon av den fulle visjonen din. Hvis du fortsatt er usikker på omfanget, sørger riktig avgrensning av prosjektet før du skriver én linje kode for at du slipper å kutte funksjoner midt i byggefasen i stedet for før den.

Apples egne retningslinjer er kontante om personvernerklæringskravet: retningslinje 5.1.1(i) slår fast at apper «må inkludere en lenke til personvernerklæringen sin» i App Store Connect-metadataene og, i mange tilfeller, inne i selve appen. Det er ikke et forslag. Mangler den, blokkerer den innsendingen.

• Definer MVP-omfanget ditt med én setning
• Bekreft at du trenger en personvernerklæring (det gjør du nesten alltid)
• Lag en Support-URL (Apple-retningslinje 1.5 krever det)
• Sjekk om GDPR/KVKK gjelder hvis du har brukere i EU eller Tyrkia
• Bestem deg for native eller kryssplattform-stack

Byggeuken for MVP-en

Byggeuken for MVP-en er der du bestemmer hva som faktisk skal ut versus hva som kuttes, og det ærlige svaret er: mer enn gründere forventer. Analyse og krasjrapportering legges inn under byggingen, ikke etterpå. Ettermonterer du det etter lansering, mister du nøyaktig de dataene du trengte for å validere den første antakelsen din.

Det vi faktisk kutter fra et v1-omfang, som regel, er alt som ikke er den ene tingen som testes. Push-varsler, sosial innlogging, en innstillingsskjerm med seks brytere, alt det kan vente. Gründere stritter imot, forståelig nok; det føles som å sende fra seg noe uferdig. Det er uferdig. Det er poenget.

Som en grunnlegger som har lansert flere apper, skrev i et sjekklisteinnlegg på dev.to, er det å hoppe over en tilbakemeldingsmekanisme tidlig en feil han «angret på hver gang». Bygg den inn nå, ikke etter at den første omtalen din lander. Vil du få fart på selve avgrensningssamtalen, er å bruke AI for å speede opp avgrensningen verdt en titt før byggingen starter.

• Instrumenter analyse før din første TestFlight-/interne build
• Koble opp krasjrapportering (Sentry eller Firebase Crashlytics)
• Bygg en tilbakemeldingsmekanisme inn i appen
• Kutt enhver funksjon som ikke er kjernen i den ene tingen du tester
• Skriv din første versjonsstreng (se versjonering nedenfor)

Uken før du sender inn

Dette er steget alle konkurrentenes sjekklister hopper over helt, og det er her de mest forbyggbare forsinkelsene skjer. Semantisk versjonering for apper følger mønsteret MAJOR.MINOR.BUILD (1.0.0, så 1.0.1 for en fiks, 1.1.0 for en funksjonsoppgradering). Velg et skjema nå, for inkonsistente versjonsnumre forvirrer både appbutikkene og teamet ditt.

En trinnvis utrulling slipper oppdateringen din ut til en liten prosentandel av brukerne først (ofte 1 %, så 10 %, så 50 %) før den går til alle. Bare én av de tre konkurrentsjekklistene vi gjennomgikk, nevner det, og da bare i forbifarten. Hvis en krasj slipper gjennom, begrenser en trinnvis utrulling skadeomfanget i stedet for å treffe 100 % av brukerne samtidig.

Spørsmålene vi stiller før vi gir grønt lys til en kundeinnsending, er enkle: fungerer den kritiske stien ende til ende, akkurat nå, på en ekte enhet? Ikke simulatoren. Er den krasjfrie raten akseptabel? Er materiellet for butikkoppføringen faktisk ferdig, ikke plassholdere?

• Bekreft at versjonsnummeret ditt følger et konsistent skjema
• Test den kritiske stien ende til ende én gang til
• Forbered prosentandelen for trinnvis utrulling hvis butikken støtter det
• Bekreft at krasjfri rate er akseptabel før du sender inn
• Ta skjermbilder og forbered alt materiell for butikkoppføringen

Innsendingsdagen: iOS kontra Android

iOS- og Android-innsendinger feiler av ulike grunner, og å behandle dem som én felles sjekkliste er den aller største årsaken til lanseringsforsinkelser i siste liten som vi ser. Apples App Store Review-retningslinjer og Google Plays utviklerpolicyer navngir hver sine spesifikke, kontrollerbare krav, og de fleste gründere finner ut av dem først etter en e-post om avvisning.

I våre egne appinnsendinger er de to tingene som oftest feller førstegangsgründere, kontoslettingskravet og en Support-URL som ikke er tilgjengelig. Begge er én-linjes-fikser hvis du fanger dem før du sender inn. Begge gir automatisk avvisning hvis du ikke gjør det.

Apples App Store Review-retningslinjer er spesifikke: retningslinje 5.1.1(v) krever at apper som støtter kontoopprettelse også tilbyr kontosletting i appen, retningslinje 1.6 dekker Data Security-opplysninger, og retningslinje 1.5 krever en fungerende Support-URL. På Android krever Google Plays utviklerpolicy både en slettevei i appen OG en offentlig web-URL for kontoslettingsforespørsler. Google kunngjorde kravet i april 2023, satte en frist 7. desember 2023 for Data safety-skjemaets spørsmål om datasletting, og tillot utsettelser til 31. mai 2024, hvoretter apper som ikke overholder, risikerer håndheving. Dette er ikke en gammel regel som ble faset ut for små apper; den gjelder fortsatt.

De to innsendingsflytene skiller seg også mekanisk, ikke bare på papiret. På iOS laster du opp en build via Xcode eller Transporter, App Store Connect behandler den (det tar alt fra noen minutter til over en time), og derfra sender du den enten til TestFlight for interne og eksterne testere, eller direkte til App Review. TestFlight er ikke valgfritt pliktarbeid: det er slik Apple forventer at du fanger bugene en reviewer ellers ville avvist deg for. På Android fungerer Google Play Console i spor i stedet for én enkelt innsending, der du går gjennom intern testing, så lukket eller åpen testing, så produksjon, hver med sitt eget publikum og et eget steg for å gå videre. En trinnvis utrulling dukker først opp når du oppdaterer en eksisterende produksjonsversjon. Som Googles egen utgivelsesdokumentasjon sier det: «Hvis du ruller ut din første versjon, vil du ikke se alternativet for å velge en utrullingsprosent», så ikke planlegg den aller første lanseringen din rundt en prosentvis opptrapping, det kommer senere.

Papirarbeid, ikke kode, er det som faktisk blokkerer de fleste førstegangs-innsendinger. Apple krever et personvernmanifest for en definert liste over mye brukte tredjeparts-SDK-er (annonsenettverk, analyse, krasjrapporterere), og deres egen veiledning er kontant om hvem som står ansvarlig: «Når du bruker en tredjeparts-SDK i appen din, er du ansvarlig for all koden SDK-en inkluderer i appen din, og du må være klar over praksisene dens for datainnsamling og bruk», ifølge Apples side om tredjeparts-SDK-krav. Hopper du over manifestet for en oppført SDK, kommer ikke builden din gjennom App Store Connect. Google Plays tilsvarende papirarbeid-port er Data safety-skjemaet, og det er obligatorisk for enhver app på ethvert spor, unntatt rene intern-test-builds: «Alle utviklere som har en app publisert på Google Play, må fylle ut Data safety-skjemaet, inkludert apper på lukkede, åpne eller produksjonstestspor», ifølge Google Plays Data safety-dokumentasjon. Gjør du det feil, sier Google rett ut at de «kan iverksette passende tiltak, inkludert håndhevingstiltak» når et avvik mellom deklarert og faktisk appatferd dukker opp.

Det finnes en tredje feilmodus som ikke har noe med policytekst å gjøre: revieweren kan bokstavelig talt ikke teste appen din. Apples retningslinje 2.1 sier det rett ut: «Inkluder demokontoinformasjon (og slå på backend-tjenesten din!) hvis appen din har innlogging.» Ingen fungerende demoinnlogging, ingen live backend i gjennomgangsvinduet, ingen tilgjengelig Support-URL, og du blir sendt tilbake uansett hvor etterrettelig kontoslettingsflyten din er. Hvis noen del av appen din ligger bak en betalingsmur eller en innloggingsport, skriv notater til revieweren som forklarer nøyaktig hvordan man når den. Det er et to-minutters steg som førstegangsgründere hopper over hele tiden.

Én Android-bare-port til hører hjemme i samme samtale: mål-API-nivået. Androids egen utviklerdokumentasjon slår fast at «nye apper og appoppdateringer må rette seg mot» det gjeldende påkrevde Android API-nivået «for å kunne sendes inn til Google Play», og at «utdaterte apper er utilgjengelige for nye brukere av enheter som kjører nyere versjoner av Android». Det har ingenting med kontosletting eller Data Safety å gjøre, men det blokkerer en innsending like blankt, og det er den typen krav som endres hvert år, så sjekk gjeldende tall før du bygger versjonen din.

Ingen av sjekklistene som rangerer øverst for nøyaktig dette søket, siterer ett eneste retningslinjenummer fra App Store. Det gjør vi, fordi gjetting om etterlevelse er slik lanseringer blir forsinket en uke om gangen. Hvis du bygger ut den bredere datahåndteringspraksisen din, dekker sjekklisten din for datahåndtering før lansering sikkerhetssiden som vi ikke gjentar her.

Sjekkliste for iOS-innsending:

• Personvernerklærings-URL live og tilgjengelig
• Kontoslettingsvei i appen er på plass (retningslinje 5.1.1(v))
• Support-URL live (retningslinje 1.5)
• Data Security-opplysninger fylt ut (retningslinje 1.6)
• TestFlight-build godkjent før offentlig innsending

Sjekkliste for Android-innsending:

• Data Safety-skjema fylt ut i Play Console
• Kontoslettingsvei i appen er på plass
• Offentlig web-URL for kontoslettingsforespørsler er live (Google Play-krav)
• Prosentandel for trinnvis utrulling er satt
• Mål-API-nivået møter gjeldende Play-krav

Lanseringsdagen

Lanseringsdagen er dagen appen din faktisk går live til ekte brukere, atskilt fra innsendingen, som kan skje dager eller uker tidligere, og atskilt fra uke én, som er etterspillet. Overvåking av trinnvis utrulling på dag én er det som forteller deg om du skal fortsette å utvide eller trykke pause.

Følg med på App Store Connect- eller Play Console-dashbordet ditt timevis, ikke daglig, de første 24 timene. Hvis den krasjfrie raten din faller, vil du vite det innen timen, ikke neste morgen når hundre brukere til har truffet den samme bugen. Hold en rollback-build klar. Den samme herd-stabiliser-rull-ut-disiplinen vi bruker for AI-funksjoner gjelder like direkte her.

• Overvåk krasjfri rate timevis de første 24 timene
• Ha støttekanalen din bemannet og klar
• Bekreft at den trinnvise utrullingen din utvider seg som planlagt
• Hold en rollback-build klar i tilfelle en kritisk bug

Din første uke i produksjon

Den første uken i produksjon er der mesteparten av det faktiske arbeidet skjer, selv om nesten ingen planlegger for det. Daglig gjennomgang av krasjrapporter og svar på de første butikkomtalene dine betyr mer enn alt du gjorde på selve lanseringsdagen.

«Selve lanseringen betyr mindre enn du tror. Det som betyr noe, er hva du gjør i ukene etter», som én grunnlegger skrev i sin egen sjekkliste etter lansering. Det er den ærlige versjonen av uke én: lapp raskt, svar personlig, og sjekk faktisk at dataslettingsflyten din fungerer før en ekte bruker tester den for deg. Hvis du nå lurer på hva alt dette koster å bygge og vedlikeholde, er budsjettlegging for vedlikehold og oppdateringer etter lansering følgesvennen. Dette innlegget dekker beredskap; det dekker regningen.

• Gå gjennom krasjrapporter daglig den første uken
• Svar personlig på de første 10 butikkomtalene dine
• Prioriter og lapp enhver kritisk bug innen 48 timer
• Bekreft at dataslettingsforespørselsprosessen din faktisk fungerer ende til ende
• Sett en kadens for å sjekke analysen mot den opprinnelige MVP-hypotesen din

Slik griper Techsy dette an

Vi behandler gjennomgangen før innsending likt for enhver kundes build: før vi gir grønt lys til en innsending, spør vi om den kritiske stien fungerer på en ekte enhet, om den krasjfrie raten holder seg, og om hver retningslinje-påkrevde flyt (kontosletting, personvernerklæring, Support-URL) faktisk fungerer, ikke bare finnes i en mockup. Det er en kort liste, men det er listen som avgjør om en app består gjennomgangen på første forsøk.

Hvis du heller vil at noen som har loset seg gjennom disse retningslinjene før, skal håndtere innsendingen din, er mobilapputviklingsprosessen vår bygget rundt nøyaktig dette gjennomgangssteget før innsending. Det er ikke en erstatning for å gjøre leksen din selv, det er det vi gjør etter at du har gjort den.

Ofte stilte spørsmål

Hva er en MVP, og hvorfor betyr det noe for en lanseringssjekkliste?

En MVP er den minste versjonen av produktet ditt som tester én kjerneantakelse med ekte brukere. Det betyr noe her fordi hvert punkt på denne sjekklisten skalerer med omfanget: en strammere MVP betyr færre ting som kan gå galt ved innsending, og færre funksjoner å instrumentere, overvåke og lappe i uke én.

Hvorfor blir apper avvist fra App Store?

De vanligste forbyggbare grunnene er manglende lenke til personvernerklæring (retningslinje 5.1.1(i)), ingen kontosletting i appen (retningslinje 5.1.1(v)) og en utilgjengelig Support-URL (retningslinje 1.5). Ingen av disse krever ingeniørinnsats å fikse, de er sjekklistepunkter, ikke buger.

Hva skjer hvis jeg ikke legger til et kontoslettingsalternativ i appen min?

På iOS gjør retningslinje 5.1.1(v) dette til en automatisk grunn til avvisning hvis appen din støtter kontoopprettelse. På Android krever Google Play både en slettevei i appen og en offentlig web-slettevei, der apper som ikke overholder, møter håndheving etter utsettelsesfristen 31. mai 2024, og å utelate den blokkerer innsending på begge plattformer.

Trenger startups en personvernerklæring for en mobilapp?

Ja, nesten alltid. Apple krever en lenket personvernerklæring under retningslinje 5.1.1(i), og Google Play krever en inne i Data Safety-skjemaet. Hvis du samler inn noen brukerdata, til og med bare en e-post for registrering, trenger du en før du sender inn.

Hva er forskjellen på å sende inn til App Store kontra Google Play?

Apples gjennomgang er retningslinjedrevet med navngitte klausuler (5.1.1, 1.5, 1.6) og en menneskelig reviewer; Google Play lener seg på Data Safety-skjemaet og automatiske kontroller. Kontoslettingskravet er likt i ånd, men ulikt i mekanikk; se sammenligningstabellen over.

Hvor lang tid tar appbutikk-gjennomgangen faktisk?

Ingen av butikkene publiserer en garantert behandlingstid, så behandle ethvert tall du leser som en grov forventning snarere enn et løfte. I våre egne kundeinnsendinger har Apple-godkjenninger generelt landet innen en dag eller to, der alt som berører kontosletting eller dataopplysninger, tar lengre tid. Google Play har vanligvis vært raskere. Planlegg lanseringsdatoen din med slingringsmonn uansett.

Hva er en trinnvis utrulling, og bør jeg bruke det?

En trinnvis utrulling slipper en oppdatering ut til en liten prosentandel av brukerne først, og utvider så gradvis, i stedet for å gå til 100 % samtidig. Bruk det når butikken støtter det; det begrenser hvor mange brukere som treffer en bug før du kan pause og fikse den.

Trenger jeg en Support-URL for å sende inn appen min?

Ja. Apples retningslinje 1.5 krever en fungerende Support-URL som del av innsendingen, og Google Play forventer en støttekontakt også. En død lenke eller en ubemannet innboks her er en enkel, unngåelig grunn til avvisning.

Hva bør jeg overvåke i appens første uke i produksjon?

Krasjrapporter daglig, de første ti butikkomtalene dine, og om dataslettingsforespørselsprosessen din faktisk fungerer ende til ende. Det er også nå du begynner å sjekke ekte bruksdata mot antakelsen MVP-en din ble bygget for å teste.

Er GDPR eller KVKK relevant for en liten startups app?

Hvis du har brukere i EU, gjelder GDPR uavhengig av størrelsen på selskapet ditt. Hvis du har brukere i Tyrkia, gjelder KVKK på samme måte. Ingen av lovene har et unntak for små startups, så sjekk anvendelighet under avgrensningen, ikke etter at du har ekte brukerdata å beskytte.

Konklusjon

En mobilapp-sjekkliste for startups fortjener bare plassen sin hvis den er spesifikk nok til å handle på i dag: definer MVP-en din med én setning, instrumenter analyse før du bygger, gå gjennom versjoneringsskjemaet ditt uken før innsending, og splitt iOS- og Android-sjekklistene dine i stedet for å behandle dem som én liste. Bare kontoslettings- og personvernerklæringspunktene står for de fleste av de unngåelige avvisningene vi ser.

Skriv ut sjekklisten, jobb deg gjennom den steg for steg, og ikke hopp over den første uken i produksjon, det er delen alle konkurrentsjekklistene utelater, og det er delen som faktisk avgjør om lanseringen din sitter. Hvis du heller vil ha et ekstra par øyne på innsendingen din før du sender den, få en gratis konsultasjon →