Guideline 4.8: Ist „Sign in with Apple“ Pflicht?

Die Guideline 4.8 greift, sobald deine App Google, Facebook oder einen anderen Drittanbieter-Login nutzt, um das Hauptkonto anzulegen. Dann verlangt sie eine weitere, gleichwertige Login-Option. Diese beschränkt die Daten auf Name und E-Mail, erlaubt es, die E-Mail zu verbergen, und trackt den Nutzer ohne seine Zustimmung nicht für Werbung. Seit Januar 2024 muss diese Option nicht mehr zwingend „Sign in with Apple“ sein. Aber genau diese nennt Apple selbst in seinen Ablehnungen.

Bei meinen Apps bieten Solys und Nolera Apple, Google und E-Mail an. Dieser Guide geht vom aktuellen Text von Apple aus. Dann zeige ich, wie ich den Apple-Login in eine Expo-App mit Supabase einbaue und was er für die Kontolöschung ändert. Für den Überblick über alle Ablehnungsgründe lies lieber warum Apple eine App ablehnt.

Was sagt die Guideline 4.8 Login Services?

Die 4.8 steht in Abschnitt 4, „Design“, der App Review Guidelines. Sie betrifft Apps, die „a third-party or social login service“ nutzen, um das Hauptkonto anzulegen oder zu authentifizieren: Facebook Login, Google Sign-In, Log in with X, LinkedIn, Amazon oder WeChat. Diese Apps müssen zusätzlich, „as an equivalent option“, einen weiteren Login-Dienst anbieten, der drei Bedingungen erfüllt.

Apples Bedingung	Im Klartext
Begrenzte Daten	Name und E-Mail, sonst nichts
Private E-Mail möglich	Der Nutzer kann sie verbergen
Keine Werbung ohne Zustimmung	Kein Werbetracking ohne Zustimmung

Der Text definiert auch das Hauptkonto: das Konto, das jemand in deiner App anlegt, um sich zu identifizieren, sich anzumelden und deine Funktionen zu nutzen. Nach dieser Definition legt ein Google-Button, der nur zum Importieren einer Datei dient, kein Hauptkonto an. Die 4.8 zielt auf den Bildschirm, über den man in deine App reinkommt.

Was sich im Januar 2024 geändert hat

Vor 2024 schrieb die Regel „Sign in with Apple“ für Apps vor, die einen Drittanbieter-Login für das Hauptkonto nutzten. Am 25. Januar 2024 hat Apple das gelockert: Du kannst den Apple-Login anbieten oder einen gleichwertigen Dienst, der die Privatsphäre schützt. Viele Seiten behaupten noch das Gegenteil. Die Expo-Dokumentation schreibt immer noch, dass eine App mit Drittanbieter-Login Apple anbieten muss.

In der Praxis endet die 4.8-Ablehnung, die in den Apple-Entwicklerforen veröffentlicht wurde, so: „Note that Sign in with Apple meets the requirements specified in guideline 4.8“. Apple nennt keinen anderen konformen Dienst. Um beim Reviewer kein Ratespiel zu spielen, baue ich den Apple-Login ein.

Die fünf Ausnahmen im Text

Apple nennt fünf Fälle, in denen kein weiterer Login verlangt wird:

1. Deine App nutzt nur dein eigenes Kontosystem, zum Beispiel E-Mail mit Passwort oder einen per E-Mail geschickten Code.
2. Deine App ist ein alternativer App-Marktplatz oder wird über einen vertrieben, mit einem eigenen Login dieses Marktplatzes.
3. Deine App ist eine Bildungs-, Unternehmens- oder Business-App und verlangt ein bestehendes Schul- oder Firmenkonto.
4. Deine App nutzt ein staatlich oder branchenweit gestütztes elektronisches Identitätssystem.
5. Deine App ist der Client eines bestimmten Drittanbieterdienstes: Die Person meldet sich bei ihrem Mail-Dienst oder sozialen Netzwerk an, um auf ihre eigenen Inhalte zuzugreifen.

