App Store-avslag enligt 2.1 App Completeness: testplan för releasebygget innan du skickar in igen (2026)

Ett App Store-avslag enligt 2.1 App Completeness betyder att granskaren inte kunde använda din app som en kund skulle. Den kan ha kraschat, visat platshållarinnehåll, stoppat granskaren vid en inloggningsskärm eller dolt ett köp i appen. Lösningen är sällan en enda kodrad. Innan du skickar in igen bör du köra en kort testplan på releasebygget, med en ny installation och samma inloggningsuppgifter som du ger App Review. Den här artikeln går igenom planen och visar hur andra utvecklare har åtgärdat samma avslag.

Vad kontrollerar App Store-riktlinje 2.1 App Completeness?

Riktlinje 2.1 kontrollerar att bygget du skickar in är en färdig, fungerande app. Den behöver fullständig metadata, fungerande länkar, en demoinloggning, en driftsatt backend och köp i appen som granskaren kan hitta och använda.

Apples App Review Guidelines delar upp 2.1 i två delar. 2.1(a) säger att inskickningar "ska vara slutliga versioner med all nödvändig metadata och fullt fungerande URL:er" och att platshållartext och tomma webbplatser ska tas bort. Den uppmanar dig också att testa på en enhet efter buggar och stabilitetsproblem, och att "inkludera uppgifter om ett demokonto (och slå på din backendtjänst!) om din app har inloggning". Apple "avvisar ofullständiga apppaket och binärer som kraschar eller uppvisar uppenbara tekniska problem". 2.1(b) säger att köp i appen måste vara "kompletta, aktuella, synliga för granskaren och fungerande". Om ett konfigurerat köp inte går att hitta i appen ska du förklara varför i dina granskningsanteckningar.

Det här avslaget är vanligt. Apples sida Preparing for App Review säger: "I genomsnitt gäller över 40 % av olösta ärenden riktlinje 2.1: App Completeness, som omfattar krascher, platshållarinnehåll, ofullständig information med mera."

Varför fångar inte test av debugbygget 2.1-problem?

Ett debugbygge körs inte på samma sätt som granskarens kopia. Granskaren installerar ett distributionssignerat releasebygge på en ren enhet, utan sparad session och utan debuggenvägar.

Din simulator är redan inloggad. Ditt lokala API kanske pekar mot en stagingserver som aldrig går ner. Debugflaggor hoppar över betalväggen och funktionsflaggor är påslagna som standard. Granskaren får inget av det. Apples granskningssida ber dig också att "testa noggrant på enheter med den senaste programvaran", så granskaren kan köra en nyare iOS-version än din testtelefon.

TestFlight är det närmaste du kommer granskarens miljö. Enligt TestFlight-översikten kan du lägga till upp till 100 interna testare från ditt App Store Connect-team och upp till 10 000 externa testare. Du kan testa ett bygge i upp till 90 dagar. Ladda upp exakt det bygge du tänker skicka in, installera det från TestFlight på en enhet som aldrig har kört appen och testa den kopian.

Vad ska en testplan för releasebygget täcka innan du skickar in igen?

En testplan för releasebygget kontrollerar alla sätt som en ny granskare kan fastna på: start, behörigheter, inloggning, backend, innehåll, länkar, köp, nätverksfel och iPad. Kör stegen i ordning på TestFlight-bygget och anteckna varje resultat så att du kan citera det i dina granskningsanteckningar.

1. Ren installation på senaste iOS. Radera eventuell tidigare kopia, installera från TestFlight och starta utan sparat tillstånd. Kallstarta tre gånger och kontrollera att introduktionsflödet inte kraschar.
2. Neka varje behörighetsfråga en gång. Neka aviseringar, plats, kamera och spårning. Appen ska ändå nå en användbar skärm. Kontrollera också att Info.plist har en användningsbeskrivning för varje skyddad resurs som appen eller dess SDK:er använder.
3. Logga in med exakt de demouppgifter du angett. Kopiera dem från App Store Connect, inte från din lösenordshanterare. Kontot ska ha realistisk data, inte kräva e-postverifiering och inte använda tvåfaktorsautentisering kopplad till din egen telefon.
4. Kontrollera att backenden är produktion och igång. Bygget måste peka mot produktionsendpoints. Hastighetsbegränsningar, IP-tillåtelselistor och geoblockering får inte stänga ute en granskare. Riktlinje 2.1(a) uppmanar dig att slå på din backendtjänst.
5. Gå igenom varje flik och skärm. Leta efter lorem ipsum, "Kommer snart"-skärmar, tomma vyer utan förklaring, testbilder och knappar som inte gör något.
6. Tryck på varje länk. Det gäller integritetspolicy, support, villkor och alla webbvyer. Apple säger: "En länk till användarsupport med aktuella kontaktuppgifter och en länk till din integritetspolicy krävs för alla appar."
7. Öppna varje köp i appen. Logga in med ett nytt konto. Kontrollera att varje produkt som skickats in med versionen visas med ett pris, kan köpas i sandlådan och att Återställ köp fungerar.
8. Testa på ett långsamt eller trasigt nätverk. Slå på flygplansläge mitt i ett flöde. Ett tydligt felmeddelande är okej. En laddningsindikator som aldrig slutar snurra, eller en krasch, är det inte.
9. Kontrollera iPad om du stöder den. Om appen körs på iPad, starta den där och se till att layouten inte låser fast användaren.

Demokontot i steg 3 orsakar fler upprepade avslag än något annat steg. Vår guide om att sätta upp ett demokonto för App Store-granskningen visar hur du skapar ett som håller.

Hur kopplar du ett 2.1-avslagsmeddelande till en åtgärd?

