Guideline 4.8: czy Sign in with Apple jest wymagane?

Guideline 4.8 obowiązuje, gdy twoja aplikacja używa Google, Facebooka albo innego zewnętrznego logowania do tworzenia głównego konta. Wymaga wtedy drugiej, równoważnej opcji logowania, która ogranicza dane do imienia i e-maila, pozwala ukryć e-mail i nie śledzi użytkownika w celach reklamowych bez jego zgody. Od stycznia 2024 ta opcja nie musi już być „Sign in with Apple”, ale to właśnie ją Apple sam wymienia w wiadomościach o odrzuceniu.

W moich aplikacjach Solys i Nolera oferują Apple, Google i e-mail. Ten poradnik wychodzi od aktualnego tekstu Apple, potem pokazuje, jak dodaję logowanie Apple w aplikacji Expo połączonej z Supabase i co to zmienia przy usuwaniu konta. Jeśli chcesz ogólny przegląd powodów odrzucenia, przeczytaj raczej dlaczego Apple odrzuca aplikację.

Co mówi guideline 4.8 Login Services?

4.8 jest w sekcji 4, „Design”, App Review Guidelines. Dotyczy aplikacji, które używają „a third-party or social login service” do tworzenia lub uwierzytelniania głównego konta: Facebook Login, Google Sign-In, Log in with X, LinkedIn, Amazon czy WeChat. Takie aplikacje muszą też oferować, „as an equivalent option”, inną usługę logowania, która spełnia trzy warunki.

Warunek Apple	Po ludzku
Ograniczone dane	Imię i e-mail, nic więcej
Możliwy prywatny e-mail	Użytkownik może go ukryć
Brak reklam bez zgody	Żadnego śledzenia reklamowego bez zgody

Tekst definiuje też główne konto: to konto, które ktoś zakłada w twojej aplikacji, żeby się identyfikować, logować i mieć dostęp do jej funkcji. Zgodnie z tą definicją przycisk Google, który służy tylko do importu pliku, nie tworzy głównego konta. 4.8 dotyczy ekranu, przez który wchodzi się do aplikacji.

Co zmieniło się w styczniu 2024

Przed 2024 rokiem reguła nakazywała „Sign in with Apple” aplikacjom, które używały zewnętrznego logowania do głównego konta. 25 stycznia 2024 Apple złagodził ten punkt: możesz zaoferować logowanie Apple albo równoważną usługę chroniącą prywatność. Wiele stron wciąż twierdzi inaczej. Dokumentacja Expo nadal pisze, że aplikacja z zewnętrznym logowaniem musi oferować Apple.

W praktyce wiadomość o odrzuceniu 4.8 opublikowana na forach deweloperów Apple kończy się tak: „Note that Sign in with Apple meets the requirements specified in guideline 4.8”. Apple nie wymienia żadnej innej zgodnej usługi. Żeby nie bawić się z recenzentem w zgadywanki, dodaję logowanie Apple.

Pięć wyjątków przewidzianych w tekście

Apple wymienia pięć przypadków, w których inne logowanie nie jest wymagane:

1. Twoja aplikacja używa wyłącznie własnego systemu kont, na przykład e-maila z hasłem albo kodu wysyłanego e-mailem.
2. Twoja aplikacja to alternatywny sklep z aplikacjami albo jest przez taki sklep dystrybuowana, z logowaniem specyficznym dla tego sklepu.
3. Twoja aplikacja jest edukacyjna, firmowa lub profesjonalna i wymaga istniejącego konta szkolnego lub firmowego.
4. Twoja aplikacja używa systemu identyfikacji elektronicznej wspieranego przez państwo lub branżę.
5. Twoja aplikacja jest klientem konkretnej usługi zewnętrznej: użytkownik loguje się do swojej poczty lub sieci społecznościowej, żeby mieć dostęp do własnych treści.

Zanim w ogóle sięgniesz po te wyjątki, zadaj sobie pytanie: czy twoja aplikacja potrzebuje konta? Jeśli nie, guideline 5.1.1(v) wymaga, żeby dało się jej używać bez logowania, jak wyjaśniam w poradniku o guideline 5.1.1.

Twój ekran logowania	Czy 4.8 obowiązuje?
Brak konta	Nie
Tylko e-mail lub kod	Nie
Tylko Google	Tak
Google i e-mail	Raczej tak
Google i Apple	Tak, i jest zgodnie
Istniejące konto szkolne	Nie
Google do importu	Nie, brak konta

Dodanie „Sign in with Apple” w aplikacji Expo

