Is mijn iOS-app klaar voor publicatie?
Geen tool kan daar ja op zeggen. App Review beoordeelt een draaiende app, de inhoud en de metadata, en een checker ziet geen van die drie. Wat je vóór het indienen kunt vaststellen, is beperkter en nuttiger, en het zijn 12 vragen.
Wat klaar eigenlijk betekent
Klaar is geen score. Het is de toestand waarin niets in het project een eis tegenspreekt die App Review mechanisch afdwingt, en niets wat App Store Connect vraagt nog leeg is. Dat zijn twee verschillende stapels, ze worden op twee verschillende plekken gecontroleerd, en bijna elke vermijdbare afwijzing is iets dat in de ene stapel lag terwijl de ontwikkelaar naar de andere keek.
De 12 vragen hieronder zijn de vragen die het waard zijn om in het laatste uur voor het indienen te beantwoorden. Het zijn dezelfde 12 regels die ReviewAhead aan het eind van een rapport toont, met de antwoorden aan jou. Bij elke regel staat een link naar de uitgebreide pagina over de eis erachter, als die er is.
De checklist
In de volgorde waarin je ze afwerkt: eerst de build, omdat dat de enige is die na het uploaden niet meer te repareren is, dan wat een reviewer nodig heeft, en dan de productpagina.
Is wat je gaat uploaden echt een release-build?
Build settings gelden per configuratie, dus een waarde die je aanpaste terwijl de Debug-kolom geselecteerd was, compileert en uploadt gewoon. Wat er dan wordt uitgebracht, is niet geoptimaliseerd, bevat testability-symbolen, of heeft elke #if DEBUG-tak actief in de app die mensen downloaden. Controleer ENABLE_TESTABILITY, SWIFT_OPTIMIZATION_LEVEL en elke DEBUG=1-definitie in de Release-kolom, en controleer dat aps-environment op production staat in de entitlements waarmee je Release-configuratie ondertekent. Een project zegt wat de build had moeten zijn; de ondertekende .ipa is wat hij werd.
Release build settingsPush notification environment (Engels)
Kan een reviewer de app überhaupt in?
Alles achter een login heeft een demo-account nodig in de App Review-informatie dat nog werkt op het moment dat de reviewer het probeert, en dat is niet het moment waarop je het invulde. Tweestapsverificatie op dat account maakt het onbruikbaar: een reviewer kan je sms niet ontvangen. Al het andere dat tussen de reviewer en de hoofdfunctie staat, zoals een uitnodigingscode, een regiobeperking of een backend-omgeving, hoort in de notities ernaast.
Reviewer access to gated content (Engels)
Is je backend bereikbaar terwijl de app wordt beoordeeld?
Een localhost-adres, een LAN-IP of een staging-host die in de broncode is blijven staan, is een scherm waar een reviewer op een kantoornetwerk niet langs komt. Of je productie-backend echt draait als App Review de app opent, is de helft die geen scanner kan zien, en die controleer je het best op de dag dat je indient in plaats van de dag dat je bouwde.
Development endpoints (Engels)
Laden je privacybeleid- en support-URL voor een onbekende?
Een URL voor het privacybeleid is verplicht voor elke app, ook voor apps die niets verzamelen. Hij moet openbaar bereikbaar zijn: niet achter een login, niet op een staging-domein, en niet op een pad dat bij de laatste redesign is verhuisd. Een support-URL staat niet als verplicht vermeld, maar App Review wijst toch af op een dode link. Open ze allebei in een privévenster zonder sessie.
Support and privacy policy URLs (Engels)
Kloppen je App Privacy-antwoorden met wat de app echt doet?
De verklaring op de productpagina, het privacy manifest in de build en de code moeten met elkaar overeenkomen. Een manifest zonder een verplichte Required Reason API, een trackingverklaring die niet klopt met NSPrivacyTracking, of een SDK van derden zonder eigen manifest zijn de drie die steeds terugkomen. Apple biedt geen manier om de App Privacy-antwoorden op te vragen, dus deze regel rust altijd op wat jij zegt, niet op iets wat kan worden uitgelezen.
App Privacy declarationPrivacy manifestRequired Reason API declarationsCollected data declarations (Engels)
Is de vragenlijst voor de leeftijdsclassificatie af, en past die bij de app?
De vragenlijst bepaalt de classificatie, en functies die al in je project zitten, kunnen een hogere minimumleeftijd afdwingen dan je zelf had gekozen. Hij wordt ingevuld in App Store Connect en niet in het project, dus hij blijft makkelijk op de standaardwaarden staan, of wordt ingevuld op een manier die de app tegenspreekt.
Age rating questionnaire (Engels)
Is er een screenshot voor elk formaat dat deze versie nodig heeft?
De verplichte formaten volgen uit de apparaatfamilies waarvoor je target uitkomt, dus iPad-ondersteuning toevoegen betekent een extra set uploads die niemand zich herinnert. Welke formaten echt een upload hebben voor deze versie, staat in App Store Connect en niet in het project.
Required screenshots (Engels)
Als je iets verkoopt, wordt elke aankoop met de app ingediend?
Elke in-app aankoop wordt los van de app beoordeeld en heeft een eigen naam, beschrijving en App Review-screenshot nodig. Een product dat wel in StoreKit bestaat maar nooit is ingediend, betekent een app waarvan een reviewer de betaalmuur niet kan afronden, en een abonnement brengt eigen verplichtingen mee op het scherm dat het verkoopt: prijs, periode, en een link naar je voorwaarden en privacybeleid.
App Store Connect productsIn-app purchase metadataSubscription disclosure (Engels)
Als de app accounts heeft, kunnen mensen hun account dan in de app verwijderen?
Guideline 5.1.1(v) wil dat het account op je server wordt verwijderd, gestart vanuit de app zelf, en niet via een supportmail of uitloggen. Een app waarin je een account kunt aanmaken maar niet kunt verwijderen, wordt afgewezen op een regel zonder uitzonderingen voor kleine teams.
Als gebruikers elkaar kunnen bereiken, zijn de vier waarborgen dan aanwezig?
Guideline 1.2 vraagt om vier dingen als iets wat de ene gebruiker schrijft bij een andere terechtkomt: filteren van aanstootgevende inhoud, een manier om het te melden, een manier om een gebruiker te blokkeren, en gepubliceerde contactgegevens. Als er één ontbreekt, is dat een routine-afwijzing, en de vier worden meestal op verschillende momenten door verschillende mensen gebouwd.
User-generated content safeguards (Engels)
Staat in de reviewnotities wat een reviewer niet zelf kan achterhalen?
Een reviewer heeft een iPhone en verder niets. Als de app hardware, een gekoppeld apparaat, een account bij een aanbieder of een bepaalde locatie nodig heeft om iets nuttigs te doen, moeten de notities uitleggen hoe je hem zonder dat alles kunt beoordelen. Dit is de afwijzing die je oplost met een alinea in plaats van met code, en de afwijzing die de meeste reviewrondes kost als je het niet doet.
Hardware and setup requirements (Engels)
Wat blijft er over dat een checker niet voor je moet beslissen?
Een deel hangt af van wat je beleid zegt of waar je recht op hebt: of aan de openbaarmakingsplichten van een meegeleverde SDK is voldaan, of je eigen teksten iets beweren wat de app niet doet, of een licentie toestaat wat je hebt uitgebracht. Een scanner kan hierop wijzen en hoort ze niet te beslissen.
Wat geen scan van een project kan beantwoorden
Een scanner leest projectbestanden. Hij kan je screenshots niet zien, niet hoe je app zich gedraagt terwijl hij draait, niet wat je server antwoordt en niet de uiteindelijk ondertekende entitlements, en dat zijn allemaal dingen die App Review beoordeelt. Of je beschrijving klopt met wat de app doet, en of de app een plek in de store verdient, zijn oordelen die een mens maakt.
De helft van de checklist hierboven staat in App Store Connect en niet in je project, en een scan van een project kan daar niet bij. Die regels zijn vragen die jij beantwoordt, en jouw antwoord is wat het rapport vastlegt.
Dus de eerlijke versie van de belofte is die op elke pagina hier: dit verkleint het risico bij het indienen, en niets kan goedkeuring garanderen. Wat het wegneemt, is het soort afwijzing dat een reviewronde kost om een waarde in een bestand die je zelf had kunnen lezen.
Zelf controleren, of laten controleren
Elke regel hierboven kun je met de hand controleren, en de handleidingen leggen uit hoe. Met de hand kost dat een uur of twee per inzending en gaat het makkelijk half: de Release-kolom van een build setting, het entitlements-bestand waarmee de Release-configuratie echt ondertekent, en een Required Reason API die door een dependency wordt gebruikt in plaats van door je eigen code, zijn de drie die worden gemist.
ReviewAhead leest het project en controleert 38 van deze eisen (Engels) in één keer, en toont dan deze checklist met elke regel gemarkeerd als klaar, niet klaar of onbekend. Er wordt niets naar Apple gestuurd, en de uitgepakte broncode wordt verwijderd (Engels) zodra de scan klaar is.
De juridische documenten zijn alleen in het Engels beschikbaar: