App Store-afwijzing 2.1 (App Completeness): testplan voor de release-build vóór herindiening (2026)

Een App Store-afwijzing onder 2.1 App Completeness betekent dat de reviewer je app niet kon gebruiken zoals een klant dat zou doen. Misschien crashte de app, toonde hij placeholdercontent, bleef de reviewer hangen op een inlogscherm of was een in-app aankoop onvindbaar. De oplossing is zelden één regel code. Voer voordat je opnieuw indient een kort testplan uit op de release-build, met een verse installatie en dezelfde inloggegevens die je aan App Review geeft. Dit artikel loopt dat plan door en laat zien hoe andere developers dezelfde afwijzing hebben opgelost.

Wat controleert App Store-richtlijn 2.1 App Completeness?

Richtlijn 2.1 controleert of de build die je indient een afgewerkte, werkende app is. Er zijn volledige metadata nodig, werkende links, een demo-login, een live backend en in-app aankopen die de reviewer kan vinden en gebruiken.

Apple's App Review Guidelines splitsen 2.1 op in twee delen. 2.1(a) stelt dat inzendingen "definitieve versies moeten zijn, met alle benodigde metadata en volledig werkende URL's" en dat placeholdertekst en lege websites verwijderd moeten worden. Ook moet je op een apparaat testen op bugs en stabiliteit, en "demo-accountgegevens meesturen (en je backendservice aanzetten!) als je app een login heeft." Apple "wijst onvolledige app-bundles en binaries af die crashen of duidelijke technische problemen vertonen." 2.1(b) stelt dat in-app aankopen "volledig, actueel, zichtbaar voor de reviewer en functioneel" moeten zijn. Is een geconfigureerde aankoop niet in de app te vinden, leg dan in je review-notities uit waarom.

Deze afwijzing komt vaak voor. Apple's pagina Preparing for App Review zegt: "Gemiddeld heeft meer dan 40% van de onopgeloste problemen betrekking op richtlijn 2.1: App Completeness, die crashes, placeholdercontent, onvolledige informatie en meer omvat."

Waarom vang je 2.1-problemen niet op door de debug-build te testen?

Een debug-build draait niet zoals het exemplaar van de reviewer. De reviewer installeert een release-build met distributiesignering op een schoon apparaat, zonder opgeslagen sessie en zonder debug-snelkoppelingen.

Je simulator is al ingelogd. Je lokale API wijst misschien naar een stagingserver die nooit platgaat. Debugflags slaan de paywall over en featureflags staan standaard aan. De reviewer krijgt daar niets van. Apple's reviewpagina vraagt je ook om "grondig te testen op apparaten met de nieuwste software", dus de reviewer draait mogelijk een nieuwere iOS-versie dan je testtelefoon.

TestFlight komt het dichtst bij de opstelling van de reviewer. Volgens het TestFlight-overzicht kun je tot 100 interne testers uit je App Store Connect-team toevoegen en tot 10.000 externe testers. Een build is tot 90 dagen testbaar. Upload precies de build die je wilt indienen, installeer hem via TestFlight op een apparaat waarop de app nog nooit heeft gedraaid, en test dat exemplaar.

Wat moet een testplan voor de release-build afdekken voordat je opnieuw indient?

Een testplan voor de release-build controleert elke manier waarop een nieuwe reviewer kan vastlopen: opstarten, permissies, inloggen, backend, content, links, aankopen, netwerkstoringen en iPad. Voer de stappen op volgorde uit op de TestFlight-build en noteer elk resultaat, zodat je het in je review-notities kunt aanhalen.

