Checklist voor het indienen bij de App Store (2026): van Xcode 26-build tot Submit for Review

Een checklist voor het indienen bij de App Store is een lijst van alles wat tegelijk klaar moet zijn voordat je indient: een werkende build, een kloppende vermelding, eerlijke privacyantwoorden en genoeg context zodat een reviewer je app kan gebruiken. Alleen een geslaagde build is niet genoeg. De zes onderdelen hieronder volgen de volgorde waarin App Store Connect erom vraagt, en elk onderdeel begint met een kort antwoord waarmee je direct aan de slag kunt.

Wat moet een App Store-inzending hebben voordat je op Submit drukt?

Een App Store-inzending heeft een verwerkte build nodig die aan de versie is gekoppeld, de verplichte metadata van de versie, screenshots, een privacybeleid, contactgegevens voor App Review en, als de app een login heeft, werkende demo-inloggegevens. Apples eigen lijst "Before You Submit" in de App Review Guidelines voegt daar twee punten aan toe: "Zet backenddiensten aan zodat ze tijdens de review actief en bereikbaar zijn" en leg niet-voor-de-hand-liggende functies uit in de reviewnotities.

Welke instellingen voor account en app-record moeten klaar zijn?

Je hebt een actief Apple Developer-lidmaatschap nodig, een app-record waarvan de bundle-ID overeenkomt met je gesigneerde build, en iemand in het team met de rol Account Holder, Admin of App Manager. Dat zijn de rollen die Apples pagina Submit an app vereist om te kunnen indienen.

Bij het aanmaken van het record kies je de naam, de primaire taal en de SKU. De SKU is intern en klanten zien hem nooit. Verkoop je een betaalde app of in-app-aankopen, rond dan eerst de overeenkomsten voor betaalde apps, de belastinggegevens en de bankgegevens af. Een niet-ondertekende overeenkomst kan een commerciële lancering ophouden, ook als de build in orde is.

Welke buildvereisten gelden in 2026 voor uploads naar de App Store?

Vanaf oktober 2026 staat op Apples pagina upcoming requirements dat "apps die naar App Store Connect worden geüpload, gebouwd moeten zijn met Xcode 26 of later met een SDK voor iOS 26, iPadOS 26, tvOS 26, visionOS 26 of watchOS 26" (sinds 28 april 2026). Er staat ook dat iOS- en iPadOS-apps "iOS 13 of later als doel moeten hebben" (sinds 9 september 2026).

• Verhoog bij elke upload het buildnummer en zorg dat het versienummer overeenkomt met de release die je wilt uitbrengen.
• Werk de Xcode-image in je CI (Codemagic, Expo EAS, GitHub Actions enzovoort) bij, en niet alleen op je eigen machine.
• Beantwoord na de verwerking een eventuele vraag over exportcompliance en koppel de verwerkte build aan de versie.
• Installeer de TestFlight-build op een fysiek toestel. Test onboarding, inloggen, offlinesituaties, aankopen en het herstellen van aankopen. Dat het in de simulator werkt, bewijst niet dat de gedistribueerde build werkt.
• Lees de e-mail die App Store Connect na de upload stuurt. ITMS-waarschuwingen over privacymanifesten of SDK-versies worden blokkades als je ze negeert.

Richtlijn 2.1(a) is duidelijk over wat er anders gebeurt: "We wijzen onvolledige app-bundels en binaries af die crashen of duidelijke technische problemen vertonen." Verwijder placeholderschermen, debugmenu's en dode links voordat je archiveert. Ons testplan voor release-builds onder 2.1 behandelt deze controles in detail.

Welke screenshots en metadata vereist App Store Connect?

Vanaf oktober 2026 vereisen Apples screenshotspecificaties minstens één screenshot voor "iPhone met Dynamic Island (middelgroot scherm)", bijvoorbeeld 1206 × 2622 of 1179 × 2556 staand. Apps die op iPad draaien, hebben daarnaast minstens één screenshot voor iPad 13 inch nodig, zoals 2064 × 2752 of 2048 × 2732.

Je "kunt tot 10 screenshots per toestelformaat uploaden in .jpeg-, .jpg- of .png-formaat", en "afbeeldingen mogen geen alfakanalen of transparantie bevatten". Is je interface op alle formaten hetzelfde, upload dan alleen de hoogste vereiste resolutie; App Store Connect schaalt die omlaag. Richtlijn 2.3.3 zegt dat screenshots "de app in gebruik moeten tonen, en niet alleen de titelafbeelding, het inlogscherm of het opstartscherm".

• Schrijf een beschrijving die zegt voor wie de app is en wat iemand in de eerste sessie kan doen.
• Houd naam, ondertitel en zoekwoorden relevant. Herhaal geen zoekwoorden en gebruik geen namen van concurrenten.
• Zorg dat de support-URL en de URL van het privacybeleid laden zonder in te loggen.
• Vul de vragenlijst voor de leeftijdsclassificatie in op basis van wat de app werkelijk bevat en kan.
• Toon de huidige build in de screenshots, inclusief een eventuele paywall waar gebruikers op stuiten.

Hoe zorg je dat je privacyantwoorden overeenkomen met de app?

