App Store Richtlinie 5.1.1: Ablehnung wegen Datenerhebung und Zweckangaben beheben

Zunächst gilt: kein Grund zur Panik. Diese Ablehnung verlangt selten einen Neubau der App. Meist betrifft das Problem einige Texte, einen Registrierungsbildschirm oder eine SDK Einstellung. Deshalb bringt eine ruhige Reihenfolge mehr als ein hastig hochgeladener Build. Gehen Sie so vor:

1. Lesen Sie die vollständige Nachricht in App Store Connect und notieren Sie den genannten Unterpunkt.
2. Stellen Sie den genannten Bildschirm, die Berechtigung oder das Datenfeld auf Ihrem eigenen Gerät nach.
3. Klären Sie, ob das Problem im Text, im Ablauf oder in einem SDK eines Drittanbieters liegt.
4. Beheben Sie den Fehler und testen Sie den neuen Build auf einem echten Gerät mit frischer Installation.
5. Antworten Sie kurz und stichpunktartig auf die Nachricht und reichen Sie dann den neuen Build ein.

Dieser Beitrag behandelt nur Richtlinie 5.1.1. Einen breiteren Überblick finden Sie in unserem Artikel über die häufigsten Gründe für eine App Ablehnung.

Wie lesen Sie den Verweis auf 5.1.1 in der Ablehnungsnachricht?

Apple nennt bei jeder Ablehnung die betroffene Regel mit ihrer Nummer. Abschnitt 5.1 behandelt den Datenschutz, 5.1.1 konkret die Datenerhebung und Speicherung. Allerdings ist 5.1.1 keine einzelne Regel, sondern eine Überschrift mit zehn ausführlichen Unterpunkten. Wer also ohne den Rest der Nachricht zu lesen loslegt, ändert womöglich den falschen Bildschirm.

Die Nachricht enthält meist drei Hinweise. Erstens beschreibt sie den betroffenen Bildschirm oder die Funktion. Zweitens nennt sie das Verhalten, das Apple erwartet. Drittens liegt manchmal ein Screenshot bei. Zum Beispiel hängt das Review Team einen Screenshot des Kameradialogs an und vermerkt, dass der Text den Zweck nicht erklärt. In diesem Fall liegt das Problem fast immer in der Zweckangabe in der Datei Info.plist.

Spricht die Nachricht dagegen von persönlichen Daten, die Ihre App gar nicht braucht, steckt das Problem in einem Formularfeld oder im Registrierungsablauf. Der genaue Wortlaut solcher Nachrichten kann sich ändern. Achten Sie daher auf den Bildschirm, auf den sie zeigt, statt auf die Formulierung. Speichern Sie zudem den Screenshot, denn Sie brauchen diesen Beleg später für Ihre Antwort.

Aus welchen Unterpunkten besteht Richtlinie 5.1.1?

In Apples offiziellen App Review Guidelines umfasst 5.1.1 zehn Unterpunkte, nummeriert von (i) bis (x). Die meisten Ablehnungen, die wir sehen, beziehen sich auf vier oder fünf davon. Die Tabelle fasst die häufigsten Punkte und die übliche Korrektur zusammen:

Kurz gesagt: Sobald Sie die Nachricht einer dieser Zeilen zuordnen, steht die Richtung der Korrektur weitgehend fest.

Wann lässt sich die Ablehnung kaum allein beheben?

Eine Zweckangabe zu korrigieren, kostet die meisten Teams wenige Stunden. Manche Fälle reichen allerdings tiefer. Vielleicht müssen Sie den gesamten Registrierungsablauf neu gestalten, einen Gastmodus in die Datenschicht einbauen oder herausfinden, welches SDK auf welche geschützte Ressource zugreift. Solche Arbeiten verlangen Produktentscheidungen und Codeänderungen zugleich.

Hat ein anderes Team die App gebaut und haben Sie keinen Einblick in Quellcode oder Buildprozess, dann zieht sich die Schleife aus Ablehnung und Neueinreichung oft in die Länge. In diesem Fall kann ein erfahrenes Team für App Entwicklung den Ablauf prüfen und eine zweite Ablehnung nach derselben Regel vermeiden helfen. Trotzdem empfehlen wir, zunächst die Prüfungen in den folgenden Abschnitten selbst durchzugehen, denn viele Ursachen liegen auf Textebene.

