App Store Vereisten: Wat U Moet Controleren Voordat U Inzendt

Uw releasedatum ligt in de handen van een beoordelaar die uw product nooit heeft gezien. Die kan de hele build terugsturen om een verlopen demowachtwoord of een onbeantwoord formulier voor de leeftijdsclassificatie. App Store vereisten zijn grotendeels administratief, en dat werk is het eerste dat sneuvelt wanneer een release krap wordt. Juist de makkelijke problemen controleert niemand. Ze opsporen voordat u inzendt, daar is App Store nalevingstesten voor.

Apple’s eigen App Review-pagina meldt dat ruim 40% van de onopgeloste problemen terug te voeren is op richtlijn 2.1, App Completeness. Die categorie dekt crashes, placeholdercontent en alles wat leeg is gebleven. Uw app kan dus perfect werken en toch de review niet halen. Goedkeuring begint met een korte lijst die niets te maken heeft met hoe goed uw app is.

U hebt een actief Apple Developer Program-lidmaatschap nodig en een volledig App Store Connect-record. De build zelf moet gecompileerd zijn met Xcode 26 en de iOS 26 SDK. Apple vraagt daarnaast om een werkend demo-account, actuele antwoorden op de leeftijdsclassificatie en een privacybeleid dat overeenkomt met wat uw app verzamelt.

Elk item op die lijst is eenvoudig te bevestigen, maar elk ervan kan een release stoppen. Dit artikel behandelt wat u moet controleren voordat u inzendt, wat een afwijzing kost in kalendertijd, en wie elke beslissing hoort te bezitten.

App Store Vereisten Die U Moet Halen Voordat U Inzendt

Twee Apple App Store-inzendingsvereisten zijn in 2026 veranderd, en geen van beide heeft met testen te maken. Toch verrassen ze teams die hun eerste update van het jaar uitbrengen. De ene maakte antwoorden op Apple’s herziene vragen over leeftijdsclassificatie verplicht op 31 januari. De andere verplicht u elke binary te bouwen met Xcode 26 en de iOS 26 SDK. Die werd actief op 28 april en geldt nu voor alle apps.

Beide deadlines staan op de pagina met komende vereisten, en als u er een mist, komt u niet verder dan de uploadfase, nog voor de review begint. Elk ervan bevestigen kost minuten, maar niemand plant tijd in voor iets dat geen feature is.

Het derde item is exportnaleving, en dat heeft ook niets met testen te maken. Amerikaans handelsrecht dekt software die encryptie gebruikt, dus Apple moet vragen of de uwe dat doet. In werkelijkheid doet vrijwel elke app dat, want elke verbinding via HTTPS telt mee. U kunt die vraag bij elke inzending met de hand beantwoorden. Het alternatief is om het eenmalig vast te leggen in het Info.plist-configuratiebestand van de app, waarna Apple ophoudt met vragen.

Die drie zijn onderdeel van een langere lijst. De tabel hieronder toont de App Store vereisten die de upload blokkeren, samen met wie in uw bedrijf elk ervan werkelijk bezit.

Die laatste rij is een harde stop als u in de Europese Unie verkoopt. De Digital Services Act verplicht Apple om voor elke ontwikkelaar die daar een app aanbiedt een geverifieerde handelsnaam en adres te publiceren. Zolang u de uwe niet aanlevert en Apple die niet verifieert, verdwijnt uw app dus volledig uit de EU App Store. Legal en finance bezitten deze, niet engineering, dus begin er vroeg aan. Zo’n hiaat hoort bij software-nalevingstesten en niet bij de mobiele QA-cyclus.

Apple App Store vereisten gaan dieper dan deze tabel, al blokkeren alleen de rijen hierboven werkelijk de upload. Brengt u de Android-build in hetzelfde venster uit, dan dekt onze gids over het doorkomen van de Google Play-review hetzelfde terrein.

De Zes Vragen Die U Moet Beantwoorden Voordat U Inzendt

Die vereisten halen brengt u alleen in de wachtrij. Daarna hangt alles af van wat een beoordelaar werkelijk met uw build kan doen. Zoek op een App Store-inzendingschecklist en u vindt er een die voor engineers is geschreven. Die somt alles op wat een ontwikkelaar aanklikt en vertelt een ondernemer niets over de vraag of de launch veilig is. De versie hieronder is daarom opgebouwd rond wat u hardop moet kunnen bevestigen, in een releaseoverleg.

Komt een Onbekende Zonder Uw Hulp in Uw App?

Een beoordelaar moet elke feature bereiken die u uitbrengt, en die begint met niets anders dan uw build. Daarom vraagt Apple’s richtlijn 2.1 om demo-accountgegevens en een werkende back-end zodra uw app een login bevat. De meeste teams leveren beide aan, maar minder teams controleren of de inloggegevens nog werken op de ochtend dat een beoordelaar ze opent.

Controleer drie dingen:

• Het demo-account verloopt niet en wordt niet geblokkeerd na mislukte pogingen.
• De back-end waar het naar wijst draait echt, niet alleen uitgerold.
• Notes for Review beschrijft elke nieuwe feature specifiek, want Apple wijst algemene formuleringen af.

Als juridische of securityregels u verhinderen een echt account te overhandigen, accepteert Apple in plaats daarvan een ingebouwde demomodus, met voorafgaande goedkeuring. Die goedkeuring krijgen kost tijd waar u rekening mee moet houden.

Is de Build Die U Inzendt de Build Die U Hebt Getest?

Releasebuilds wijken vaak op kleine, dure manieren af van wat u hebt getest:

• Een feature flag die aan bleef staan
• Een staging-endpoint hard gecodeerd in een configuratiebestand
• Een in-app aankoop die nog naar de sandbox wijst

Geen daarvan valt op bij dagelijks gebruik, want uw team draait een andere build. De bevestiging is één zin: iemand heeft de exacte binary op een schoon toestel gezet en het hoofdpad van begin tot eind doorlopen. Dat is de reden dat mobiele applicatietesten tegen de release candidate hoort te draaien en niet tegen een eerdere branch. Dat is ook de goedkoopste plek om stabiliteitsproblemen te vinden.

Belooft Uw Storevermelding Iets Dat de Build Niet Doet?

Marketing schrijft de storevermelding weken voordat engineering de build afrondt, met screenshots uit ontwerpen en teksten uit de roadmap. Dan schuift een feature door, en niemand werkt de tekst bij.

Apple’s richtlijn 2.3 behandelt die mismatch als onjuiste metadata, dus lees uw eigen vermelding naast de build die u gaat versturen. Elke belofte heeft een bijbehorende feature nodig die een beoordelaar zonder instructies kan bereiken.

Hebt U Elke Vraag Beantwoord Die Apple Nu Stelt?

De formulieren in App Store Connect zijn geen formaliteit, en ze veranderen vaker dan teams verwachten. Vooral privacyverklaringen moeten overeenkomen met wat uw app werkelijk verzamelt, inclusief data die wordt opgehaald door SDK’s van derden die u niet hebt geschreven. Misschien weet niemand in uw team wat die libraries versturen, en juist daarom moet dit gecontroleerd worden in plaats van onthouden.

Kunstmatige intelligentie (AI) is het nieuwste gebied dat Apple heeft aangescherpt. Richtlijn 5.1.2(i) verplicht u om persoonsgegevens die u naar een AI van derden verstuurt te vermelden. U hebt ook expliciete toestemming nodig voordat die data verplaatst, wat we behandelden in Apple’s richtlijnen voor AI-gegevensdeling.

Kunnen Gebruikers Verwijderen, Herstellen en Rapporteren in Uw App?

Sommige vereisten gaan over wat uw app doet, niet over wat u erover zegt. Elk product dat aanmelden ondersteunt, moet ook accountverwijdering in de app aanbieden. Aankopen moeten te herstellen zijn, en elk ervan moet zichtbaar zijn voor de beoordelaar. Apps waarin gebruikers content publiceren, moeten iedereen de mogelijkheid geven een bericht te rapporteren en de auteur te blokkeren.

Een beoordelaar probeert elk van deze zaken, dus test ze op dezelfde manier op de build die u uitbrengt. Verwijderen kent de meeste randgevallen, dus reserveer daar tijd voor.

Wie Bezit het Antwoord Als het Terugkomt?

Dit is de vraag die ondernemers overslaan, en die de meeste kalendertijd kost. Een afwijzing komt binnen in Apple’s Resolution Center, de berichtenthread bij uw inzending, met een richtlijnnummer en een korte toelichting. Daarna moet iemand die lezen, bepalen of er een metadata-aanpassing of een nieuwe build nodig is, en reageren.

Benoem die persoon voordat u inzendt, wijs een achtervang aan, en controleer of geen van beiden op vakantie is tijdens het reviewvenster. Elk uur dat het antwoord ongelezen blijft, schuift uw releasedatum op.

Wat een Mislukte Inzending Uw Launch Kost

Een afwijzing is geen engineeringticket maar een zakelijke gebeurtenis met een rekening eraan vast. De meeste kosten landen bij mensen die de richtlijnen nooit hebben gelezen. Apple handelt 90% van de inzendingen binnen 24 uur af, dus een schone build gaat snel. De tweede review begint echter pas zodra uw herstel klaar is, en dat wachten kost u de dagen. De tabel hieronder toont wat opschuift en wie het opvangt.

Hoe lang dat duurt, hangt af van wat er stuk was. Een screenshot of beschrijving herstellen is een middag werk, daarna een nieuwe review. Codewijzigingen vragen eerst regressietesten, en zo wordt een kleine bug een week vertraging.