1. Zainstaluj moduł i zadeklaruj capability

npx expo install expo-apple-authentication

Dokumentacja Expo każe potem włączyć capability w konfiguracji aplikacji:

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

Druga linia sprawia, że przycisk wyświetla się w języku iPhone'a. Z EAS Build capability zostaje włączona dla identyfikatora twojej aplikacji w momencie builda. To ustawienie natywne: trafia do aplikacji z nowym buildem, nigdy przez zdalną aktualizację.

Pułapka, na którą trafiłem, przeglądając kod startowy moich kitów: ta capability wymaga podpisu, nawet do uruchomienia aplikacji w symulatorze. Na Macu bez certyfikatu „Apple Development” lokalna kompilacja kończyła się błędem „No code signing certificates are available to use”. Rozwiązanie: włączać logowanie Apple dopiero wtedy, gdy serwer uwierzytelniania jest skonfigurowany.

2. Pokaż oficjalny przycisk, tak samo widoczny jak Google

Zasady projektowania Apple są jasne: przycisk Apple nie może być mniejszy niż inne przyciski logowania i nie może wymagać przewijania ekranu, żeby go zobaczyć. Komponent Expo rysuje oficjalny przycisk z tytułem zatwierdzonym przez Apple.

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 i web: brak logowania Apple, brak przycisku.
  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 zaznacza, że przycisk nie pojawi się bez szerokości i wysokości. Kolor i zaokrąglenie ustawiasz przez buttonStyle i cornerRadius, a nie przez style.

3. Otwórz sesję w Supabase

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("Brak tokenu Apple");
    const { error } = await supabase.auth.signInWithIdToken({
      provider: "apple",
      token: credential.identityToken,
    });
    if (error) throw error;
    // Imię przychodzi tylko przy pierwszej autoryzacji: zapisujemy je od razu.
    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;
  }
}

Liczą się cztery szczegóły, wzięte z dokumentacji Supabase, dokumentacji Expo i zasad projektowania Apple:

• W Supabase zadeklaruj swój bundle identifier w Client IDs dostawcy Apple. Aplikacja wyłącznie natywna nie potrzebuje tajnego klucza do logowania. Dodaj host.exp.Exponent, jeśli testujesz w Expo Go.
• Imię i e-mail przychodzą tylko raz. Apple nie odsyła ich przy kolejnych logowaniach: zapisz je od razu przy pierwszej odpowiedzi.
• E-mail może być adresem przekaźnikowym. Apple zaleca, żeby potem nie prosić ponownie o prywatny adres.
• Anulowanie to nie błąd. W Nolerze zamknięcie arkusza Apple nie wywołuje żadnego czerwonego komunikatu: to świadoma decyzja.

Przypadek z Solys, sierpień 2026: przyciski Apple i Google były w aplikacji, ale żaden z dostawców nie był włączony w Supabase. Kod był dobry, poprawka poszła po stronie serwera, bez nowego builda. Przycisk Apple, który nie działa przy recenzencie, to odrzucenie 2.1 zamiast odrzucenia 4.8. Szczegóły znajdziesz w poradniku o guideline 2.1.

4. Testuj na prawdziwym iPhonie

Expo ostrzega, że symulator pozwala tylko na ograniczony test, a identyfikatory otrzymane w Expo Go różnią się od tych z opublikowanej aplikacji. Przetestuj logowanie, wylogowanie i ponowne logowanie na prawdziwym iPhonie, z buildem TestFlight.

Logowanie Apple a usuwanie konta

Guideline 5.1.1(v) wymaga, żeby konto utworzone w aplikacji dało się z niej usunąć. Przy logowaniu Apple strona Apple o usuwaniu konta dodaje krok: użyj REST API Sign in with Apple, żeby unieważnić tokeny danej osoby.

To unieważnienie wymaga dwóch rzeczy: tokenu użytkownika, który dostajesz, walidując kod autoryzacji, oraz sekretu podpisanego twoim kluczem prywatnym Sign in with Apple. Nawet jeśli natywne logowanie obywa się bez tajnego klucza, unieważnienie go wymaga, i ten klucz zostaje na twoim serwerze. Dlaczego, wyjaśniam w tajny klucz API w aplikacji Expo.

W Nolerze przy usuwaniu konta aplikacja prosi ponownie o logowanie Apple, żeby dostać świeży kod autoryzacji. Wysyła go do funkcji serwerowej, która wymienia go w Apple, a potem unieważnia token. Jeśli użytkownik anuluje, jasny komunikat o tym informuje i nic nie zostaje usunięte. Resztę procesu, łącznie z danymi, subskrypcją i testami, opisuję w usuwanie konta w iOS.