Apple schreibt außerdem in den Richtlinien, dass die Prüfung länger dauert, wenn eine App immer wieder am selben Verstoß scheitert. Eine vollständige erste Korrektur ist daher zeitlich der günstigste Weg.

Was ist eine Zweckangabe (Purpose String)?

Eine Zweckangabe, auf Englisch purpose string oder usage description, ist der Text im Berechtigungsdialog des Systems, wenn Ihre App auf eine geschützte Ressource wie Kamera, Standort, Mikrofon oder Fotos zugreifen möchte. Sie hinterlegen ihn in der Info.plist als Wert des passenden Schlüssels, für die Kamera etwa NSCameraUsageDescription.

Apples Leitfaden zu Zweckangaben erklärt, dass das Betriebssystem den Zugriff auf diese Ressourcen sperrt, bis die Person zustimmt. Laut Apple ermöglicht die Zweckangabe eine informierte Entscheidung. Anders gesagt: Dieser Text ist mehr als eine technische Pflicht, er ist der erste Vertrauenssatz zwischen Ihrer App und den Nutzern.

Unterpunkt 5.1.1 (ii) formuliert es deutlich: Ihre Zweckangaben müssen die Nutzung der Daten klar und vollständig beschreiben. Das Review Team öffnet jeden Berechtigungsdialog einzeln und prüft, ob der Text sagt, was die App möchte und wozu. Ein Satz wie "Wir benötigen Ihren Standort" reicht deshalb schon für eine Ablehnung, weil er nur den Namen der Ressource wiederholt.

Warum führen Zweckangaben zur Ablehnung wegen Datenerhebung?

Apples Leitfaden nennt drei typische Merkmale schwacher Zweckangaben. Erstens wiederholen sie den Namen der Ressource, ohne die Nutzung zu erklären. Zweitens versprechen sie vage Vorteile oder verschleiern mit passiven Formulierungen, wer Zugriff auf die Daten hat. Drittens enthalten sie Werbesprache oder eine lange Funktionsliste.

• Nur der Ressourcenname: "Um die Kamera zu nutzen."
• Vager Vorteil: "Ihre Daten verbessern Ihr Erlebnis."
• Werbesprache: "Entdecken Sie unsere großartigen Funktionen!"
• Ein Zweck, den die App nie nutzt: Der Text erwähnt das Scannen von Belegen, die Kamera öffnet sich aber an anderer Stelle.

Der letzte Punkt wiegt am schwersten, weil das Review Team den Text mit dem tatsächlichen Verhalten vergleicht. Sagt Ihr Text zum Beispiel "für ein Profilfoto", erscheint der Kameradialog aber schon beim ersten Start, dann passen Text und Kontext nicht zusammen. Zudem macht es Ärger, denselben Text für mehrere Ressourcen zu kopieren. Apple verlangt für jede geschützte Ressource eine eigene Zweckangabe.

Wie schreiben Sie eine Zweckangabe, die die Prüfung besteht?

Laut Apples Leitfaden besteht eine gute Zweckangabe aus einem kurzen, vollständigen Satz im Aktiv, der mit einem Punkt endet. Außerdem nennt sie die Funktion oder das Ergebnis, das die Daten ermöglichen, und gibt ein konkretes Beispiel. Kurz gesagt: Nach dem Lesen sollte klar sein, was passiert, wenn man auf Erlauben tippt.

Eine einfache Formel hilft: Wer nutzt welche Daten für welche Funktion? Die folgenden Beispiele setzen sie um:

• Standort: "Die App nutzt Ihren Standort, um die nächste Filiale auf der Karte zu zeigen und Ihnen den Weg dorthin anzuzeigen."
• Kamera: "Die App nutzt die Kamera, um den QR Code auf Ihrer Rechnung zu lesen und die Zahlungsmaske auszufüllen."
• Mikrofon: "Die App nutzt das Mikrofon, um Sprachnotizen aufzunehmen und Ihren Einträgen hinzuzufügen."
• Kontakte: "Die App greift auf Ihre Kontakte zu, damit Sie die Person auswählen können, die Sie einladen möchten."

Diese Beispiele folgen derselben Logik wie Apples eigenes Beispiel zur Routenwahl mit Wegbeschreibung. Stellen Sie sich nach jedem Text eine Frage: Erkennt ein Leser, ob die Daten die App verlassen? Teilen Sie die Daten für Werbung oder Analyse, dann sagen Sie das offen.

