Ist Sign in with Apple Pflicht? Ablehnung nach Richtlinie 4.8 beheben

Falls Sie die Ablehnung gerade erhalten haben, bleiben Sie ruhig. Diese Ablehnung ist gut bekannt und hat eine klare Lösung. Gehen Sie deshalb in der folgenden Reihenfolge vor, dann erledigen Sie Codeänderung und Antwort meist in einer Runde.

1. Prüfen Sie, ob die Ablehnung tatsächlich Richtlinie 4.8 nennt, und notieren Sie den betroffenen Bildschirm.
2. Listen Sie alle Wege zur Registrierung und Anmeldung in Ihrer App auf: E-Mail, Google, Facebook, Telefonnummer und weitere.
3. Prüfen Sie ehrlich, ob Ihre App unter eine der offiziellen Ausnahmen fällt.
4. Gibt es keine Ausnahme, ergänzen Sie Apples Anmeldung oder einen anderen Dienst mit allen drei Datenschutzmerkmalen.
5. Platzieren Sie den neuen Button auf demselben Bildschirm wie die übrigen Anmeldebuttons und mindestens genauso sichtbar.
6. Laden Sie einen neuen Build hoch und erklären Sie die Änderung kurz in Ihrer Antwort an App Review.

Dieser Beitrag konzentriert sich ausschließlich auf die Ablehnung nach 4.8. Einen breiteren Überblick finden Sie in unserem Leitfaden warum Apps am häufigsten abgelehnt werden.

Was verlangt Richtlinie 4.8 genau?

Den aktuellen Wortlaut finden Sie in den Apple App Review Guidelines. Kurz gesagt: Eine App, die das Hauptkonto über einen Drittanbieter oder Social Login einrichtet oder bestätigt, muss als gleichwertige Option zusätzlich einen weiteren Anmeldedienst anbieten. Als Beispiele nennt Apple Facebook Login, Google Sign In, Log in with X, Sign In with LinkedIn, Login with Amazon und WeChat Login.

Der zweite Dienst muss dabei alle drei Merkmale erfüllen:

• Er beschränkt die Datenerhebung auf Namen und E-Mail der Nutzer.
• Er erlaubt Nutzern, ihre E-Mail bei der Kontoeinrichtung privat zu halten.
• Er erfasst Interaktionen mit Ihrer App ohne Einwilligung nicht zu Werbezwecken.

Beachten Sie: Der Text beschreibt Merkmale und nennt kein bestimmtes Produkt. Frühere Fassungen der Regel verlangten Apples Anmeldung noch namentlich. Die aktuelle Fassung lässt dagegen jeden Dienst zu, der die drei Kriterien erfüllt. Allerdings erfüllt Apples Option diese Kriterien weiterhin am eindeutigsten. Weil sich die Regel im Lauf der Zeit verändert hat, prüfen Sie den aktuellen Text immer direkt bei Apple.

Was gilt als Hauptkonto?

Apple beschreibt das Hauptkonto als das Konto, das Nutzer in Ihrer App anlegen, um sich zu identifizieren, sich anzumelden und Ihre Funktionen sowie zugehörige Dienste zu nutzen. Das heißt, die Regel betrifft die Haupttür Ihrer App.

Nehmen Sie zum Beispiel eine App zur Fotobearbeitung. Registrieren sich Nutzer mit Google und greifen dann auf ihre eigenen Projekte zu, richtet dieser Google Login das Hauptkonto ein; somit greift Richtlinie 4.8. Verbindet sich dieselbe App dagegen nur mit Google Drive, um Fotos zu exportieren, handelt es sich um eine Integration und nicht um ein Hauptkonto.

Diese Unterscheidung stärkt außerdem Ihre Antwort. Sie können App Review etwas Konkretes schreiben, etwa: „Die Google Verbindung dient nur dem Dateiexport und legt kein Konto an.“ Trotzdem muss die Erklärung genau zum tatsächlichen Ablauf in Ihrem Build passen. Sonst kommt bei der nächsten Prüfung dieselbe Ablehnung zurück.

