In diesem Artikel
- Acht Gründe, warum die App-Store-Prüfung Ihre App zurückschickt
- 1 — Es gibt kein Demo-Konto, mit dem der Prüfer Ihre App öffnen kann
- 2 — Der Store sieht Ihre App als neu verpackte Website
- 3 — Die Datenschutzerklärung ist unvollständig oder fehlt in der App
- 4 — In der App gibt es keine Kontolöschung
- 5 — Die Datensicherheitsangaben bei Google Play stimmen nicht mit dem überein, was die App tut
- 6 — Das Update wird abgelehnt, weil die App auf eine alte Android-Version ausgerichtet ist
- 7 — Neue Konten brauchen 12 Tester und 14 Tage vor der Veröffentlichung
- 8 — Store-Metadaten, Screenshots und eine eigene App pro Filiale
- Wie dieses Tor in den Projektplan passt
- Quellen
Acht Gründe, warum die App-Store-Prüfung Ihre App zurückschickt
Die kurze Antwort: Die meisten App-Ablehnungen im App Store und bei Google Play gehen nicht auf einen Programmierfehler zurück. Sie gehen auf administrative Punkte zurück, die der Geschäftsinhaber kontrolliert, nicht der Entwickler – ein Demo-Konto, mit dem sich der Prüfer anmelden kann, eine vollständige Datenschutzerklärung, eine Datenangabe, die der Realität entspricht, ein Entwicklerkonto auf den Namen des Unternehmens und eine technische Frist, die bereits abgelaufen ist. All das lässt sich zwei Wochen vor dem Launch vorbereiten, ohne eine einzige Zeile Code zu schreiben.
Die Auswirkung auf den Zeitplan ist größer, als es scheint. Eine Ablehnung bedeutet nicht, dass die App schlecht ist; sie bedeutet, dass die App nach jeder Korrektur wieder ans Ende der Warteschlange rückt, sodass eine Launch-Kampagne, die an eine Saison oder ein Ereignis gebunden ist, zu einer Verzögerung ohne absehbares Ende wird. Deshalb verdienen die Veröffentlichungsunterlagen, als Teil des Projekts behandelt zu werden, nicht als Papierkram für den letzten Tag.
1 — Es gibt kein Demo-Konto, mit dem der Prüfer Ihre App öffnen kann
Das ist der häufigste Grund bei Apps, die mit einem Anmeldebildschirm beginnen. Der Prüfer ist keiner Ihrer Kunden und hat keine in Ihrem System registrierte Telefonnummer, also bleibt er ohne vorbereitete Zugangsdaten am ersten Bildschirm hängen. Apples Regel zur Vollständigkeit der App (App Completeness, 2.1) ist eindeutig: Reichen Sie eine finale Version ein, fügen Sie die Daten eines Demo-Kontos bei, wenn Ihre App eine Anmeldung hat, und lassen Sie Ihren Backend-Dienst eingeschaltet. Wenn rechtliche oder sicherheitsbezogene Pflichten verhindern, dass Sie ein echtes Konto bereitstellen, dürfen Sie mit vorheriger Genehmigung von Apple einen eingebauten Demo-Modus einbinden, der den vollen Funktionsumfang der App zeigt.
In der Praxis: Legen Sie ein dauerhaftes Konto an, das nicht abläuft und bei Datenbereinigungen nicht gelöscht wird, und sorgen Sie dafür, dass die Staging-Server während des gesamten Prüfungszeitraums laufen, nicht nur zu Ihren Bürozeiten.
2 — Der Store sieht Ihre App als neu verpackte Website
Die Regel zur Mindestfunktionalität (Minimum Functionality, 4.2) besagt, dass eine App Funktionen, Inhalte und eine Oberfläche bieten muss, die sie über eine neu verpackte Website hinausheben, und dass Apps, die in erster Linie Marketingmaterial, Web-Ausschnitte, Inhaltsaggregatoren oder eine Sammlung von Links sind, nicht akzeptiert werden. Viele Unternehmen wollen eine App, weil ein Wettbewerber eine hat, und das Produkt erscheint als Kopie der Website in einer Hülle.
Es gibt zwei Auswege: Entweder Sie geben der App echten Mehrwert, den der Browser nicht liefern kann – Offline-Nutzung, Benachrichtigungen je nach Bestellstatus, Barcode-Scan, auf dem Gerät gespeicherte Daten, Integration von Zahlungen und Karten –, oder Sie veröffentlichen eine Progressive Web App, statt über die Stores zu gehen. Diese Abwägung haben wir in Progressive Web App oder native App behandelt.
3 — Die Datenschutzerklärung ist unvollständig oder fehlt in der App
Apples Regel zur Datenerhebung (Data Collection, 5.1.1) verlangt einen Link zur Datenschutzerklärung in den Metadaten von App Store Connect und in der App selbst an einer leicht zugänglichen Stelle. Die Erklärung muss angeben, welche Daten erhoben werden, wie und zu welchen Zwecken sie jeweils genutzt werden; bestätigen, dass jeder Dritte, mit dem Sie Daten teilen – Analysetools, Werbenetzwerke, SDKs von Drittanbietern –, denselben Schutz bietet; und die Richtlinien zu Aufbewahrung und Löschung erläutern sowie erklären, wie ein Nutzer seine Einwilligung widerruft.
Das ist keine Seite, die man von einer anderen Website kopiert. Sie beschreibt, was Ihr System tatsächlich tut, und muss zu Ihren Pflichten nach dem saudischen Gesetz zum Schutz personenbezogener Daten (PDPL) passen, wie wir in unserem praktischen PDPL-Leitfaden erklären.
4 — In der App gibt es keine Kontolöschung
Regel 5.1.1 (v) ist klar: Wenn Ihre App das Anlegen eines Kontos unterstützt, müssen Sie auch die Löschung des Kontos innerhalb der App anbieten. Sie ergänzt eine Regel, die viele Teams übersehen: Wenn Ihre App keine wesentlichen kontobasierten Funktionen bietet, lassen Sie die Leute sie ohne Anmeldung nutzen, und verlangen Sie keine personenbezogenen Daten, sofern sie nicht direkt für die Kernfunktion relevant oder gesetzlich vorgeschrieben sind.
Kontolöschung ist hier nicht nur ein Knopf in der Oberfläche; es ist ein vollständiger Ablauf im Backend. Was passiert mit den Bestellungen, Rechnungen und Buchhaltungsunterlagen des Kunden, die gesetzlich nicht gelöscht werden dürfen? Die übliche Antwort lautet, Identitätsdaten von Finanzunterlagen zu trennen, bevor die Entwicklung beginnt, nicht danach.
5 — Die Datensicherheitsangaben bei Google Play stimmen nicht mit dem überein, was die App tut
Google verlangt von jedem Entwickler, die Daten anzugeben, die die App erhebt und vom Gerät überträgt, einschließlich der Daten, die von Bibliotheken und SDKs von Drittanbietern erhoben werden, ob die Erhebung erforderlich oder optional ist, den Zweck, ob die Daten bei der Übertragung verschlüsselt werden und ob es einen Mechanismus für Löschanfragen gibt. Die Richtlinie stellt fest, dass allein der Entwickler für korrekte Angaben verantwortlich ist und dass Verstöße zu gesperrten Updates oder zur Entfernung aus Google Play führen.
Der übliche Fehler ist simpel: Ein Entwickler hat ein Analyse- oder Absturzberichts-Tool eingebaut, um sich die eigene Arbeit zu erleichtern, und niemand hat es in die Angaben aufgenommen. Stellen Sie Ihrem Team vor der Einreichung eine einzige Frage: Wie lautet die vollständige Liste der Drittanbieter-Pakete in dieser App, und was sendet jedes davon?
6 — Das Update wird abgelehnt, weil die App auf eine alte Android-Version ausgerichtet ist
Seit dem 31. August 2026 verlangt Google Play, dass neue Apps und App-Updates auf Android 16 (API-Level 36) oder höher ausgerichtet sind, mit Ausnahmen: Wear OS und Android Automotive auf Level 35 sowie Android TV und Android XR auf Level 34. Entwickler, die eine Verlängerung beantragt haben, haben Zeit bis zum 1. November 2026.
Die betriebliche Folge für einen Geschäftsinhaber: Ihre veröffentlichte App bleibt im Store, aber Sie können überhaupt kein Update ausliefern – nicht einmal einen dringenden Sicherheitsfix oder eine Preisänderung –, bis sie gegen das geforderte Level neu gebaut wurde. Jede App, die ein Jahr lang nicht aktualisiert wurde, verdient eine Prüfung dieses Punkts, bevor Sie dringend ein Release brauchen.
7 — Neue Konten brauchen 12 Tester und 14 Tage vor der Veröffentlichung
Private Entwicklerkonten, die nach dem 13. November 2023 bei Google Play erstellt wurden, können nicht sofort öffentlich veröffentlichen. Sie brauchen einen geschlossenen Test mit mindestens 12 Testern, die mindestens 14 Tage lang ununterbrochen teilnehmen, bevor sie Zugang zur Produktion beantragen können. Das sind zwei zusätzliche Wochen im Zeitplan und 12 echte Menschen mit echten Google-Konten.
Auf der anderen Seite erfordert die Anmeldung beim Apple Developer Program als Organisation eine D-U-N-S-Nummer und eine juristische Person, die Verträge abschließen kann, unter dem rechtlichen Namen der Organisation – nicht unter einem Handelsnamen und nicht als Filiale. Die Nummer zu beschaffen und die Verifizierung zu durchlaufen dauert Tage. Beginnen Sie damit in der ersten Projektwoche, nicht in der Launch-Woche.
8 — Store-Metadaten, Screenshots und eine eigene App pro Filiale
Drei kleine Regeln bringen ganze Releases zum Scheitern: Screenshots müssen die App im Einsatz zeigen, nicht das Titelbild, die Anmeldeseite oder den Startbildschirm (2.3.3); der App-Name ist auf 30 Zeichen begrenzt, und die Metadaten dürfen nicht mit Markenbegriffen, Namen beliebter Apps oder Preisen vollgestopft werden (2.3.7); und Sie dürfen nicht mehrere Bundle IDs derselben App anlegen (4.3a) – genau das passiert, wenn ein Unternehmen eine eigene App pro Filiale oder pro Stadt verlangt. Das richtige Muster ist eine einzige App, in der der Nutzer die Filiale auswählt.
Wie dieses Tor in den Projektplan passt
- Registrieren Sie das Entwicklerkonto auf den Namen Ihres Unternehmens, nicht auf den des Entwicklers oder der Agentur. Es ist ein Vermögenswert des Unternehmens wie die Domain, wie wir in wem die Rechte an Ihrer Software gehören erläutert haben.
- Eröffnen Sie die Konten in der ersten Woche: Apple verlangt 99 $ pro Jahr und Google Play einmalig 25 $, und Zeit kostet die Verifizierung, nicht die Zahlung.
- Nehmen Sie eine Klausel in den Vertrag auf, die festlegt, wer den Build einreicht und auf Prüfungsanmerkungen antwortet, und wie viele Prüfungszyklen im Preis enthalten sind.
- Behandeln Sie die Veröffentlichungsunterlagen als eigenes Lieferobjekt: Datenschutzerklärung, Datenangaben, Screenshots, Beschreibung, Demo-Konto und die Liste der Drittanbieter-Pakete.
Der Code ist eine Woche vor dem Launch fertig. Die Veröffentlichungsunterlagen brauchen zwei Wochen. Wer diese Reihenfolge falsch angeht, verursacht die meisten verspäteten Launches.
Quellen
Häufige Fragen
Wie lange dauert die Freigabe in beiden Stores normalerweise?
Die Prüfung selbst dauert pro Einreichung meist ein bis drei Tage, die tatsächliche Dauer hängt aber davon ab, wie oft Sie abgelehnt werden. Planen Sie zwei Wochen für die Veröffentlichungsunterlagen vor der Einreichung ein, eine Reservewoche für mindestens einen Zyklus aus Ablehnung und Korrektur und zwei zusätzliche Wochen, wenn das Google-Play-Konto neu ist und noch seinen geschlossenen Test braucht.
Unsere App ist seit zwei Jahren ohne Update veröffentlicht. Ist bei uns alles in Ordnung?
Die App bleibt zum Download verfügbar, aber Google Play akzeptiert kein neues Update, solange es nicht auf Android 16 (API-Level 36) ausgerichtet ist – eine Anforderung, die seit dem 31. August 2026 gilt. Das Problem taucht plötzlich an dem Tag auf, an dem Sie einen Sicherheitsfix oder eine Preisänderung brauchen und feststellen, dass ein kleines Update einen kompletten Neubau erfordert. Prüfen Sie das jetzt, nicht mitten in einem Notfall.
Brauchen wir für jede unserer Filialen eine eigene App?
Nein, und Apples Regel gegen Duplikate verbietet das ausdrücklich: Sie dürfen nicht mehrere Bundle IDs derselben App mit einer eigenen Version für jede Stadt oder jeden Standort anlegen. Der richtige Weg ist eine einzige App, in der der Nutzer die Filiale auswählt – das ist zudem günstiger in Entwicklung und Pflege und besser für Ihre Sichtbarkeit in der Store-Suche.
Das Entwicklerkonto läuft auf den Namen der Agentur, die die App gebaut hat. Was ist das Risiko?
Das Risiko besteht darin, dass die App, ihre Rezensionen, ihre Bewertungen und ihre Download-Historie Vermögenswerte sind, die an ein Konto gebunden sind, das Ihnen nicht gehört, und ein späterer Umzug erfordert die Zustimmung der Gegenseite und ein Übertragungsverfahren. Registrieren Sie das Konto von Anfang an auf Ihre juristische Person und geben Sie der Agentur einen begrenzten Zugang, den Sie bei Vertragsende widerrufen können.
Folgen Sie Origami bei Google
Legen Sie Origami als bevorzugte Quelle fest, dann erscheinen unsere Artikel bei Ihnen zuerst in der Google-Suche und in den Top-Meldungen.