1. Schone installatie op de nieuwste iOS. Verwijder eerdere exemplaren, installeer via TestFlight en start zonder opgeslagen status. Doe drie keer een koude start en controleer dat de onboarding niet crasht.
2. Weiger elke permissieprompt één keer. Weiger meldingen, locatie, camera en tracking. De app moet nog steeds een bruikbaar scherm bereiken. Controleer ook dat Info.plist een usage description bevat voor elke beschermde bron die de app of de SDK's gebruiken.
3. Log in met exact de demogegevens. Kopieer ze uit App Store Connect, niet uit je wachtwoordmanager. Het account moet realistische data hebben, geen e-mailverificatie vereisen en geen tweestapsverificatie gebruiken die aan je eigen telefoon gekoppeld is.
4. Controleer of de backend productie is en live staat. De build moet naar productie-endpoints wijzen. Rate limits, IP-allowlists en geoblocking mogen een reviewer niet buitensluiten. Richtlijn 2.1(a) zegt dat je je backendservice moet aanzetten.
5. Loop elk tabblad en scherm door. Zoek naar lorem ipsum, "Binnenkort beschikbaar"-schermen, lege staten zonder uitleg, testafbeeldingen en knoppen die niets doen.
6. Tik op elke link. Dat omvat privacybeleid, support, voorwaarden en eventuele webviews. Apple zegt: "Een link naar gebruikersondersteuning met actuele contactgegevens en een link naar je privacybeleid zijn verplicht voor alle apps."
7. Open elke in-app aankoop. Log in met een nieuw account. Controleer dat elk product dat met de versie is ingediend met een prijs verschijnt, in de sandbox gekocht kan worden en dat Aankopen herstellen werkt.
8. Test op een traag of haperend netwerk. Zet halverwege een flow de vliegtuigmodus aan. Een duidelijke foutmelding is prima. Een spinner die nooit stopt, of een crash, is dat niet.
9. Controleer de iPad als je die ondersteunt. Draait de app op iPad, start hem daar en zorg dat de lay-out de gebruiker niet vastzet.

Het demo-account uit stap 3 veroorzaakt meer herhaalde afwijzingen dan welke andere stap ook. Onze gids over een demo-account voor App Store-review instellen legt uit hoe je er een bouwt dat blijft werken.

Hoe koppel je een 2.1-afwijzingsbericht aan een oplossing?

Om een 2.1-afwijzing aan een oplossing te koppelen, lees je de zin na het richtlijnnummer. Die noemt het symptoom, en elk symptoom wijst naar één stap in het testplan.

Stel dat een habit-tracker wordt afgewezen met het bericht "We were unable to review the app because it crashed on launch" (de app crashte bij het opstarten). Een tweede notitie zegt dat de reviewer de in-app aankopen niet kon vinden. De tabel hieronder koppelt veelvoorkomende symptomen aan een oorzaak, een test en een oplossing.

Voor een bredere aanpak om elk afwijzingsbericht te lezen, zie App Store-afwijzing: zo los je het op, richtlijn per richtlijn.

Hoe zagen de 2.1-afwijzingen van andere developers eruit?

Publieke 2.1-gevallen volgen hetzelfde patroon. De app werkt in de opstelling van de developer en faalt bij de reviewer door iets wat alleen een verse installatie of de login van een buitenstaander aan het licht brengt.

• Crash door een ontbrekende usage description. Op de Solar2D-forums kreeg een developer te horen "We were unable to review the app because it crashed on launch" op een iPhone 13 mini met iOS 18.3.2, hoewel de app in TestFlight wel werkte. Een ander forumlid vond dit in het bijgevoegde crashlog: "Deze app is gecrasht omdat hij probeerde privacygevoelige data te openen zonder usage description." De developer meldde: "Hij werd goedgekeurd na het toevoegen van NSUserTrackingUsageDescription."
• Social logins die de reviewer niet kon gebruiken. Een developer op de Apple Developer Forums meldde herhaalde 2.1-afwijzingen omdat reviewers "social logins niet konden gebruiken." Hij had demo-accounts voor Apple en Google aangeleverd, maar de Apple ID-login vereiste een verificatiecode die naar de telefoon van de developer werd gestuurd. Apple-medewerkers antwoordden dat App Review rechtstreeks contact zou opnemen. Er is geen publieke oplossing gepost.
• In-app aankopen "niet gevonden in de ingediende binary." In een thread in de RevenueCat-community werd een developer afgewezen omdat een maandabonnement niet in de binary werd gevonden, hoewel sandbox-aankopen werkten. Een helper vertelde dat een vergelijkbare afwijzing was opgelost door te reageren met een gedetailleerde walkthrough en screenshots van elk pad naar de paywall. RevenueCat-medewerkers adviseerden om elk ingediend product op de standaardpaywall te tonen en StoreKit-testbestanden buiten het Archive-scheme te houden.