Welche Apps sind von Richtlinie 4.8 ausgenommen?

Der offizielle Text nennt fünf Fälle, in denen kein zusätzlicher Anmeldedienst nötig ist. Wenn Sie glauben, dass Ihre App darunter fällt, stützen Sie Ihre Begründung auf diese Punkte:

• Ihre App nutzt ausschließlich das eigene Konto und Anmeldesystem Ihres Unternehmens.
• Sie ist ein alternativer App Marktplatz oder stammt aus einem solchen und nutzt eine marktplatzeigene Anmeldung für Konto, Download und Handel.
• Es handelt sich um eine Bildungs, Unternehmens oder Business App, die eine Anmeldung mit einem bestehenden Bildungs oder Firmenkonto verlangt.
• Die Anmeldung läuft über ein staatliches oder branchengestütztes Bürgeridentifikationssystem beziehungsweise eine elektronische ID.
• Die App ist ein Client für einen bestimmten Drittanbieterdienst, und Nutzer müssen sich direkt bei diesem Mail, Social Media oder sonstigen Konto anmelden, um ihre Inhalte zu sehen.

In der Praxis sorgt die erste Ausnahme für die meisten Missverständnisse. Das Wort „ausschließlich“ ist hier entscheidend. Sobald Sie neben Ihrem eigenen System einen einzigen Google Button anbieten, fallen Sie nicht mehr darunter.

Reicht Ihre eigene Anmeldung mit E-Mail und Passwort?

Bietet Ihre App nur die eigene Registrierung mit E-Mail und Passwort an, brauchen Sie keinen zusätzlichen Dienst. Schwierig wird es erst, wenn Sie neben Ihrem eigenen System einen Social Login anbieten.

Viele Teams gehen dann davon aus, dass ihre E-Mail Registrierung bereits als gleichwertige Option zählt. Allerdings beschreibt die Richtlinie die gleichwertige Option als „anderen Anmeldedienst“ mit drei Datenschutzmerkmalen. Dass Ihr eigenes Formular dazugehört, steht dort nicht. Daher gibt es keine verlässliche Grundlage dafür, dass dieses Argument trägt.

Unser Rat ist einfach: In den meisten Projekten ist es schneller, Apples Anmeldung zu ergänzen, als darüber zu diskutieren. So verlassen Sie die Ablehnungsschleife, und Ihre Nutzer erhalten zudem eine Option ganz ohne neues Passwort. Ihre eigene Registrierung müssen Sie dafür nicht entfernen; alle drei Optionen können nebeneinander bestehen.

Wollen Sie trotzdem argumentieren, dass Ihr Ablauf die Regel erfüllt, erklären Sie schriftlich, wie er jedes der drei Merkmale liefert. Auch dann hängt das Ergebnis davon ab, wie App Review Ihre Erklärung liest.

Welche Anmeldeoptionen erfüllen Richtlinie 4.8?

Die folgende Tabelle vergleicht gängige Anmeldevarianten aus Sicht der Regel. Sie ist unsere Einschätzung; die endgültige Entscheidung trifft immer App Review.

Die vierte Zeile ist die riskanteste. Gerade kleine Teams starten oft mit genau dieser Kombination und erhalten bei der ersten Prüfung eine Ablehnung.

Warum ist Apples Anmeldung meist die schnellste Lösung?

Theoretisch können Sie einen anderen Dienst wählen, der die drei Kriterien erfüllt. Allerdings liegt der Nachweis dafür bei Ihnen. Apples Option bietet das Verbergen der E-Mail bereits an; deshalb fragt App Review hier seltener nach.

Zudem bringt iOS ein Systemframework mit. Nutzer legen ihr Konto mit Face ID oder dem Gerätecode mit einem Fingertipp an und überspringen also das Registrierungsformular. In der Praxis kann das Abbrüche beim Anmelden verringern.