Wie lokalisieren Sie Zweckangaben in einer mehrsprachigen App?

Unterstützt Ihre App mehrere Sprachen, verlangt Apples Leitfaden ausdrücklich lokalisierte Zweckangaben. Ein einziger englischer Wert in der Info.plist, der in einer deutschen Oberfläche als englischer Dialog erscheint, sorgt also für ein schlechtes Erlebnis und ein echtes Ablehnungsrisiko.

In der Praxis pflegen Sie für jede Sprache eine eigene Datei InfoPlist.strings oder die Lokalisierungsdatei, die Ihr Projekt verwendet. Dort hinterlegen Sie die Übersetzung jedes Schlüssels. Danach stellen Sie die Gerätesprache nacheinander um und öffnen jeden Berechtigungsdialog, um den richtigen Text zu prüfen. Auch Apple rät, die App auf jede Lokalisierung einzustellen und die Anfrage dort zu testen.

Achten Sie beim Übersetzen auf denselben Grad an Konkretheit statt auf eine Wort für Wort Übertragung. Nennt der englische Text etwa die nächste Filiale, dann sollte die deutsche Fassung dieselbe Funktion nennen. Ebenso erfüllen holprige maschinelle Übersetzungen den Maßstab "klar und vollständig" aus Sicht des Review Teams womöglich nicht.

Wie lösen SDKs von Drittanbietern eine Ablehnung nach 5.1.1 aus?

Viele Teams wundern sich über eine Ablehnung wegen einer Berechtigung, die ihr eigener Code nie nutzt. Apples Leitfaden ist hier eindeutig: Sie tragen die Verantwortung für alles in Ihrer App, also auch für SDKs, Bibliotheken und anderen Code von Dritten. Ein Analyse, Werbe oder Karten SDK kann auf eine geschützte Schnittstelle verweisen, ohne dass Sie es bemerken.

Apple beschreibt zwei Wege. Hat Ihre App einen berechtigten Grund für den Zugriff, hinterlegen Sie in der Info.plist eine Zweckangabe zu Ihrem konkreten Anwendungsfall. Fehlt ein solcher Grund, entfernen Sie die Verweise auf diese Schnittstellen aus dem Binary. Folglich akzeptiert das Review Team den Satz "Das SDK fragt, wir nutzen es nicht" nicht als Antwort.

1. Listen Sie alle Abhängigkeiten des Projekts auf.
2. Prüfen Sie in der Dokumentation jedes SDK, auf welche geschützten Ressourcen es zugreifen kann.
3. Deaktivieren oder entfernen Sie Module, die Sie nicht nutzen.
4. Schreiben Sie für jeden verbleibenden Zugriff eine Zweckangabe zu Ihrer eigenen Funktion.

Zudem müssen Sie die von SDKs erhobenen Daten in den Datenschutzangaben im App Store korrekt ausweisen. Wie das geht, zeigt unser Leitfaden zu den App Store Datenschutzangaben.

Warum führen unnötige persönliche Daten zur Ablehnung?

Unterpunkt 5.1.1 (v) untersagt Apps, für ihre Funktion persönliche Angaben zu verlangen, sofern diese nicht direkt mit der Kernfunktion zusammenhängen oder gesetzlich nötig sind. Eine Taschenrechner App, die auf dem ersten Bildschirm Geburtsdatum und Telefonnummer abfragt, verstößt also direkt gegen diese Regel.

Unterpunkt (x) erlaubt dagegen die Abfrage einfacher Kontaktdaten wie Name und E-Mail Adresse, allerdings unter drei Bedingungen. Die Abfrage muss freiwillig bleiben. Keine Funktion darf von der Angabe abhängen. Außerdem muss die App alle übrigen Regeln einhalten, auch die Grenzen bei der Datenerhebung von Kindern. Ein E-Mail Feld für einen Newsletter ist also möglich, ein Satz wie "Ohne E-Mail geht es nicht weiter" dagegen nicht.

Prüfen Sie Ihre Formulare Feld für Feld mit einer Frage: Funktioniert die Funktion auch ohne diese Angabe? Lautet die Antwort ja, machen Sie das Feld optional oder streichen es. Eine Liefer App braucht zum Beispiel eine Adresse, aber keinen Beruf und kein Geschlecht. Für Nutzer in der EU gilt zudem die DSGVO; Grundlagen dazu finden Sie in unserem DSGVO Leitfaden. Dieser Beitrag ist keine Rechtsberatung.

