App-Store-Ablehnung nach Guideline 4.3: Was dahintersteckt und was hilft

Eine Ablehnung nach Guideline 4.3 ist für viele Teams die frustrierendste Nachricht aus dem App Review: Die App funktioniert, sie stürzt nicht ab und wird trotzdem abgelehnt, weil Apple sie als „Spam“ einstuft. Die Ursachen lassen sich meist klar eingrenzen.

Was Guideline 4.3 regelt

Die App Review Guidelines fassen unter 4.3 („Spam“) zwei Fälle zusammen:

• 4.3(a): mehrere Bundle-IDs für dieselbe App. Varianten, etwa für einzelne Standorte, Vereine oder Kunden, sollen in einer App gebündelt werden.
• 4.3(b): Apps in Kategorien, die bereits gesättigt sind, ohne eigenständigen, hochwertigen Mehrwert.

In der Praxis kommt vor allem 4.3(a) vor. Die Begründung lautet dann sinngemäß, die App teile Binärcode, Metadaten oder Konzept mit Apps anderer Entwickler und unterscheide sich nur geringfügig.

Typische Ursachen

• Code aus Vorlagen und Baukästen. Apps aus derselben Vorlage ähneln sich im Binärcode stark. Besonders auffällig wird das, wenn Beispieltexte, ungenutzte Screens oder Standard-Assets übrig geblieben sind.
• White-Label-Apps. Dieselbe App wird für mehrere Kunden unter mehreren Bundle-IDs eingereicht, oft aus dem Entwicklerkonto einer Agentur.
• Eingereicht vom falschen Konto. Nach Guideline 4.2.6 müssen Apps aus kommerziellen Vorlagen oder App-Generatoren vom Anbieter der Inhalte selbst eingereicht werden, also vom Entwicklerkonto des Kunden, nicht von dem der Agentur.
• Austauschbare Metadaten. Generische Beschreibungen und Screenshots, die zu vielen Apps passen könnten, verstärken den Eindruck.

Verwandt, aber getrennt zu behandeln ist Guideline 4.2 („Minimum Functionality“): Sie trifft Apps, die kaum mehr sind als eine eingebettete Website.

Was hilft

1. Die Begründung genau lesen. Ist es 4.3(a), 4.3(b) oder eigentlich 4.2? Davon hängt ab, was sich ändern muss.
2. Die App unterscheidbar machen. Reste der Vorlage entfernen, ungenutzten Code und Beispielinhalte löschen, die eigenen Funktionen in den Vordergrund stellen.
3. Varianten zusammenführen. Statt vieler fast gleicher Apps eine App, in der Nutzer Standort oder Organisation wählen.
4. Vom richtigen Konto einreichen. Eine Kunden-App gehört in das Apple-Developer-Konto des Kunden.
5. Metadaten überarbeiten. Beschreibung und Screenshots zeigen, was genau diese App kann.
6. Im App Store Connect antworten. Sachlich erklären, was die App eigenständig macht und was sich seit der letzten Einreichung geändert hat. Wer die Entscheidung für falsch hält, kann Einspruch beim App Review Board einlegen.

Was selten hilft: dieselbe Version unverändert erneut einzureichen.

Wenn Ihre App feststeckt

Ich übernehme bestehende Flutter-Codebasen und löse Store-Review-Ablehnungen bei Apple und Google. Für eine erste Einschätzung sehe ich mir die Ablehnung, die Codebasis und die Store-Konten an. Schreiben Sie mir.