Andererseits gehören Serverarbeit, das private Mail Relay und die Kontolöschung zur Integration. Diese Teile beim ersten Mal richtig aufzusetzen kostet Zeit, und eine Lücke kann eine neue Ablehnung auslösen. Fehlt Ihrem Team diese Erfahrung, unterstützen wir Sie im Rahmen unserer App Entwicklung dabei, den gesamten Anmeldeablauf durchgängig zu planen. Möchten Sie die Integration selbst umsetzen, führen Sie die nächsten Abschnitte Schritt für Schritt durch alle Punkte.

Wo platzieren Sie den Sign in with Apple Button?

Apples Human Interface Guidelines zu Sign in with Apple legen klare Regeln für den Button fest. Zeigen Sie ihn gut sichtbar, machen Sie ihn nicht kleiner als andere Anmeldebuttons und zwingen Sie Nutzer nicht zum Scrollen.

• Verwenden Sie als Beschriftung nur „Sign in with Apple“, „Sign up with Apple“ oder „Continue with Apple“.
• Wählen Sie je nach Hintergrund zwischen schwarzem, weißem und weißem Stil mit Umrandung.
• Nutzen Sie den schwarzen Stil nicht auf dunklem Hintergrund und den umrandeten Stil auf hellen Flächen mit wenig Kontrast.
• Bleiben Sie auf allen Anmelde und Registrierungsbildschirmen bei derselben Beschriftung.

Den häufigsten Fehler sehen wir beim Verstecken der Apple Option in einem Menü für weitere Optionen. Wenn zum Beispiel der Google Button die volle Breite einnimmt, Apples Option aber nur ein kleines Symbol ist, wertet App Review das möglicherweise nicht als gleichwertig. Platzieren Sie deshalb beide Buttons auf demselben Bildschirm, gleich groß und untereinander.

Wie fragen Sie Namen und E-Mail richtig ab?

Im Apple Ablauf können Sie Name und E-Mail anfordern. Nutzer dürfen ihren Namen dann anpassen, eine andere Kontaktadresse wählen oder ihre E-Mail ganz verbergen. Verbergen sie sie, erzeugt Apple eine eindeutige Weiterleitungsadresse, die Nachrichten an das echte Postfach weiterleitet.

Die Designrichtlinien verlangen, dass Sie diese Entscheidung respektieren. Fragen Sie also nicht nach einer persönlichen E-Mail, nachdem jemand eine Weiterleitungsadresse geteilt hat. Verlangen Sie außerdem kein Passwort, denn ein zentraler Vorteil der Methode besteht gerade darin, dass Nutzer keins anlegen müssen.

• Brauchen Sie zusätzliche Daten wie ein Geburtsdatum, halten Sie die Abfrage minimal und sagen Sie, ob sie Pflicht oder freiwillig ist.
• Sperren Sie Konto und Funktionen nicht für Personen, die freiwillige Angaben auslassen.
• Speichern Sie Namen und E-Mail sofort auf Ihrem Server, da spätere Anmeldungen sie unter Umständen nicht erneut liefern.

Der letzte Punkt ist in der Praxis besonders wichtig. In der Entwicklergemeinschaft ist die Erfahrung verbreitet, dass diese Angaben meist nur bei der ersten Autorisierung ankommen. Speichert Ihr Server die erste Antwort nicht, bleibt der Nutzer womöglich mit einem namenlosen Konto zurück.

Wie richten Sie das private Mail Relay ein?

Verbirgt ein Nutzer seine E-Mail, erhalten Sie eine Weiterleitungsadresse. Möchten Sie dorthin Bestellbestätigungen oder andere Nachrichten senden, müssen Sie zunächst auf Apples Seite Vorarbeit leisten. Laut Apples Hilfeseite zum privaten Mail Relay registrieren und bestätigen Sie jede Domain und Subdomain, von der Sie senden.

