App Store metadata-afwijzingen: 2.3.x, 2.3.7, 4.3 en 5.2.1 oplossen
Je krijgt de mail net binnen. Status springt naar Metadata Rejected, en de notitie in het Resolution Center noemt een guideline-nummer waar je op moest zoeken. Het goede nieuws: een metadata-afwijzing is een van de snelst op te lossen soorten — je uploadt geen nieuwe build, je bewerkt het versie-record en dient opnieuw in.
Check eerst het guideline-nummer in het bericht van het Resolution Center, want dat vertelt je precies welk veld je moet aanpassen. Deze post behandelt de vier die je het vaakst tegenkomt bij een listing-afwijzing. Guideline-nummers worden af en toe hernummerd, dus deze weerspiegelen de huidige App Store Review Guidelines.
Eerst de mechaniek: wat "Metadata Rejected" echt betekent
Een Metadata Rejected-status wijst naar je storelisting — appnaam, subtitel, keywords, beschrijving, screenshots, previews, URL's — niet naar de gecompileerde app. Omdat de melding op de metadata slaat, heb je geen nieuwe binary nodig. Je past het genoemde veld aan in App Store Connect, houdt de bestaande build aan de versie gekoppeld, en dient opnieuw in.
Twee kanttekeningen die het waard zijn om helder te stellen. Ten eerste: opnieuw indienen zet je terug in de reviewqueue, dus het is bouwvrij maar niet reviewvrij — een mens of automatische check kijkt er opnieuw naar. Ten tweede: het ene veld dat Apple noemt oplossen maakt de rest van je listing niet immuun. Reviewers kunnen bij de volgende ronde een andere guideline aanmerken. Ruim de hele listing op terwijl je toch bezig bent, niet alleen de zin die naar je hoofd werd geslingerd.
Guideline 2.3.3 — screenshots moeten de app in gebruik tonen
Wat het triggert. Je screenshots laten niet zien wat de app doet. De klassieker is een eerste slot met een splash screen, een loginpagina, of titelbeeld met een tagline zonder daadwerkelijke UI. Het gaat ook af wanneer een screenshot een functie toont die de app niet heeft, of verwijst naar een apparaat of interface van een ander platform.
Voor: slot één is je logo gecentreerd op een gradient met de woorden "de slimste manier om je week te plannen", zonder ergens een app-interface.
Na: slot één is een echt scherm uit een kernflow — een weekweergave met daadwerkelijk ingevulde items — met een kort bijschrift dat het voordeel benoemt boven het device. Reviewers (en gebruikers) zien vanaf de thumbnail wat de app doet. Behoud marketingbijschriften en device frames, maar zorg dat de UI eronder echt en actueel is.
Dit is een metadata-wijziging: wissel de afbeeldingen in het versie-record om, dien opnieuw in, geen nieuwe build nodig.
Guideline 2.3.7 — keywords moeten je app beschrijven, geen zoekwoord-jacht
Wat het triggert. Dit is de guideline over keyword-misbruik. Het gaat af wanneer je metadata is opgevuld met termen die je app niet beschrijven: gedeponeerde termen die niet van jou zijn, namen van grotere of populairdere apps, prijsinformatie in het verkeerde veld, namen van beroemdheden of publieke figuren voor extra bereik, of generieke woorden erin gepropt om zoekopdrachten te vangen. Het keyword-veld van 100 tekens is de gebruikelijke boosdoener, maar subtitel en naam worden ook aangemerkt. Appnamen zijn beperkt tot 30 tekens, en prijs- of promotietaal hoort niet thuis in de naam, subtitel of screenshots.
Voor (keyword-veld): een lijst met daarin de namen van drie grotere apps in jouw categorie, de naam van een bekende maker, en een paar losse trending woorden, die geen van allen een functie beschrijven die je daadwerkelijk hebt.
Na: keywords die aansluiten bij wat een gebruiker daadwerkelijk zou zoeken om jouw functie te vinden — de taken die de app uitvoert, het probleem dat hij oplost, de zelfstandige naamwoorden uit je eigen schermen. Elke term moet naar iets verwijzen dat de app echt doet.
Voor (subtitel): een vergelijkingszin waarin je jezelf positioneert tegenover een met naam genoemde concurrerende app.
Na: een subtitel die in gewone taal beschrijft welk resultaat jouw app oplevert, zonder naam van een ander merk erin. De subtitel is voor context over jouw app, geen plek om andermans verkeer te lenen.
Guideline 4.3 — spam en bijna-identieke apps
Wat het triggert. 4.3 gaat over gelijkenis. Het gaat af wanneer je meerdere bijna-identieke apps uitbrengt onder aparte bundle-ID's (een aparte build per stad, per team, per klant, in plaats van één app met die varianten erin), of wanneer een indiening moeilijk te onderscheiden is van iets wat al breed beschikbaar is. Het is vaak een conceptprobleem, maar de listing maakt de duplicatie zichtbaar — identieke beschrijvingen en screenshots tussen je eigen apps zijn een duidelijk signaal.
Voor: vijf apps in je account met dezelfde layout, dezelfde functielijst, en tekst die alleen verschilt door één stads- of teamnaam om te wisselen.
Na: één app die die varianten als in-app-opties of aankopen draagt, met een listing die beschrijft wat de app werkelijk onderscheidend maakt. Als je écht aparte producten hebt, zorg dan dat elke listing in de screenshots en beschrijving laat zien wat er daadwerkelijk anders is, niet alleen een zoek-en-vervang op een eigennaam.
4.3 kan meer vergen dan een metadata-edit als de onderliggende app echt een dunne reskin is. Maar waar het probleem is dat je listings als elkaars kloon overkomen, is het differentiëren van tekst en screenshots een metadata-fix.
Guideline 5.2.1 — andermans intellectueel eigendom in je metadata
Wat het triggert. Het gebruik van beschermd materiaal van derden waar je geen rechten op hebt — merken, auteursrechtelijk beschermd werk, namen die op iets bestaands lijken — waar dan ook in je bundle, ontwikkelaarsnaam of metadata. Een veelvoorkomende variant is een mismatch tussen de app of het merk in de listing en de entiteit die hem daadwerkelijk indiende, waardoor Apple gaat vragen wie de naam bezit.
Voor: een merk- of platformnaam die niet van jou is, in je apptitel, subtitel of keyword-veld om het bijbehorende zoekverkeer te vangen.
Na: je eigen productnaam in titel, subtitel en keywords. Als je daadwerkelijk integreert met een platform van derden en dat moet vermelden, houd elke feitelijke compatibiliteitsvermelding dan in de beschrijving waar het is toegestaan, en niet in naam en subtitel. Als je de app voor een klant hebt gebouwd die het merk bezit, dien hem dan in vanuit het account van de eigenaar, of laat je toevoegen aan hun team, zodat verkopersnaam en merk overeenkomen.
Het bouwvrije deel, nog eens
Voor alle vier geldt: als de fix in het versie-record zit — tekst en afbeeldingen — corrigeer je die in App Store Connect en dien je dezelfde binary opnieuw in. Je hoeft geen buildnummer op te hogen of te wachten op verwerking. Dat is de snelle route die een metadata-afwijzing je oplevert. De prijs is dat je opnieuw door de review gaat, dus het loont om de hele listing tegen deze vier langs te lopen voordat je opnieuw indient, in plaats van ze één voor één op te lossen na elke afwijzing.
Waar Mokbi helpt (en waar niet)
De meeste 2.3.7-problemen ontstaan al bij het schrijven, wanneer een keyword-veld of subtitel wordt opgevuld om bereik te jagen. De AI van Mokbi stelt je listingtekst op — naam, subtitel, keywords, beschrijving — vanuit wat je app daadwerkelijk doet, wat je wegstuurt van de opvul- en geleende-merk-gewoontes die überhaupt tot een keyword-afwijzing leiden. Daarna lokaliseert het die tekst naar 50 talen, zodat je niet per markt handmatig een nieuw keyword-veld schrijft en telkens dezelfde valkuil opnieuw introduceert.
Wees nuchter over de grens. Dit verlaagt je kans op een 2.3.x- of 5.2.1-melding op de tekst; het kan geen goedkeuring garanderen, en het beslist niet wat er in je build zit. Review is aan Apple. Wat compliant, app-accurate tekst wél doet, is de makkelijke, zelf veroorzaakte redenen om te worden afgewezen wegnemen. Mokbi publiceert niet automatisch naar je listing — het levert de tekst en de screenshots; jij beoordeelt ze en dient in.