Om je privacyantwoorden te laten overeenkomen met de app, maak je een lijst van elke SDK die je meelevert en welke gegevens die verzamelt. Op basis van die lijst vul je App Privacy in, schrijf je het privacybeleid en richt je het gedrag in de app in. Richtlijn 2.3 zegt dat je metadata, "inclusief privacy-informatie", de app nauwkeurig moet weergeven.

Richtlijn 5.1.1(i) stelt: "Alle apps moeten een link naar hun privacybeleid bevatten in het metadataveld van App Store Connect en op een goed bereikbare manier in de app." Richtlijn 5.1.1(v) voegt toe: "Als je app het aanmaken van een account ondersteunt, moet je ook het verwijderen van het account in de app aanbieden." SDK's voor analytics, crashrapportage, advertenties en inloggen veranderen meestal je antwoorden, dus controleer ze met onze SDK-audit voor privacylabels. Controleer ook of je app en elke meegeleverde SDK een privacymanifest PrivacyInfo.xcprivacy bevatten dat alle required-reason-API's dekt die ze gebruiken.

Wat moet er in App Review Information staan?

App Review Information moet een contactpersoon bevatten die ook echt reageert, demo-inloggegevens die werken en niet verlopen, en notities die de reviewer direct naar je kernfuncties leiden. Richtlijn 2.1(a) vraagt je om "gegevens van een demo-account mee te sturen (en je backenddienst aan te zetten!) als je app een login heeft"; een ingebouwde demomodus in plaats van een account vereist vooraf toestemming van Apple.

Een uitgewerkt voorbeeld van reviewnotities: "Log in met het meegeleverde reviewaccount. Open Library, kies het voorbeeldproject en tik op Export. Op het account zijn alle premiumfuncties ontgrendeld. Locatiefuncties gebruiken een gesimuleerde stad, dus reizen is niet nodig." Stuur reviewers niet naar een leeg account, een eenmalige code die verloopt of een flow die alleen werkt als jij online bent om goed te keuren. Onze handleiding voor het opzetten van een demo-account laat zien hoe je een reviewerlogin bouwt die standhoudt.

Hoe dien je een app in voor review in App Store Connect?

Om een app in te dienen voor review koppel je de build aan de versie, klik je op Add for Review en daarna op Submit for Review. Alleen Add for Review stuurt niets naar Apple. De volgorde hieronder volgt Apples pagina Submit an app zoals die er in oktober 2026 uitziet.

1. Selecteer in Apps de app en klik in de zijbalk op de appversie.
2. Scrol naar het onderdeel Build en controleer of de juiste build is gekoppeld.
3. Kies in het onderdeel App Store Version Release voor handmatige release als je zelf de lanceringsdag wilt bepalen, en klik op Save.
4. Klik op Add for Review en kies een bestaande conceptinzending of maak een nieuwe aan. De status verandert in Ready for Review.
5. Klik op Submit for Review. Wanneer de review begint, verandert de status in In Review.
6. Bewaar een kopie van de ingediende metadata en notities, en houd de e-mail van het reviewcontact in de gaten voor vragen.

Komt de inzending afgewezen terug, lees dan het richtlijnnummer en de toelichting van de reviewer voordat je iets aanpast. Sommige oplossingen betreffen alleen metadata. Andere vereisen een nieuwe build. Onze gids over App Store-afwijzingen legt uit hoe je ziet met welk type je te maken hebt.

Wat ging er bij andere ontwikkelaars mis bij het indienen?

In beide openbare gevallen hieronder werkte de app voor de ontwikkelaar zelf, en kwam het probleem pas aan het licht in de geüploade build of in de eerste sessie van de reviewer.

Een ontwikkelaar op het Adalo-forum kreeg een afwijzing onder richtlijn 2.1: "we konden niet inloggen met de demo-inloggegevens die je hebt opgegeven." De gegevens waren geldig, maar de eerste tik op de loginknop deed niets en pas een tweede tik werkte, omdat voorwaardelijke navigatie op de loginknop draaide voordat de gebruikerssessie was geregistreerd. De oplossing was de loginknop naar een leeg tussenscherm te laten verwijzen waarop de voorwaardelijke acties stonden, waarna de app opnieuw werd ingediend.

Een ontwikkelaar op het JUCE-forum ontving na een upload "ITMS-91053: Missing API declaration", met de melding dat nieuwe uploads "een NSPrivacyAccessedAPITypes-array moeten bevatten in het privacymanifest van je app". De gemarkeerde categorieën waren SystemBootTime en FileTimestamp, en een andere gebruiker meldde UserDefaults. De oplossing was een PrivacyInfo.xcprivacy-bestand met goedgekeurde redencodes, toegevoegd als Xcode-resource. In de eerste versie van één gebruiker ontbrak een type-key, wat ITMS-91056 voor een ongeldig manifest opleverde totdat dat was gecorrigeerd.

Beide ontwikkelaars hadden alleen op hun eigen setup getest. Test de build die Apple daadwerkelijk ontvangt met een nieuwe login, en lees elke e-mail na de upload, voordat je op Submit for Review drukt. Wil je dat iemand anders het pakket nog eens nakijkt, bekijk dan onze diensten voor het indienen.