Wie entfernen Sie den Loginzwang bei Funktionen ohne Kontobezug?

Der erste Satz von 5.1.1 (v) besagt sinngemäß: Bietet Ihre App keine wesentlichen kontobasierten Funktionen, dann lassen Sie Menschen sie ohne Login nutzen. Diese Ablehnung trifft besonders oft Katalog, Menü, Inhalts und Informations Apps.

Nehmen Sie als Beispielszenario eine Restaurant App. Speisekarte, Öffnungszeiten und Preise brauchen kein Konto. Eine Bestellung, der Bestellverlauf oder ein Punktekonto brauchen dagegen eines. Der richtige Ablauf lässt Gäste also zunächst hinein und fragt erst dann nach einem Login, wenn jemand einen Schritt mit echtem Kontobezug erreicht.

1. Teilen Sie alle Bildschirme in zwei Gruppen: funktioniert ohne Konto oder braucht ein Konto.
2. Entfernen Sie den Pflichtlogin beim Start oder machen Sie ihn leicht überspringbar.
3. Zeigen Sie Login oder Registrierung erst, wenn jemand eine kontobasierte Aktion beginnt.
4. Speichern Sie Gastdaten lokal und übertragen Sie sie nach der Registrierung.

Unterstützt Ihre App die Kontoerstellung, verlangt dieselbe Regel außerdem die Kontolöschung innerhalb der App. Diese eigene, eng verwandte Anforderung erklären wir im Beitrag zu Apples Pflicht zur Kontolöschung.

Was sagt Richtlinie 5.1.1 zum Login über soziale Netzwerke?

Unterpunkt 5.1.1 (v) enthält eine eigene Regel zu sozialen Netzwerken. Hängt die Kernfunktion Ihrer App nicht mit einem bestimmten Netzwerk zusammen, dann müssen Sie Zugang ohne Login oder über einen anderen Weg bieten. Basisdaten aus dem Profil abrufen, Inhalte im Netzwerk teilen oder Freunde einladen zählt Apple nicht als Kernfunktion.

Daneben stellt die Regel zwei technische Bedingungen. Erstens braucht die App einen Weg, die Zugangsdaten zum Netzwerk zu widerrufen und den Datenzugriff zwischen App und Netzwerk innerhalb der App zu trennen. Zweitens darf die App solche Zugangsdaten oder Tokens nicht außerhalb des Geräts speichern. Sie darf sie nur nutzen, um sich bei laufender App direkt mit dem Netzwerk zu verbinden.

Eine App, die ausschließlich einen sozialen Login anbietet, trägt somit ein Risiko, wenn ihre Kernfunktion nichts mit diesem Netzwerk zu tun hat. Die übliche Lösung ergänzt einen alternativen Weg, etwa einen Gastmodus oder einen Login per E-Mail, sowie eine Option zum Trennen in den Einstellungen. So erfüllen Sie die Regel und behalten Nutzer ohne Konto im jeweiligen Netzwerk.

Sollten Sie die Systemauswahl statt Vollzugriff nutzen?

Unterpunkt 5.1.1 (iii) zur Datenminimierung verlangt, dass Apps nur Zugriff auf Daten anfragen, die für ihre Kernfunktion relevant sind, und nur das erheben, was eine Aufgabe erfordert. Zudem empfiehlt die Regel, wo möglich die Systemauswahl außerhalb des App Prozesses (out of process picker) oder das Teilen Menü zu nutzen, statt Vollzugriff auf Fotos oder Kontakte anzufragen.

Konkret heißt das: Möchte jemand ein Profilbild hochladen, brauchen Sie keinen Zugriff auf die gesamte Fotomediathek. Die Fotoauswahl des Systems übergibt Ihrer App nur das gewählte Bild, den Rest sieht die App nie. Dadurch entfällt der Berechtigungsdialog komplett, und die Frage des Review Teams nach dem Grund für den Vollzugriff stellt sich gar nicht.

Dieselbe Logik gilt für Kontakte. Statt das gesamte Adressbuch zu lesen, um eine einzige Einladung zu senden, genügt meist die Systemoberfläche zur Auswahl eines einzelnen Kontakts. Zusammengefasst: Weniger Berechtigungen sind die stärkste Korrektur nach 5.1.1, denn eine Berechtigung, die Sie nie anfragen, braucht auch keine Zweckangabe.

