App Store Metadaten-Ablehnungen: Fixes für 2.3.x, 2.3.7, 4.3 und 5.2.1
Du hast gerade die E-Mail bekommen. Der Status ist auf Metadata Rejected gesprungen, und die Notiz im Resolution Center nennt eine Guideline-Nummer, die du erst nachschlagen musstest. Die gute Nachricht: Eine Metadaten-Ablehnung gehört zu den schneller behobenen Fällen. Du lädst keinen neuen Build hoch, sondern bearbeitest den Versionseintrag und reichst neu ein.
Das Wichtigste zuerst: die Guideline-Nummer in der Nachricht des Resolution Centers prüfen, denn die sagt dir genau, welches Feld du korrigieren musst. Dieser Beitrag behandelt die vier, die dir bei einer Listing-Ablehnung am häufigsten begegnen. Guideline-Nummern werden im Lauf der Zeit neu vergeben, die hier genannten entsprechen den aktuellen App Store Review Guidelines.
Zuerst die Mechanik: was „Metadata Rejected" wirklich bedeutet
Ein Status Metadata Rejected verweist auf dein Store-Listing — App-Name, Untertitel, Keywords, Beschreibung, Screenshots, Previews, URLs — nicht auf die kompilierte App. Weil das Flag auf den Metadaten liegt, brauchst du keinen neuen Build. Du bearbeitest das genannte Feld in App Store Connect, behältst den bestehenden Build an der Version und reichst erneut ein.
Zwei Vorbehalte, die man klar benennen sollte. Erstens: Ein erneutes Einreichen bringt dich trotzdem zurück in die Review-Warteschlange — build-frei, aber nicht review-frei, ein Mensch oder ein automatisierter Durchlauf sieht sich das erneut an. Zweitens: Das eine von Apple genannte Feld zu korrigieren immunisiert nicht den Rest deines Listings. Reviewer können beim nächsten Durchlauf eine andere Guideline beanstanden. Räum das ganze Listing auf, solange du schon dabei bist — nicht nur den zitierten Satz.
Guideline 2.3.3 — Screenshots müssen die App im Einsatz zeigen
Was es auslöst. Deine Screenshots zeigen die App nicht bei der Arbeit. Der klassische Fall: Der erste Slot ist ein Splash-Screen, eine Login-Seite oder Titel-Artwork mit Tagline ohne echte UI. Es greift auch, wenn ein Screenshot ein Feature zeigt, das die App nicht hat, oder ein Gerät bzw. Interface einer anderen Plattform referenziert.
Vorher: Slot eins zeigt dein Logo zentriert auf einem Farbverlauf mit dem Satz „der smarteste Weg, deine Woche zu planen" — nirgendwo ein App-Interface.
Nachher: Slot eins ist ein echter Screen aus einem Kernablauf — eine Wochenansicht mit tatsächlich eingetragenen Terminen — mit einem kurzen Untertitel, der den Nutzen über dem Gerät benennt. Reviewer (und Nutzer) sehen schon am Thumbnail, was die App tut. Marketing-Untertitel und Geräterahmen bleiben, aber die UI darunter muss echt und aktuell sein.
Das ist eine reine Metadaten-Änderung: Bilder im Versionseintrag austauschen, neu einreichen, kein neuer Build.
Guideline 2.3.7 — Keywords müssen deine App beschreiben, nicht die Spielesuche bedienen
Was es auslöst. Das ist die Keyword-Missbrauchs-Guideline. Sie greift, wenn deine Metadaten mit Begriffen aufgefüllt sind, die deine App nicht beschreiben: geschützte Markenbegriffe, die dir nicht gehören, Namen größerer oder populärerer Apps, Preisformulierungen im falschen Feld, Prominenten- oder Persönlichkeitsnamen für Reichweite, oder generische Phrasen zum Abgreifen von Suchen. Meist trifft es das 100-Zeichen-Keyword-Feld, aber auch Untertitel und Name werden beanstandet. App-Namen sind auf 30 Zeichen begrenzt, und Preis- oder Werbesprache gehört weder in Name, Untertitel noch Screenshots.
Vorher (Keyword-Feld): eine Liste mit den Namen von drei größeren Apps deiner Kategorie, dem Namen eines bekannten Creators und ein paar unpassenden Trend-Wörtern — nichts davon beschreibt ein von dir gebautes Feature.
Nachher: Keywords, die dem entsprechen, wonach ein Nutzer tatsächlich sucht, um deine Funktion zu finden — die Aufgaben, die sie erledigt, das Problem, das sie löst, die Begriffe aus deinen eigenen Screens. Jeder Begriff sollte auf etwas verweisen, das die App wirklich tut.
Vorher (Untertitel): eine Vergleichszeile, die dich gegen eine namentlich genannte Konkurrenz-App positioniert.
Nachher: ein Untertitel, der in klaren Worten das Ergebnis nennt, das deine App liefert — kein fremder Markenname darin. Der Untertitel dient dem Kontext deiner App, nicht dem Abgreifen fremder Reichweite.
Guideline 4.3 — Spam und nahezu identische Apps
Was es auslöst. Bei 4.3 geht es um Gleichförmigkeit. Sie greift, wenn du mehrere nahezu identische Apps unter separaten Bundle-IDs veröffentlichst (ein eigener Build pro Stadt, pro Team, pro Kunde, statt einer App mit diesen Varianten intern), oder wenn eine Einreichung kaum von etwas bereits weit Verbreitetem zu unterscheiden ist. Oft ist es ein Konzeptproblem, aber das Listing macht die Duplizierung sichtbar — identische Beschreibungen und Screenshots über deine eigenen Apps hinweg sind ein starkes Indiz.
Vorher: fünf Apps in deinem Account mit demselben Layout, derselben Feature-Liste und Text, der sich nur durch den Austausch eines Stadt- oder Teamnamens unterscheidet.
Nachher: eine App, die diese Varianten als In-App-Optionen oder Käufe abbildet, mit einem Listing, das das tatsächlich Eigenständige beschreibt. Falls du wirklich separate Produkte hast, sorg dafür, dass jedes Listing in Screenshots und Beschreibung zeigt, was tatsächlich anders ist — nicht nur einen ausgetauschten Eigennamen.
4.3 kann mehr als eine Metadaten-Korrektur erfordern, wenn die App wirklich nur ein dünnes Reskin ist. Aber wo das Problem ist, dass deine Listings wie Klone voneinander wirken, ist die Differenzierung von Text und Screenshots ein Metadaten-Fix.
Guideline 5.2.1 — fremdes geistiges Eigentum in deinen Metadaten
Was es auslöst. Geschütztes Fremdmaterial ohne Rechte zu verwenden — Marken, urheberrechtlich geschützte Werke, Trittbrettfahrer-Namen — an beliebiger Stelle in Bundle, Entwicklername oder Metadaten. Eine häufige Variante ist eine Diskrepanz zwischen der App bzw. Marke im Listing und der Instanz, die tatsächlich eingereicht hat, was Apple fragen lässt, wem der Name gehört.
Vorher: ein Marken- oder Plattformname, der dir nicht gehört, in App-Titel, Untertitel oder Keyword-Feld, um dessen Suchverkehr abzugreifen.
Nachher: dein eigener Produktname in Titel, Untertitel und Keywords. Wenn du wirklich mit einer Drittanbieter-Plattform integrierst und das erwähnen musst, halte jede faktische Kompatibilitätsangabe in der Beschreibung — dort, wo sie zulässig ist — und nicht in Name oder Untertitel. Wenn du die App für einen Kunden gebaut hast, dem die Marke gehört, reiche sie über den Account dieser Instanz ein oder lass dich zu deren Team hinzufügen, damit Verkäufername und Marke übereinstimmen.
Der build-freie Teil, noch einmal
Bei allen vier Guidelines gilt: Liegt der Fix im Versionseintrag — Text und Bilder —, korrigierst du ihn in App Store Connect und reichst denselben Build erneut ein. Du erhöhst keine Build-Nummer und wartest nicht auf Verarbeitung. Das ist die Überholspur, die dir eine Metadaten-Ablehnung verschafft. Der Preis dafür: Du durchläufst die Review erneut — es lohnt sich also, das ganze Listing gegen diese vier Punkte zu prüfen, bevor du erneut einreichst, statt sie einzeln nacheinander abzuarbeiten.
Wo Mokbi hilft (und wo nicht)
Die meisten 2.3.7-Probleme entstehen schon beim Schreiben, wenn ein Keyword-Feld oder Untertitel für mehr Reichweite aufgebläht wird. Die KI von Mokbi entwirft deinen Listing-Text — Name, Untertitel, Keywords, Beschreibung — aus dem, was deine App tatsächlich tut, und lenkt dich so weg von den Auffüll- und Trittbrettfahrer-Gewohnheiten, die eine Keyword-Ablehnung erst auslösen. Anschließend lokalisiert sie diesen Text in 50 Sprachen, sodass du nicht pro Markt ein neues Keyword-Feld von Hand schreibst und dieselbe Falle jedes Mal neu aufstellst.
Sei dir der Grenze bewusst. Das senkt deine Chancen auf ein 2.3.x- oder 5.2.1-Flag beim Wortlaut, kann aber keine Freigabe versprechen und entscheidet nicht über den Inhalt deines Builds. Die Review liegt bei Apple. Konformer, appgerechter Text nimmt dir die einfachen, selbstverschuldeten Gründe für eine Ablehnung. Mokbi veröffentlicht nichts automatisch in deinem Listing — es erstellt Text und Screenshots, du prüfst sie und reichst sie ein.