1. Listen Sie alle Domains und Subdomains auf, von denen Ihre App Mails versendet.
2. Registrieren Sie diese Quellen im passenden Bereich Ihres Apple Developer Kontos.
3. Authentifizieren Sie ausgehende Mails mit SPF und nach Möglichkeit mit DKIM; Apple empfiehlt beides.
4. Prüfen Sie, ob die Absenderdomain exakt mit der registrierten Domain übereinstimmt.
5. Senden Sie mit einem Testkonto eine Nachricht an eine Weiterleitungsadresse und kontrollieren Sie die Zustellung.

Vergessen Sie eine Quelle, kommen Nachrichten an die Weiterleitungsadresse als unzustellbar zurück. Versenden Sie zum Beispiel Marketingmails über eine eigene Subdomain, tragen Sie auch diese ein. Dieser Schritt löst zwar keine Ablehnung nach 4.8 aus; trotzdem schadet er der Nutzererfahrung und erhöht die Zahl der Supportanfragen.

Was passiert mit Apple Tokens, wenn Nutzer ihr Konto löschen?

Apps mit Kontoerstellung müssen Nutzern auch die Kontolöschung direkt in der App ermöglichen. Diese Regel haben wir ausführlich im Beitrag über Apples Pflicht zur Kontolöschung behandelt; hier geht es nur um die Seite der Apple Anmeldung.

Laut den häufigen Fragen in Apples Hinweisen zur Kontolöschung sollen Apps mit Apples Anmeldung beim Löschen eines Kontos die Nutzertokens über die Sign in with Apple REST API widerrufen. Außerdem empfiehlt Apple Benachrichtigungsendpunkte von Server zu Server, um Änderungen an diesen Konten zu verarbeiten.

Planen Sie die Löschung also gleich zusammen mit der Anmeldung. Ihr Server sollte die für den Widerruf nötigen Tokens bei der Anmeldung sicher speichern. Sonst bleibt die Autorisierung auf Apples Seite womöglich aktiv, obwohl der Nutzer auf Löschen getippt hat, und genau das kann zu einer zweiten Ablehnung führen.

Warum sollten Sie den Anmeldestatus beim App Start prüfen?

Nutzer können den Zugriff Ihrer App jederzeit in den Einstellungen ihres Apple Accounts entziehen. Deshalb prüft Apples Beispielcode bei jedem Start den Status der gespeicherten Nutzerkennung.

Ist der Status autorisiert, läuft die App normal weiter. Ist der Zugriff entzogen oder die Kennung nicht auffindbar, zeigt die App erneut den Anmeldebildschirm. So bleibt niemand mit einer alten Sitzung in der App, der den Zugriff bereits entzogen hat.

Eine fehlende Prüfung führt nicht automatisch zu einer Ablehnung. Trotzdem kann ein ungewöhnliches Sitzungsverhalten auf dem Testgerät der Prüfer zu einer separaten Rückmeldung führen, etwa dass die App nicht richtig funktioniert. Zu solchen Ablehnungen wegen Unvollständigkeit lesen Sie unseren Beitrag zur Ablehnung nach Richtlinie 2.1.

Wie gehen Sie auf anderen Plattformen mit Apples Anmeldung um?

Viele Apps teilen ein Kontosystem zwischen iOS, Android und Web. Überlegen Sie dann rechtzeitig, wie ein Nutzer, der sich unter iOS mit Apple registriert hat, auf anderen Plattformen an dasselbe Konto kommt.

Apple bietet für seine Anmeldung auch einen Ablauf im Web an. Die Einrichtungsdetails sollten Sie allerdings in Apples Entwicklerdokumentation prüfen, bevor Sie sich darauf verlassen. Hat der Nutzer seine E-Mail verborgen, ist ein Abgleich über die E-Mail auf einer anderen Plattform zudem eventuell unmöglich. Verknüpfen Sie Konten daher über die dauerhafte Nutzerkennung von Apple statt über die E-Mail.

Ein Beispielszenario: Ein Team, das aus einer React Native Codebasis für beide Plattformen veröffentlicht, hat Apples Anmeldung unter Android womöglich gar nicht eingeplant. Dann kommt ein unter iOS registrierter Nutzer unter Android nicht in sein Konto. Vor und Nachteile einer gemeinsamen Codebasis erklären wir in unserem Leitfaden zu React Native. Für Richtlinienfragen unter Android hilft Ihnen unser Beitrag zum Einspruch nach einem Google Play Richtlinienverstoß.