För att koppla ett 2.1-avslag till en åtgärd läser du meningen efter riktlinjenumret. Den beskriver symptomet, och varje symptom pekar på ett steg i testplanen.

Anta att en app för vanespårning avvisas med meddelandet "We were unable to review the app because it crashed on launch." En andra kommentar säger att granskaren inte kunde hitta köpen i appen. Tabellen nedan kopplar vanliga symptom till en orsak, ett test och en åtgärd.

För en bredare metod att tolka alla typer av avslagsmeddelanden, se App Store-avslag: så åtgärdar du det, riktlinje för riktlinje.

Hur såg andra utvecklares 2.1-avslag ut?

Offentliga 2.1-fall följer samma mönster. Appen fungerar i utvecklarens miljö och misslyckas för granskaren på grund av något som bara en ny installation eller en främlings inloggning avslöjar.

• Krasch på grund av en saknad användningsbeskrivning. På Solar2D-forumet fick en utvecklare beskedet "We were unable to review the app because it crashed on launch" på en iPhone 13 mini med iOS 18.3.2, trots att appen fungerade i TestFlight. En annan medlem hittade detta i den bifogade kraschloggen: "This app has crashed because it attempted to access privacy-sensitive data without a usage description." Utvecklaren rapporterade: "It passed after adding : NSUserTrackingUsageDescription."
• Sociala inloggningar som granskaren inte kunde använda. En utvecklare på Apple Developer Forums rapporterade upprepade 2.1-avslag eftersom granskarna "inte kunde använda sociala inloggningar". Utvecklaren hade angett demokonton för Apple och Google, men inloggningen med Apple-ID krävde en verifieringskod som skickades till utvecklarens telefon. Apples personal svarade att App Review skulle kontakta utvecklaren direkt. Ingen offentlig lösning publicerades.
• Köp i appen som "inte kunde hittas i den inskickade binären". I en tråd i RevenueCats community fick en utvecklare avslag eftersom en månadsplan inte hittades i binären, trots att köp i sandlådan fungerade. En hjälpare berättade att ett liknande avslag löstes genom att svara med en detaljerad genomgång och skärmbilder av varje väg till betalväggen. RevenueCats personal rådde att visa varje inskickad produkt på standardbetalväggen och att hålla StoreKit-testfiler utanför Archive-schemat.

I alla tre fallen klarade utvecklarens egna tester sig. Felet uppstod bara utifrån granskarens utgångsläge: ingen telefon för 2FA, ingen tidigare session och ingen kunskap om var betalväggen fanns. Det är just det utgångsläget som testplanen ovan återskapar.

Vad ska anteckningarna till App Review innehålla efter ett 2.1-avslag?

Granskningsanteckningar efter ett 2.1-avslag ska ge fungerande demouppgifter, lista vad som har ändrats sedan det avvisade bygget och ange exakt var köpen i appen och eventuella mindre uppenbara funktioner finns.

Apples granskningssida säger att kontouppgifter och särskild konfiguration ska läggas i avsnittet App Review Information. Om en funktion kräver hårdvara eller en miljö som är svår att sätta upp ska du "vara beredd att tillhandahålla en demovideo eller hårdvaran". Riktlinje 2.3.1(a) tillägger att nya funktioner måste beskrivas "specifikt" i Notes for Review och att "generiska beskrivningar avvisas". En kort, strukturerad anteckning fungerar bra:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Om juridiska eller säkerhetsmässiga skyldigheter utesluter ett demokonto tillåter riktlinje 2.1(a) ett inbyggt demoläge, men endast efter förhandsgodkännande från Apple, och det läget måste visa appens fullständiga funktioner. Byt inte till ett demoläge utan det godkännandet.

Hur skickar du in igen eller överklagar ett 2.1-avslag?

För att skicka in igen efter ett 2.1-avslag laddar du upp eller väljer det bygge du har testat, svarar App Review i App Store Connect med vad du har ändrat, uppdaterar granskningsanteckningarna och skickar in på nytt. Överklaga bara om du anser att granskaren har missförstått appen.

1. Kontrollera att byggnumret som är kopplat till versionen i App Store Connect stämmer med det TestFlight-bygge du har testat.
2. Svara på avslagsmeddelandet med en kort sammanfattning av varje åtgärd. För ett problem med köp eller navigering, lägg till steg-för-steg-instruktioner och skärmbilder.
3. Uppdatera avsnittet App Review Information med aktuella inloggningsuppgifter och anteckningar.
4. Skicka in för granskning. I oktober 2026 uppger Apple att man vanligtvis granskar "minst 50 % av inskickningarna på mindre än 24 timmar och 90 % på mindre än 48 timmar".

Om du anser att Apple har fel kan du via App Review-sidan överklaga till App Review Board. Ange konkreta skäl till varför appen uppfyller riktlinjerna och "skicka bara ett överklagande per inskickning som inte klarade granskningen". För ett 2.1-avslag går det dock oftast snabbare att återskapa problemet på en ren enhet än att argumentera. Om du hellre vill lämna över den nya inskickningen täcker vår tjänst för App Store-inskickning förberedelser inför granskningen och hantering av avslagsfeedback för båda butikerna för $599, med avgifter för utvecklarkonton utöver det.

2.1-problem återkommer ofta i senare uppdateringar: en ny funktionsflagga, en roterad API-nyckel eller ett demokonto som har gått ut. Lägg in den här testplanen i din releaserutin tillsammans med checklistan för App Store-inskickning. För uppdateringar begränsar en stegvis lansering hur många användare en missad bugg når. Vill du ha en second opinion på ett avvisat bygge kan du mejla yagyeshsrbobde@gmail.com med avslagsmeddelandet.