Welche Alternative bieten Sie Nutzern, die eine Berechtigung ablehnen?

Unterpunkt 5.1.1 (iv) verlangt, dass Apps die Berechtigungseinstellungen respektieren und niemanden zu unnötigem Datenzugriff drängen, verleiten oder zwingen. Apple nennt zwei Beispiele. Eine App, die Fotos in einem sozialen Netzwerk teilt, darf vor dem Hochladen keinen Mikrofonzugriff verlangen. Lehnt jemand die Standortfreigabe ab, sollte die App eine manuelle Adresseingabe anbieten.

Diese Regel zielt auf Abläufe nach dem Muster "ohne Freigabe keine App". Ein leerer Bildschirm mit dem bloßen Hinweis auf die Einstellungen nach einer Standortablehnung ist zum Beispiel riskant. Stattdessen ergänzen Sie Alternativen wie eine Suche nach Stadt oder Postleitzahl oder das manuelle Setzen eines Punkts auf der Karte.

• Standort abgelehnt: manuelle Eingabe von Adresse oder Stadt.
• Kamera abgelehnt: Auswahl aus der Mediathek oder manuelle Codeeingabe.
• Mitteilungen abgelehnt: ein Posteingang innerhalb der App.
• Kontakte abgelehnt: manuelle Eingabe der Telefonnummer.

Außerdem sollte ein Erklärbildschirm vor dem Systemdialog niemanden zum Tippen auf Erlauben drängen. Die Berechtigung für Werbetracking folgt einem eigenen Rahmen, den wir im Beitrag zu App Tracking Transparency (ATT) erklären.

Was muss der Link zur Datenschutzerklärung abdecken?

Nach 5.1.1 (i) müssen alle Apps einen Link zu ihrer Datenschutzerklärung im passenden Metadatenfeld von App Store Connect und gut erreichbar innerhalb der App bereitstellen. Die Erklärung selbst muss drei Bereiche klar und ausdrücklich abdecken.

• Welche Daten die App erhebt, wie sie diese erhebt und wofür sie sie nutzt.
• Die Bestätigung, dass Dritte wie Analysetools, Werbenetzwerke und SDKs denselben oder einen gleichwertigen Schutz bieten.
• Regeln zu Aufbewahrung und Löschung sowie den Weg, eine Einwilligung zu widerrufen oder die Löschung zu beantragen.

Ein häufiger Fehler ist eine allgemeine Erklärung, die eigentlich für die Website entstand. Ein solcher Text erwähnt womöglich nie, warum die App Kamera oder Standort nutzt. Passen Sie die Erklärung daher an den tatsächlichen Datenfluss der App an und lassen Sie keine Widersprüche zwischen Zweckangaben, Datenschutzangaben und Erklärung zu. Stützen sich die drei Dokumente gegenseitig, erleichtert das auch dem Review Team die Arbeit.

Was sagen die Regeln zu Widerruf und kostenpflichtigen Funktionen?

Unterpunkt 5.1.1 (ii) verlangt, dass Apps für die Erhebung von Nutzer oder Nutzungsdaten eine Einwilligung einholen, auch wenn die Daten zum Zeitpunkt der Erhebung als anonym gelten. Die Regel stellt zwei weitere Bedingungen. Kostenpflichtige Funktionen dürfen nicht von der Freigabe dieser Daten abhängen. Außerdem braucht die App einen leicht erreichbaren, verständlichen Weg, die Einwilligung zu widerrufen.

Öffnet eine App ihr Premiumangebot zum Beispiel nur für Nutzer, die Standort oder Kontakte freigeben, verstößt sie direkt gegen diese Regel. Ebenso problematisch ist es, wenn jemand für den Widerruf der Analyseeinwilligung eine E-Mail an den Support schreiben muss. Ein klarer Schalter in den Einstellungen erfüllt die Anforderung am einfachsten.

Die Regel sagt zudem, dass Apps, die ohne Einwilligung Daten auf Grundlage eines berechtigten Interesses nach der DSGVO oder einem ähnlichen Gesetz erheben, alle Bedingungen dieses Gesetzes erfüllen müssen. Hier brauchen Sie eine rechtliche Einschätzung. Dieser Beitrag ist keine Rechtsberatung; sprechen Sie dafür mit einer Anwältin oder einem Anwalt.