Wie antworten Sie auf eine Ablehnung nach Richtlinie 4.8?

Ihre Antwort senden Sie über die Prüfkorrespondenz in App Store Connect. Ziel ist, dass der Prüfer die Änderung schnell nachvollziehen kann. Verzichten Sie deshalb auf lange Verteidigungen und schreiben Sie kurze, konkrete und überprüfbare Angaben.

1. Korrigieren Sie zuerst den Code und laden Sie einen neuen Build hoch; eine reine Nachricht genügt meist nicht.
2. Nennen Sie die ergänzte Anmeldeoption und den Bildschirm, auf dem sie erscheint.
3. Fügen Sie bei Bedarf einen Screenshot oder eine kurze Bildschirmaufnahme bei.
4. Halten Sie die Zugangsdaten des Demokontos in den Prüfnotizen aktuell.
5. Berufen Sie sich auf eine Ausnahme, nennen Sie den genauen Punkt.

Eine Beispielantwort könnte lauten: „Wir haben auf dem Anmeldebildschirm einen Sign in with Apple Button in derselben Größe wie den Google Button ergänzt. Im neuen Build erscheinen beide Optionen beim ersten Start untereinander.“ Eine so kurze Notiz wirkt oft besser als ein langer Text.

Was schreiben Sie, wenn Sie eine Ausnahme geltend machen?

Fällt Ihre App tatsächlich unter eine Ausnahme, können Sie ohne Codeänderung antworten. Ihre Antwort muss sich dann allerdings auf Belege stützen.

Entwickeln Sie zum Beispiel eine Unternehmensapp, erklären Sie, dass sich Nutzer nur mit dem bestehenden Firmenkonto anmelden können und es keine individuelle Registrierung gibt. Ebenso sollte eine App mit elektronischer ID das genutzte ID System nennen. Ein Client für einen Drittanbieterdienst sollte darlegen, dass Nutzer ihre Inhalte nur über das Konto dieses Dienstes erreichen.

Akzeptiert App Review Ihre Erklärung nicht, bleiben zwei Wege: die Änderung umsetzen oder Einspruch beim App Review Board einlegen, Apples offiziellem Kanal dafür. Auch ein Einspruch bietet keine Garantie, denn die Entscheidung trifft Apple. Nutzen Sie im Einspruch daher nur überprüfbare Fakten und zitieren Sie den offiziellen Regeltext.

Welche Fehler passieren bei der Integration am häufigsten?

Wenn Teams die Integration nach einer Ablehnung unter Zeitdruck umsetzen, tauchen immer wieder dieselben Fehler auf. Nutzen Sie die folgende Liste als Prüfliste vor dem nächsten Upload:

• Den Apple Button nur auf dem Registrierungsbildschirm einbauen und den Anmeldebildschirm vergessen.
• Nach der Apple Anmeldung trotzdem ein Passwort oder eine persönliche E-Mail verlangen.
• Name und E-Mail aus der ersten Autorisierung nicht speichern.
• Absenderdomains für das private Mail Relay nicht registrieren.
• Apple Tokens bei der Kontolöschung nicht widerrufen.
• Die Beschriftung des Buttons in eine Formulierung ändern, die die Richtlinien nicht vorsehen.
• Den Anmeldestatus beim App Start nicht prüfen.

Einige dieser Punkte fallen nicht direkt unter Richtlinie 4.8. Trotzdem können sie in derselben Prüfrunde eine Ablehnung nach einer anderen Richtlinie auslösen. Wenn Sie alles auf einmal beheben, sparen Sie also Zeit.

Wie wirkt sich Sign in with Apple auf die Datenschutzangaben aus?