Noch vor diesen Ausnahmen solltest du dir eine Frage stellen: Braucht deine App überhaupt ein Konto? Wenn nicht, verlangt die Guideline 5.1.1(v), dass sie ohne Login nutzbar ist, wie ich im Guide zur Guideline 5.1.1 erkläre.

Dein Login-Bildschirm	Greift die 4.8?
Kein Konto	Nein
Nur E-Mail oder Code	Nein
Nur Google	Ja
Google und E-Mail	Ja, vermutlich
Google und Apple	Ja, und konform
Bestehendes Schulkonto	Nein
Google für einen Import	Nein, kein Konto

„Sign in with Apple“ in eine Expo-App einbauen

1. Modul installieren und Capability deklarieren

npx expo install expo-apple-authentication

Laut Expo-Dokumentation aktivierst du danach die Capability in der App-Konfiguration:

{
  "expo": {
    "ios": {
      "usesAppleSignIn": true,
      "infoPlist": { "CFBundleAllowMixedLocalizations": true }
    }
  }
}

Die zweite Zeile zeigt den Button in der Sprache des iPhones an. Mit EAS Build wird die Capability beim Build auf deiner App-ID aktiviert. Das ist eine native Einstellung: Sie kommt mit einem neuen Build, nie mit einem Remote-Update.

Eine Falle, die ich beim Durchsehen des Starter Code meiner Kits gefunden habe: Diese Capability erfordert eine Signatur, sogar um die App im Simulator zu starten. Auf einem Mac ohne „Apple Development“-Zertifikat schlug der lokale Build mit „No code signing certificates are available to use“ fehl. Die Lösung: den Apple-Login erst aktivieren, wenn der Auth-Server konfiguriert ist.

2. Den offiziellen Button zeigen, genauso sichtbar wie Google

Die Design-Regeln von Apple sind eindeutig: Der Apple-Button darf nicht kleiner sein als die anderen Login-Buttons, und man darf nicht scrollen müssen, um ihn zu sehen. Die Expo-Komponente zeichnet den offiziellen Button mit einem von Apple erlaubten Titel.

import * as AppleAuthentication from "expo-apple-authentication";
import { useEffect, useState } from "react";

export function BoutonApple({ onPress }: { onPress: () => void }) {
  const [disponible, setDisponible] = useState(false);

  useEffect(() => {
    AppleAuthentication.isAvailableAsync().then(setDisponible);
  }, []);

  // Android und Web: kein Apple-Login, kein Button.
  if (!disponible) return null;

  return (
    <AppleAuthentication.AppleAuthenticationButton
      buttonType={AppleAuthentication.AppleAuthenticationButtonType.CONTINUE}
      buttonStyle={AppleAuthentication.AppleAuthenticationButtonStyle.BLACK}
      cornerRadius={12}
      style={{ width: "100%", height: 50 }}
      onPress={onPress}
    />
  );
}

Expo weist darauf hin, dass der Button ohne Breite und Höhe nicht erscheint. Farbe und Eckenradius laufen über buttonStyle und cornerRadius, nicht über den Style.

3. Die Session in Supabase öffnen

import * as AppleAuthentication from "expo-apple-authentication";
import { supabase } from "./supabase";

export async function connexionApple(): Promise<"ok" | "annule"> {
  try {
    const credential = await AppleAuthentication.signInAsync({
      requestedScopes: [
        AppleAuthentication.AppleAuthenticationScope.FULL_NAME,
        AppleAuthentication.AppleAuthenticationScope.EMAIL,
      ],
    });
    if (!credential.identityToken) throw new Error("Apple-Token fehlt");
    const { error } = await supabase.auth.signInWithIdToken({
      provider: "apple",
      token: credential.identityToken,
    });
    if (error) throw error;
    // Der Vorname kommt nur bei der ersten Autorisierung: sofort speichern.
    const prenom = credential.fullName?.givenName;
    if (prenom) await supabase.auth.updateUser({ data: { prenom } });
    return "ok";
  } catch (e) {
    if ((e as { code?: string }).code === "ERR_REQUEST_CANCELED")
      return "annule";
    throw e;
  }
}