Co odpowiedzieć Apple po odrzuceniu 4.8

Wiadomość Apple daje dwa wyjścia. Albo dodajesz równoważną opcję. Albo twoja aplikacja już ją ma: odpowiadasz w App Store Connect, mówisz, która to opcja i dlaczego spełnia trzy warunki. Apple sugeruje też zaktualizowanie zrzutów ekranu pokazujących ekran logowania. Procedura odpowiadania App Review jest taka sama jak przy innych regułach.

Oto szablon po angielsku do dostosowania (podmień numer builda):

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,

Checklista 4.8 przed wysłaniem

• Wiesz, czy twoja aplikacja potrzebuje konta. Jeśli nie, działa bez logowania.
• Jeśli Google, Facebook albo X tworzą konto, logowanie Apple jest na tym samym ekranie.
• Przycisk Apple to oficjalny przycisk, tak duży jak pozostałe, widoczny bez przewijania.
• Dostawca Apple jest włączony po stronie serwera, z twoim bundle identifierem.
• Anulowanie wraca do ekranu logowania, bez komunikatu o błędzie.
• Imię i e-mail są zapisywane przy pierwszym logowaniu.
• Usuwanie konta unieważnia token Apple, z twojego serwera.
• Wszystko jest przetestowane na prawdziwym iPhonie, z kontem Apple, które nigdy nie logowało się do aplikacji.
• Twoje zrzuty ekranu pokazują ekran logowania dokładnie taki, jaki jest w wysłanym buildzie.

Napraw odrzucenie, zanim wyślesz aplikację ponownie

Jeśli twoja aplikacja właśnie została odrzucona z powodu 4.8, Apple Review Kit zbiera to, co sprawdzam przed każdym wysłaniem, z dwoma skillami, które przeglądają twój projekt w Claude Code i przygotowują odpowiedź, jeśli Apple odrzuci aplikację. Jeśli chcesz, żeby spojrzał na to człowiek, zarezerwuj godzinę ze mną: razem przeczytamy wiadomość i obejrzymy twój ekran logowania. Pełne postępowanie po odrzuceniu opisuję na stronie aplikacja odrzucona przez Apple.

Jeśli przygotowujesz swoją pierwszą publikację, zrób darmową diagnozę: powie ci, od którego etapu zacząć, i wyśle ci moją checklistę przeciw odrzuceniom Apple.

Nikt nie zagwarantuje, że Apple zaakceptuje twoją aplikację. Dodanie logowania Apple we właściwym miejscu przynajmniej skreśla ten powód z listy.

Najczęściej zadawane pytania

Czy logowanie przez Apple jest obowiązkowe w iOS?

Nie, nie zawsze. Jest wymagane tylko wtedy, gdy twoja aplikacja oferuje zewnętrzne logowanie, np. Google lub Facebook, do tworzenia głównego konta. Od stycznia 2024 może je zastąpić inna równoważna usługa, ale Apple jako zgodne wymienia tylko logowanie Apple.

Co oznacza „Guideline 4.8 - Design - Login Services”?

To tytuł odrzucenia w wiadomości od Apple. Oznacza, że twoja aplikacja oferuje zewnętrzne logowanie bez równoważnej opcji, która ogranicza dane do imienia i e-maila, pozwala ukryć e-mail i nie służy do reklam bez zgody.

Czy rejestracja przez e-mail obok Google wystarczy?

Nie ma gwarancji. Tekst wymaga usługi, która pozwala zachować prywatność e-maila, a zwykły formularz o niego prosi. Apple nie zajął stanowiska w tej sprawie, a jego wiadomość o odrzuceniu wymienia tylko logowanie Apple. Ja bym nie ryzykował.

Czy trzeba oferować logowanie Apple na Androidzie?

Nie. 4.8 to reguła App Store, a moduł Expo działa tylko w iOS. Na Androidzie isAvailableAsync() zwraca false: przycisk Apple się nie wyświetla, a Google może zostać jedyną opcją.

Czy po odrzuceniu 4.8 potrzebny jest nowy build?

Tak, w większości przypadków. Logowanie Apple wymaga natywnej capability, włączanej w momencie builda. Zdalna aktualizacja nie może jej dodać. Jedyny wyjątek: twoja aplikacja miała już zgodną opcję i wystarczy wyjaśnić to Apple w odpowiedzi.