Guideline 4.3 ist Apples Spam-Regel. Sie greift üblicherweise, wenn eine App ein bestehendes Produkt zu duplizieren scheint, ein Template wiederholt oder einer ohnehin überfüllten Kategorie ein weiteres nahezu identisches Listing hinzufügt. Ein neues Icon oder ein umgeschriebener Untertitel behebt den Grund der Ablehnung selten.
Wisse, welcher Teil von 4.3 greift
Abschnitt 4.3(a) betrifft mehrere Bundle-IDs für im Wesentlichen dieselbe App, einschließlich Portfolios, die nach Ort, Kunde oder Thema aufgeteilt sind. Abschnitt 4.3(b) betrifft Apps, die von Produkten, die in einer gesättigten Kategorie bereits üblich sind, nicht zu unterscheiden sind. Der erste fragt, ob die Varianten ein Produkt sein sollten. Der zweite, ob das Produkt selbst ein nennenswertes Erlebnis hinzufügt.
Beginne mit der Reviewer-Notiz
Lies die exakte Notiz in App Store Connect und trenne die Belege von der Schlussfolgerung. Schreib auf, was der Reviewer als ähnlich bezeichnet hat: das Produktkonzept, das Binary, das Listing, das Konto-Portfolio oder die Kategorie selbst. Reiche nicht erneut ein, bevor du den Unterschied in einem Satz erklären kannst.
Wenn Screenshots, First-Run-Flow und Kernergebnis mit einer anderen App austauschbar wirken, wird auch der Reviewer vermutlich kein eigenständiges Produkt sehen.
Prüfe das Produkt, nicht nur das Listing
- Kernergebnis: Benenne den Job, den deine App erledigt und die verglichenen Apps nicht.
- Erlebnis: Zeig, wo Workflow, Zielgruppe, Inhalte oder Daten sich wesentlich unterscheiden.
- Eigentum: Sammle Lizenzen und Berechtigungen für Markeninhalte, Templates oder Assets Dritter.
- Portfolio: Erkläre, warum das eine eigene App sein muss statt eines Modus in einer bestehenden.
Bereite eine saubere Review-Notiz vor
Bleib sachlich. Benenne den differenzierenden Workflow, führe den Reviewer dorthin und leg alle Zugangsdaten bei, die nötig sind, um ihn zu erreichen. Wenn der vorherige Build Verwirrung gestiftet hat, sag klar, was sich im neuen Build geändert hat. Argumentiere nicht damit, dass Wettbewerber freigegeben wurden — geprüft wird die eingereichte App.
What is distinct:
[one clear product difference]
Where to find it:
[screen and exact steps]
What changed in this build:
[material product changes]
Supporting rights or context:
[licenses, ownership, account relationship]Änderungen, die 4.3 üblicherweise nicht lösen
Ein neues Icon, eine neue Farbpalette, ein neuer App-Name oder eine andere Screenshot-Reihenfolge lassen das Listing anders aussehen, während das Produkt unverändert bleibt. Einen Template-Verweis zu entfernen entfernt weder geteilten Code noch einen austauschbaren Workflow. Wenn der Reviewer den eigenständigen Mehrwert mit dem bereitgestellten Konto und den Schritten nicht erreicht, gilt er als nicht belegt.
Erneut einreichen oder Einspruch?
Reiche erneut ein, wenn du das Produkt geändert hast oder einen Unterschied jetzt zeigen kannst, den der Reviewer nicht erreichen konnte. Lege Einspruch ein, wenn die Einreichung bereits konform ist und die Ablehnung auf einem sachlichen Missverständnis zu beruhen scheint. Schick in beiden Fällen einen zusammenhängenden Vorgang statt mehrerer fragmentierter Nachrichten.
Bevor du auf Submit drückst
- Der geprüfte Build enthält die versprochenen Änderungen.
- Screenshots und Metadaten beschreiben das aktuelle Produkt.
- Der differenzierende Workflow ist mit dem bereitgestellten Review-Konto erreichbar.
- Deine Notiz ist konkret, kurz und frei von Vergleichen, die du nicht belegen kannst.
War dieser Artikel hilfreich?