Vier Details zählen, aus der Supabase-Dokumentation, der von Expo und den Design-Regeln von Apple:

• Trag in Supabase deine Bundle-ID in die Client IDs des Apple-Providers ein. Eine rein native App braucht für den Login keinen Secret Key. Füge host.exp.Exponent hinzu, wenn du in Expo Go testest.
• Vorname und E-Mail kommen nur einmal. Apple schickt sie bei späteren Logins nicht mehr: Speichere sie gleich bei der ersten Antwort.
• Die E-Mail kann eine Relay-Adresse sein. Apple empfiehlt, danach nicht noch einmal nach einer privaten Adresse zu fragen.
• Ein Abbruch ist kein Fehler. Bei Nolera löst das Schließen des Apple-Sheets keine rote Meldung aus: Das ist eine bewusste Aktion.

Ein echter Fall bei Solys, im August 2026: Die Buttons für Apple und Google waren in der App, aber keiner der beiden Provider war in Supabase aktiviert. Der Code war korrekt, die Korrektur passierte serverseitig, ohne neuen Build. Ein Apple-Button, der vor dem Reviewer scheitert, bringt dir eine 2.1-Ablehnung statt einer 4.8-Ablehnung. Details im Guide zur Guideline 2.1.

4. Auf einem echten iPhone testen

Expo warnt, dass der Simulator nur eingeschränkt testen kann und dass die in Expo Go erhaltenen Kennungen sich von denen der veröffentlichten App unterscheiden. Teste Login, Logout und erneuten Login auf einem echten iPhone, mit einem TestFlight-Build.

Apple-Login und Kontolöschung

Die Guideline 5.1.1(v) verlangt, dass ein in der App angelegtes Konto auch in der App gelöscht werden kann. Beim Apple-Login fügt Apples Seite zur Kontolöschung einen Schritt hinzu: Über die REST-API von Sign in with Apple die Tokens der Person widerrufen.

Dieser Widerruf braucht zwei Dinge: ein Token der Person, das man durch Validieren eines Autorisierungscodes bekommt, und ein Secret, das mit deinem privaten Sign-in-with-Apple-Schlüssel signiert ist. Auch wenn der native Login ohne Secret Key auskommt, braucht der Widerruf einen, und der bleibt auf deinem Server. Das Warum steht in geheimer API-Schlüssel in einer Expo-App.

Bei Nolera fragt die App beim Löschen des Kontos erneut nach einem Apple-Login, um einen frischen Autorisierungscode zu bekommen. Sie schickt ihn an eine Serverfunktion, die ihn bei Apple eintauscht und dann das Token widerruft. Bricht die Person ab, sagt eine klare Meldung das, und nichts wird gelöscht. Der Rest des Ablaufs, inklusive Daten, Abo und Tests, steht in Kontolöschung unter iOS.

Was du Apple nach einer 4.8-Ablehnung antwortest

Apples Nachricht bietet zwei Auswege. Entweder du fügst eine gleichwertige Option hinzu. Oder deine App hat schon eine: Dann antwortest du in App Store Connect und sagst, welche es ist und warum sie die drei Bedingungen erfüllt. Apple schlägt auch vor, die Screenshots zu aktualisieren, die den Login-Bildschirm zeigen. Das Vorgehen, um App Review zu antworten, ist dasselbe wie bei den anderen Regeln.

Hier eine Vorlage auf Englisch zum Anpassen (ersetze die Build-Nummer):

Hello,

Thank you for your review.

Build X adds Sign in with Apple as an equivalent login option.
It appears on the same screen as Google Sign-In, with the same
size, and is visible without scrolling.

How to verify: launch the app, open the sign-in screen and
tap "Continue with Apple".