Mit Apples Anmeldung ändern sich unter Umständen die Datentypen, die Sie erheben. Name und E-Mail kommen jetzt zum Beispiel auch über diesen Kanal. Gleichen Sie deshalb Ihre Datenschutzangaben im App Store mit dem neuen Ablauf ab.

Wie Sie diese Angaben Schritt für Schritt ausfüllen, zeigen wir in unserem Leitfaden App Store Datenschutzangaben vorbereiten. Zudem kann eine übermäßige Datenabfrage bei der Registrierung unabhängig von 4.8 mit der Regel zur Datenerhebung kollidieren. Diese Ablehnung behandeln wir im Beitrag zur Ablehnung nach Richtlinie 5.1.1.

Kurz gesagt: Wenn Sie den Anmeldeablauf ändern, aktualisieren Sie nicht nur den Button. Passen Sie auch Ihre Datenschutzhinweise und das Registrierungsformular an. So schaffen Sie beim Lösen einer Ablehnung keinen neuen Ablehnungsgrund.

Warum ist es riskant, die Regel zu umgehen?

Manche Teams überlegen, den Google Button während der Prüfung auszublenden oder Social Login nur in bestimmten Regionen freizuschalten. Solche Taktiken können als Täuschung von App Review gelten und schwerere Folgen haben als eine einfache Ablehnung.

Ebenso ist es keine Lösung, dieselbe App über ein anderes Entwicklerkonto erneut einzureichen. Apples Prüfrichtlinien betrachten Versuche, den Prüfprozess zu täuschen, als schweren Verstoß. Folglich kann ein solcher Versuch das Problem auf die Ebene des Kontos heben. Zur Ablehnung wegen wiederholter Einreichungen lesen Sie unseren Beitrag zur Spam Ablehnung nach Richtlinie 4.3.

Der sicherste Weg besteht darin, den Zweck der Regel anzuerkennen und eine echte gleichwertige Option anzubieten. Das verkürzt den Prüfprozess und gibt Nutzern einen privateren Anmeldeweg.

Wie hängen Passkeys und OAuth mit dieser Regel zusammen?

Die meisten Social Logins beruhen im Hintergrund auf Standards wie OAuth 2.0 und OpenID Connect. Die Grundlagen erklären wir in unserem Leitfaden zu OAuth 2.0. Apples Anmeldung nutzt einen ähnlichen Autorisierungsablauf. Für 4.8 zählt allerdings weniger der technische Standard als die Frage, ob der Dienst die drei Datenschutzmerkmale erfüllt.

Ein Passkey ist dagegen eine Methode zur Anmeldung ohne Passwort. Nutzen Sie Passkeys in Ihrem eigenen Kontosystem, wird daraus kein Anmeldedienst eines Drittanbieters. Bieten Sie also nur Ihr eigenes System mit Passkeys an, gilt die erste Ausnahme weiterhin. Mehr dazu lesen Sie im Beitrag was ein Passkey ist.

Anders sieht es aus, wenn Sie Passkeys im eigenen System einsetzen und zugleich einen Google Button auf demselben Bildschirm behalten. Dann legt der Social Login weiterhin ein Hauptkonto an, Richtlinie 4.8 greift, und Sie brauchen die gleichwertige datenschutzorientierte Option.

Wie schützen Sie bestehende Google Nutzer?

Ist Ihre App schon länger live, haben Sie bereits Nutzer, die sich mit Google oder Facebook registriert haben. Nach dem Einbau von Apples Button tippen manche davon versehentlich darauf und legen ein zweites, leeres Konto an. Das erhöht Supportanfragen und Beschwerden.

Einige Schutzmaßnahmen helfen. Zeigen Sie zunächst auf dem Anmeldebildschirm einen kurzen Hinweis, der an die genutzte Methode erinnert. Ergänzen Sie dann in den Kontoeinstellungen eine Option zum Verknüpfen weiterer Anmeldemethoden; so kann ein angemeldeter Nutzer seinen Apple Account mit dem bestehenden Profil verbinden.