Wie schreiben Sie eine Antwort im Resolution Center?

Was viele Entwickler noch Resolution Center nennen, ist heute der Nachrichtenbereich für App Review in App Store Connect. Laut Apples Hilfeseite zum Antworten auf App Review Nachrichten wählen Sie Ihre App, klicken oben auf den Link zu offenen Problemen, dann neben der Einreichung auf Resolve und schließlich auf Reply to App Review. Screenshots und weitere Unterlagen können Sie anhängen.

Apple sagt auch, wie die Antwort aussehen sollte. Seien Sie konkret und nennen Sie die genaue Funktion, Regel oder den Schritt, um den es geht. Glauben Sie, dass das Review Team die App missverstanden hat, dann ergänzen Sie Informationen zu Konzept und beabsichtigter Funktion. Eine gute Antwort nach 5.1.1 ist also keine lange Verteidigung, sondern ein kurzer Änderungsbericht.

1. Nennen Sie den betroffenen Unterpunkt.
2. Beschreiben Sie pro Problem in einem Satz, was Sie geändert haben.
3. Zitieren Sie die neuen Zweckangaben oder beschreiben Sie die Formularänderung genau.
4. Hängen Sie einen Screenshot an, der die Änderung zeigt.
5. Aktualisieren Sie bei Bedarf das Demokonto im Bereich App Review Information.

Beachten Sie, dass Apple dieses Antwortfeld nicht für Einsprüche vorsieht. Dafür gibt es ein eigenes Formular.

Antworten, neu einreichen oder Einspruch einlegen?

Nach einer Ablehnung wegen Datenerhebung haben Sie drei Wege, und die richtige Wahl hängt davon ab, ob das Problem wirklich besteht. Ist das der Fall, etwa bei einer vagen Zweckangabe oder einem Loginzwang, dann beheben Sie es, reichen einen neuen Build ein und erklären die Änderung in einer kurzen Antwort.

Hat das Review Team dagegen eine Funktion missverstanden, etwa übersehen, dass Standortdaten das Gerät nie verlassen, erklären Sie das zunächst über App Store Connect. Auch Apples Leitfaden zum Einspruch beim App Review Board verlangt, vor dem Einspruch auf die Nachricht zu antworten und den Sachverhalt zu klären. Reicht diese Klärung nicht, folgt das Einspruchsformular.

Im Einspruch erwartet Apple, dass Sie die konkrete Regel nennen und Punkt für Punkt erklären, wie Ihre App sie erfüllt. Pro abgelehnter App reichen Sie nur einen Einspruch ein. Nennt die Ablehnung mehrere Regeln, behandeln Sie alle im selben Einspruch. Haben Sie das Problem bereits behoben und neu eingereicht, legen Sie keinen Einspruch ein. Der Leitfaden stellt klar, dass auch ein vollständiger Einspruch keine Aufhebung garantiert. Auch wir versprechen keine Freigabe; der richtige Weg verkürzt lediglich den Prozess.

Welche Fehler bringen die Ablehnung wegen Datenerhebung zurück?

Eine zweite Ablehnung wegen Datenerhebung nach derselben Regel hat meist eine halbfertige Korrektur als Ursache. Diese Fehler sehen wir am häufigsten:

• Nur die genannte Berechtigung korrigieren und andere vage Zweckangaben stehen lassen.
• Die Texte in der Basissprache ändern und die übrigen Lokalisierungsdateien vergessen.
• Beim Startlogin einen Überspringen Knopf ergänzen und auf dem nächsten Bildschirm erneut einen Login verlangen.
• Ein ungenutztes SDK Modul im Code lassen.
• Die Datenschutzerklärung aktualisieren, den Link in der App aber nie ergänzen.

Beschränken Sie die Korrektur deshalb nicht auf den genannten Bildschirm, sondern prüfen Sie die ganze App mit demselben Blick. Findet das Review Team bei der nächsten Einreichung dasselbe Problem an anderer Stelle, folgt eine neue Ablehnung nach 5.1.1. Löschen Sie die App außerdem vor dem Einreichen und testen Sie mit frischer Installation, weil früher erteilte Freigaben die Dialoge sonst verbergen.