We also updated the screenshots that show the sign-in screen.

Best regards,

Die 4.8-Checkliste vor dem Einreichen

• Du weißt, ob deine App ein Konto braucht. Wenn nicht, funktioniert sie ohne Login.
• Wenn Google, Facebook oder X das Konto anlegen, ist der Apple-Login auf demselben Bildschirm.
• Der Apple-Button ist der offizielle Button, genauso groß wie die anderen, sichtbar ohne Scrollen.
• Der Apple-Provider ist serverseitig aktiviert, mit deiner Bundle-ID.
• Ein Abbruch führt zurück zum Login-Bildschirm, ohne Fehlermeldung.
• Vorname und E-Mail werden gleich beim ersten Login gespeichert.
• Die Kontolöschung widerruft das Apple-Token, von deinem Server aus.
• Alles ist auf einem echten iPhone getestet, mit einem Apple-Account, der sich noch nie bei der App angemeldet hat.
• Deine Screenshots zeigen den Login-Bildschirm so, wie er im eingereichten Build ist.

Deine Ablehnung beheben, bevor du die App neu einreichst

Wenn deine App gerade wegen 4.8 abgelehnt wurde, bündelt das Apple Review Kit, was ich vor jeder Einreichung prüfe, mit zwei Skills, die dein Projekt in Claude Code durchgehen und deine Antwort vorbereiten, falls Apple ablehnt. Für einen menschlichen Blick buch eine Stunde mit mir: Wir lesen die Nachricht zusammen und schauen uns deinen Login-Bildschirm an. Das komplette Vorgehen nach einer Ablehnung steht auf der Seite App von Apple abgelehnt.

Wenn du deinen ersten Release vorbereitest, mach deine kostenlose Diagnose: Sie sagt dir, welchen Schritt du zuerst angehen solltest, und schickt dir meine Checkliste gegen Apple-Ablehnungen.

Niemand kann garantieren, dass Apple deine App annimmt. Den Apple-Login an der richtigen Stelle einzubauen, streicht aber zumindest diesen Grund von der Liste.

Häufige Fragen

Ist der Login mit Apple unter iOS Pflicht?

Nein, nicht in jedem Fall. Er wird nur verlangt, wenn deine App einen Drittanbieter-Login wie Google oder Facebook anbietet, um das Hauptkonto anzulegen. Seit Januar 2024 kann ein anderer gleichwertiger Dienst ihn ersetzen, aber Apple nennt nur den Apple-Login als konform.

Was bedeutet „Guideline 4.8 - Design - Login Services“?

Das ist der Titel der Ablehnung in Apples Nachricht. Er bedeutet, dass deine App einen Drittanbieter-Login anbietet, ohne eine gleichwertige Option, die die Daten auf Name und E-Mail beschränkt, das Verbergen der E-Mail erlaubt und ohne Zustimmung nicht für Werbung genutzt wird.

Reicht meine E-Mail-Registrierung neben Google?

Das ist nicht garantiert. Der Text verlangt einen Dienst, mit dem man seine E-Mail privat halten kann, während ein klassisches Formular sie abfragt. Apple hat zu diesem Fall keine Position veröffentlicht, und seine Ablehnung nennt nur den Apple-Login. Ich würde dieses Risiko nicht eingehen.

Muss ich den Apple-Login auch unter Android anbieten?

Nein. Die 4.8 ist eine App-Store-Regel, und das Expo-Modul funktioniert nur unter iOS. Unter Android gibt isAvailableAsync() false zurück: Der Apple-Button wird nicht angezeigt, und Google kann allein bleiben.

Brauche ich nach einer 4.8-Ablehnung einen neuen Build?

Ja, in den meisten Fällen. Der Apple-Login braucht eine native Capability, die beim Build aktiviert wird. Ein Remote-Update kann sie nicht hinzufügen. Einzige Ausnahme: Deine App hatte schon eine konforme Option, und es reicht, das Apple in deiner Antwort zu erklären.