De goedkoopste manier om die lus te verkorten is weten wat hem meestal veroorzaakt. We zetten de veelvoorkomende oorzaken op een rij in redenen waarom apps worden afgekeurd, het artikel om te openen als uw inzending al is teruggekomen.

Waar Controles Voor Inzending Meestal Stuklopen

Teams gaan hier op twee tegengestelde manieren de fout in:

• De eerste is de iOS-inzendingschecklist als eenmalige gebeurtenis behandelen. Ze lopen die grondig door voor de eerste launch en slaan hem daarna over bij updates, precies wanneer het platform onder hen is verschoven. Apple’s regels veranderden alleen in de eerste 4 maanden van 2026 al twee keer.
• De tweede is de verkeerde laag te veel testen. Toegankelijkheid is het duidelijkste voorbeeld, want die blokkeert zelden een App Store-review. Teams negeren het daarom, of behandelen het als inzendingspoort, en beide lezingen missen het punt. De echte druk komt van de European Accessibility Act en van de gebruikers die u stilletjes kwijtraakt. Dat zet toegankelijkheidstesten voor mobiele apps op het releaseplan en niet op het inzendingsformulier.

App Store vereisten vroeg controleren kost een uur, plus een agendaherinnering voor de langzamere punten. Dezelfde hiaten tijdens de review vinden kan u de releasedatum kosten.

Hoe QAwerk een iOS-build Verifieert Voor Inzending

Wij testen uw werkelijke release candidate, niet een beschrijving daarvan. Dat betekent de App Store-reviewchecklist doorlopen tegen de exacte binary, geïnstalleerd op echte toestellen. Onze engineers doorlopen de flows voor aanmelden, aankopen, herstellen en verwijderen, en vergelijken daarna uw vermelding met wat de build werkelijk doet.

U krijgt een schriftelijk rapport van wat kan mislukken en waarom, met elk punt gekoppeld aan de richtlijn die het raakt. Precies dat deden we voor BeFamily, met meer dan 500 testgevallen op 9 toestellen voor de launch. De app heeft sindsdien geen grote problemen in productie gehad. Betrek ons erbij zolang de inzenddatum nog kan schuiven, dan is er ruimte om te herstellen wat we vinden zonder noodsprint.

QAwerk test mobiele releases sinds 2015, en we stappen in bij elke fase waarin uw project zich bevindt. Uw releasedatum is het enige dat u niet terugkrijgt, dus neem contact met ons op en laten we vinden wat Apple zou kunnen markeren.

FAQ

Hoe lang duurt het om een afgewezen App Store-inzending te herstellen?

Dat hangt af van welke App Store vereisten u hebt gemist. Metadataproblemen zoals een screenshot of beschrijving kosten een paar uur, daarna een nieuwe review die Apple meestal binnen een dag teruggeeft. Codeherstel duurt langer, want de opnieuw gebouwde app moet eerst regressietesten door. Plan voor het langzamere geval, want u weet pas welke u treft wanneer u antwoord krijgt.

Hoe lang duurt de App Store-review?

Apple beoordeelt 90% van wat het ontvangt binnen 24 uur. Eerste inzendingen vanaf een nieuw ontwikkelaarsaccount blijven vaak langer liggen, net als apps in gevoelige categorieën. Reken op 1 tot 3 dagen in plaats van goedkeuring dezelfde dag, en plan nooit een launchevenement rond een doorlooptijd van 24 uur.

Hebt u een demo-account nodig als uw app geen login heeft?

Dan hebt u er geen nodig, want Apple vraagt alleen om demogegevens wanneer uw app een login bevat. Het veld Notes for Review blijft wel belangrijk, om elke feature te beschrijven die niet vanzelf uit de interface blijkt, want algemene formuleringen worden afgewezen. Zonder inloggegevens opent degene die uw inzending oppakt simpelweg het product en werkt zich er zelfstandig door.

Kunt u Apple vragen uw app sneller te beoordelen?

Dat kan, al komen alleen twee situaties in aanmerking voor een verzoek om een versnelde review. De eerste is een kritieke bug die gebruikers in productie raakt, de tweede een app die aan een vaste publieke deadline hangt. Lever reproductiestappen voor het defect aan, of de naam en datum van het evenement. Goedkeuring wordt per geval beslist en is nooit gegarandeerd, dus plan er niet op.

Moet u een afwijzing aanvechten of herstellen en opnieuw inzenden?

Herstel en zend opnieuw in wanneer Apple gelijk heeft, en dat is meestal zo. Leg het voor aan de App Review Board wanneer u meent dat de richtlijn onjuist is toegepast. Apple staat één beroep toe per inzending die niet is doorgekomen, en verwacht dat u eerst elk verzoek om meer informatie beantwoordt. Een echte overtreding aanvechten kost u alleen dagen.