Führen Sie Konten jedoch nicht automatisch zusammen, nur weil die E-Mail übereinstimmt. Hat der Nutzer eine Weiterleitungsadresse geteilt, gibt es ohnehin keine Übereinstimmung. Selbst bei einer echten Adresse kann automatisches Zusammenführen eine Sicherheitslücke öffnen. Verknüpfen Sie Konten deshalb immer mit der ausdrücklichen Zustimmung eines angemeldeten Nutzers.

Wie testen Sie den Sign in with Apple Ablauf?

App Review testet Ihre App möglicherweise auf einem echten Gerät mit einem eigenen Apple Account. Testen Sie daher durchgängig auf echter Hardware und nicht nur im Simulator. Prüfen Sie vor allem Erstregistrierung, Abmelden und erneutes Anmelden, verborgene E-Mail und Kontolöschung als getrennte Szenarien.

1. Registrieren Sie sich mit einem neuen Apple Testaccount und prüfen Sie, ob Name und E-Mail Ihren Server erreichen.
2. Melden Sie sich ab und mit demselben Konto wieder an; dabei darf kein neues Konto entstehen.
3. Nutzen Sie bei einer weiteren Registrierung die Option zum Verbergen der E-Mail und senden Sie eine Testnachricht an die Weiterleitungsadresse.
4. Entziehen Sie der App in den Geräteeinstellungen den Apple Zugriff und prüfen Sie, ob der Anmeldebildschirm erscheint.
5. Löschen Sie das Konto in der App und kontrollieren Sie, ob der Tokenwiderruf in Ihren Serverprotokollen auftaucht.

Bereiten Sie parallel die Android Version vor, gelten dort eigene Testregeln. Die Pflicht zum geschlossenen Test für neue private Konten erklären wir zum Beispiel im Beitrag Google Play: 12 Tester und 14 Tage geschlossener Test.

Prüfliste vor der erneuten Einreichung

Gehen Sie diese kurze Liste vor dem Einreichen gemeinsam im Team durch. Sie soll verhindern, dass Sie dieselbe Ablehnung nach 4.8 zweimal erhalten:

• Jeder Bildschirm mit Social Login zeigt auch Apples Option oder eine gleichwertige.
• Der Apple Button ist nicht kleiner als die anderen und ohne Scrollen sichtbar.
• Nach der Registrierung fragt die App weder Passwort noch persönliche E-Mail ab, Zusatzdaten sind freiwillig.
• Die Zustellung an eine Weiterleitungsadresse ist mit einem Testkonto bestätigt.
• Beim Löschen eines Kontos widerruft Ihr Server die Apple Tokens.
• Die Datenschutzangaben spiegeln den neuen Anmeldeablauf.
• In den Prüfnotizen stehen ein aktuelles Demokonto und eine kurze Beschreibung der Änderung.

Können Sie jeden Punkt mit Ja beantworten, senden Sie Ihre Antwort ab. Warten Sie dann das Ergebnis ab und gehen Sie neue Rückmeldungen genauso ruhig Punkt für Punkt an.

Wann lohnt sich professionelle Unterstützung?

In einer einfachen App dauert der Einbau von Apples Anmeldung vielleicht einige Tage. Kommen allerdings mehrere Plattformen, ein bestehender Nutzerstamm, Kontoverknüpfung und eine Mailinfrastruktur hinzu, wächst der Aufwand. Gerade einen neuen Anmeldeweg einzubauen, ohne bestehende Google Konten zu beschädigen, braucht sorgfältige Planung.

Bei solchen Ablehnungen bilden wir als Team zunächst gemeinsam mit Ihnen den Ablauf ab und entscheiden dann, welche Teile sich wirklich ändern müssen. Eine Freigabe garantieren wir nie, denn die Entscheidung trifft Apple. Wir können aber dafür sorgen, dass jedes Teil, das die Regel verlangt, sauber umgesetzt ist. Wenn Sie Anmeldeablauf, Kontolöschung und Prüfantwort gemeinsam angehen möchten, finden Sie auf unserer Seite zur Mobile App Entwicklung alle Wege, uns zu erreichen.