Ablehnungen wegen fehlender oder halb funktionierender Funktionen beruhen auf einer anderen Regel. Mehr dazu lesen Sie im Beitrag zur Ablehnung nach Richtlinie 2.1.

Was bedeutet ein ähnliches Datenproblem bei Google Play?

Veröffentlichen Sie in beiden Stores, dann lohnt es sich, Ihre Korrektur nach 5.1.1 auch in die Android Version zu übernehmen. Google Play hat einen eigenen Richtlinienrahmen und eigene Abläufe, Apples Nummern gelten dort also nicht. Dennoch können unnötige Berechtigungen und eine undurchsichtige Datenerhebung auch dort Probleme verursachen.

Die Schritte für eine Play App, die wegen eines Richtlinienverstoßes entfernt wurde, erklären wir im Beitrag zum Einspruch nach einer Entfernung bei Google Play. Zur Testpflicht für neue Entwicklerkonten lesen Sie unseren Leitfaden zum geschlossenen Test bei Google Play. Betrifft die Sperre Ihr ganzes Konto, passt unser Artikel zum gekündigten Google Play Entwicklerkonto besser.

Ein wichtiger Hinweis: In keinem Store löst es das Problem, dieselbe App unter einem neuen Konto oder über verbundene Konten erneut hochzuladen, um eine Ablehnung oder Sperre zu umgehen. Im Gegenteil, dieser Weg kann den Verstoß verschärfen und Maßnahmen gegen das ganze Konto nach sich ziehen. Der richtige Weg bleibt immer, das Problem zu beheben und über den offiziellen Kanal neu einzureichen.

Wann lohnt sich Unterstützung bei einer Ablehnung wegen Datenerhebung?

Korrekturen an Zweckangaben und Formularfeldern schafft Ihr eigenes Team in der Regel selbst. Ein Blick von außen spart allerdings Zeit, wenn sich die Ablehnung zwei oder drei Mal wiederholt, wenn die Nachricht den gesamten Registrierungsablauf betrifft oder wenn unklar bleibt, welches SDK welche Berechtigung auslöst. Dasselbe gilt, wenn Sie keinen Zugang zum Quellcode haben oder der frühere Entwickler nicht mehr erreichbar ist.

Wir, Talha Aslan und Team, beginnen solche Aufträge damit, die Ablehnungsnachricht und alle Berechtigungen der App zu erfassen. Danach planen wir Code und Textänderungen in einem Durchgang. Dennoch sagen wir offen: Kein Team kann eine Freigabe durch Apple garantieren, die Entscheidung liegt immer beim App Review Team. Möchten Sie den Datenfluss Ihrer App von Anfang an sauber aufbauen oder eine bestehende App überarbeiten, dann sehen Sie sich an, wie Sie bei uns eine App entwickeln lassen können.

Die dauerhafteste Lösung gegen eine Ablehnung wegen Datenerhebung sind Entscheidungen zu Berechtigungen und Daten schon im Design. Dann beginnt jede neue Funktion mit derselben Frage: Brauchen wir diese Daten wirklich?

Welche letzten Prüfungen sollten Sie vor der Einreichung machen?

Haken Sie vor dem Hochladen des neuen Builds die folgende Liste Punkt für Punkt ab. Wir haben sie so aufgebaut, dass sie alle Unterpunkte von Richtlinie 5.1.1 abdeckt:

• Jede geschützte Ressource hat eine eigene, konkrete Zweckangabe in einem Satz.
• Die Zweckangaben liegen in allen unterstützten Sprachen vor, und Sie haben sie auf einem Gerät getestet.
• Ungenutzte SDK Module und Schnittstellenverweise sind entfernt.
• Inhalte ohne Kontobezug öffnen sich im Gastmodus.
• Felder wie Name und E-Mail bleiben freiwillig, und keine Funktion hängt davon ab.
• Wer eine Berechtigung ablehnt, sieht eine Alternative.
• Die Datenschutzerklärung ist aktuell und in der App erreichbar.
• Eine klare Widerrufsoption steht in den Einstellungen.

Ist die Liste vollständig, löschen Sie die App, installieren sie neu und öffnen jeden Berechtigungsdialog nacheinander. Danach schreiben Sie Ihre kurze Antwort auf die Ablehnung und reichen den neuen Build ein. Diese Reihenfolge senkt das Risiko einer zweiten Ablehnung nach derselben Regel spürbar.