In alle drie de gevallen slaagden de eigen tests van de developer. De fout kwam pas aan het licht vanuit het startpunt van een reviewer: geen telefoon voor 2FA, geen eerdere sessie en geen idee waar de paywall zat. Precies dat startpunt bootst het testplan hierboven na.

Wat moet er in de App Review-notities staan na een 2.1-afwijzing?

Review-notities na een 2.1-afwijzing moeten werkende demogegevens bevatten, opsommen wat er sinds de afgewezen build is veranderd, en precies vermelden waar de in-app aankopen en minder voor de hand liggende functies te vinden zijn.

Apple's reviewpagina zegt dat je accountgegevens en speciale configuratie in de sectie App Review Information moet zetten. Vereist een functie hardware of een omgeving die lastig op te zetten is, "houd er dan rekening mee dat je een demovideo of de hardware moet aanleveren." Richtlijn 2.3.1(a) voegt daaraan toe dat nieuwe functies "specifiek" beschreven moeten worden in de Notes for Review, en dat "algemene beschrijvingen worden afgewezen." Een korte, gestructureerde notitie werkt goed:

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.

Sluiten wettelijke of beveiligingsverplichtingen een demo-account uit, dan staat richtlijn 2.1(a) een ingebouwde demomodus toe, maar alleen met voorafgaande goedkeuring van Apple, en die modus moet de volledige functies en functionaliteit van de app tonen. Stap niet over op een demomodus zonder die goedkeuring.

Hoe dien je opnieuw in of ga je in beroep tegen een 2.1-afwijzing?

Om na een 2.1-afwijzing opnieuw in te dienen, upload of selecteer je de build die je hebt getest, reageer je in App Store Connect aan App Review met wat je hebt veranderd, werk je de review-notities bij en dien je opnieuw in. Ga alleen in beroep als je denkt dat de reviewer de app verkeerd heeft begrepen.

1. Controleer dat het buildnummer dat in App Store Connect aan de versie is gekoppeld overeenkomt met de TestFlight-build die je hebt getest.
2. Reageer op het afwijzingsbericht met een korte samenvatting van elke fix. Voeg bij een aankoop- of navigatieprobleem stapsgewijze instructies en screenshots toe.
3. Werk de sectie App Review Information bij met actuele inloggegevens en notities.
4. Dien in voor review. Per oktober 2026 zegt Apple dat het doorgaans "minstens 50% van de inzendingen binnen 24 uur en 90% binnen 48 uur" beoordeelt.

Denk je dat Apple het mis heeft, dan kun je via de App Review-pagina in beroep gaan bij de App Review Board. Geef concrete redenen waarom de app aan de regels voldoet, en "dien slechts één beroep in per inzending die niet door de review is gekomen." Bij een 2.1-afwijzing is het probleem reproduceren op een schoon apparaat meestal wel sneller dan in discussie gaan. Wil je de herindiening liever uitbesteden, dan dekt onze App Store-indieningsservice reviewvoorbereiding en afhandeling van afwijzingsfeedback voor beide stores voor $599, exclusief de kosten van het developeraccount.

2.1-problemen keren vaak terug in latere updates: een nieuwe featureflag, een geroteerde API-sleutel of een verlopen demo-account. Neem dit testplan op in je releaseroutine, naast de checklist voor App Store-indiening. Bij updates beperkt een gefaseerde release hoeveel gebruikers een gemiste bug bereikt. Wil je een second opinion over een afgewezen build, mail dan het afwijzingsbericht naar yagyeshsrbobde@gmail.com.