Czy Sign in with Apple jest obowiązkowe?
Nie wprost, ale przy logowaniu przez Google lub Facebooka jest najkrótszą drogą do zgodności. Wcześniejsze wersje wytycznej 4.8 wymieniały logowanie przez Apple z nazwy, dlatego wiele poradników nadal opisuje je jako obowiązkowe. Obecne brzmienie wymaga innej usługi logowania o trzech cechach, opisanych niżej. W komunikatach odrzucenia, które deweloperzy publikują na forum Apple, recenzenci dopisują jednak, że logowanie przez Apple spełnia wymogi wytycznej 4.8. Jeśli aplikacja ma już opcję, która według Ciebie spełnia te warunki, Apple w takim komunikacie prosi o odpowiedź w App Store Connect ze wskazaniem tej opcji i wyjaśnieniem, dlaczego je spełnia.
Co dokładnie mówi wytyczna 4.8
Wytyczna dotyczy aplikacji, które używają zewnętrznej usługi logowania, takiej jak logowanie przez Facebooka, Google, X, LinkedIn, Amazon albo WeChat, do założenia głównego konta użytkownika lub logowania do niego. Głównym kontem Apple nazywa konto, które użytkownik zakłada w aplikacji, żeby się identyfikować, logować i korzystać z jej funkcji i powiązanych usług. Takie aplikacje muszą zaoferować, jako równoważną opcję, inną usługę logowania, która spełnia trzy warunki:
- ogranicza zbieranie danych do imienia i adresu e-mail użytkownika,
- pozwala użytkownikowi zachować adres e-mail w tajemnicy przy zakładaniu konta,
- nie zbiera informacji o korzystaniu z Twojej aplikacji do celów reklamowych bez zgody.
Kiedy dodatkowa opcja nie jest potrzebna
- Aplikacja używa wyłącznie własnego systemu kont i logowania firmy.
- Aplikacja jest alternatywnym sklepem z aplikacjami albo jest z niego dystrybuowana i używa logowania tego sklepu.
- Aplikacja edukacyjna, firmowa albo biznesowa wymaga logowania istniejącym kontem szkolnym lub firmowym.
- Aplikacja uwierzytelnia użytkowników przez państwowy lub branżowy system identyfikacji obywateli albo elektroniczny dowód tożsamości.
- Aplikacja jest klientem konkretnej usługi zewnętrznej, a użytkownik musi zalogować się do swojej poczty, serwisu społecznościowego albo innego konta, żeby zobaczyć swoje treści.
Jak to wygląda w typowych sytuacjach
| Sytuacja | Czy potrzebna dodatkowa opcja? |
|---|---|
| Logowanie tylko e-mailem i hasłem we własnym systemie | Nie, to własny system kont firmy. |
| E-mail i hasło oraz przycisk „Zaloguj przez Google” | Tak, bo Google służy do założenia głównego konta. |
| Aplikacja dla pracowników logujących się istniejącym kontem firmowym | Nie, to jeden z wyjątków. |
| Logowanie przez Facebooka w aplikacji z rezerwacjami salonu | Tak. Dodatkowo logowanie nie może być jedyną drogą, jeśli aplikacja nie jest związana z tym serwisem. |
| Połączenie konta Google tylko po to, żeby zsynchronizować kalendarz | Zwykle nie, jeśli nie służy do logowania do głównego konta. Warto opisać to recenzentowi w notatkach. |
Druga zasada: logowanie przez serwis społecznościowy nie może być jedyne
Wytyczna 5.1.1(v) dodaje kilka reguł. Jeśli aplikacja nie ma istotnych funkcji opartych na koncie, ma działać bez logowania. Jeśli główna funkcja aplikacji nie jest związana z konkretnym serwisem społecznościowym, trzeba zapewnić dostęp bez logowania przez ten serwis albo w inny sposób. Pobranie podstawowych danych profilu, udostępnianie i zapraszanie znajomych nie są uznawane za główną funkcję. Aplikacja musi też pozwalać odłączyć konto serwisu społecznościowego i nie może przechowywać danych logowania ani tokenów tego serwisu poza urządzeniem.
Logowanie przez Apple: o czym pamiętać
- Użytkownik może udostępnić losowy, unikalny adres e-mail, z którego wiadomości trafiają na jego prywatną skrzynkę. System kont musi taki adres przyjąć i wysyłać na niego wiadomości. Apple zapowiedziało nową domenę tych adresów, o czym piszemy we wpisie wymagania Google Play i App Store do kwietnia 2027.
- Logowanie przez Apple można dodać w każdej wersji aplikacji i strony, także poza urządzeniami Apple. Dzięki temu klient z iPhone'a zaloguje się tym samym kontem na Androidzie albo w przeglądarce.
- Apple zaleca łączenie kont: jeśli adres z logowania przez Apple pasuje do istniejącego konta, zaproponuj ich połączenie zamiast tworzyć duplikat.
- Przy usuwaniu konta aplikacja powinna odwołać tokeny użytkownika przez REST API Sign in with Apple.
- Apple radzi prosić o logowanie dopiero wtedy, gdy daje ono coś użytkownikowi, a w sklepie pozwolić najpierw kupić jako gość.
Co zrobić krok po kroku
- Spisz metody logowania w aplikacji na iOS i sprawdź, czy któraś to zewnętrzna usługa używana do głównego konta.
- Sprawdź, czy aplikacja mieści się w jednym z wyjątków. Jeśli tak, opisz to krótko w notatkach dla recenzenta.
- Jeśli nie, dodaj opcję spełniającą trzy warunki z wytycznej 4.8, na przykład logowanie przez Apple, na tym samym ekranie i w tej samej randze co pozostałe.
- Na serwerze dodaj obsługę identyfikatora użytkownika z nowej metody, adresów przekazujących wiadomości i łączenia kont.
- Zdecyduj, czy ta sama metoda ma działać na Androidzie i w wersji webowej, żeby klient miał jedno konto na wszystkich urządzeniach.
- Dodaj odwołanie tokenów do procesu usuwania konta.
- Przetestuj: nowe konto każdą metodą, logowanie na drugim urządzeniu, łączenie z istniejącym kontem i usunięcie konta.
- Zaktualizuj politykę prywatności i informacje o prywatności w App Store Connect.
Najczęstsze błędy
- Schowanie dodatkowej opcji pod przyciskiem „Więcej sposobów logowania”. Wytyczna mówi o opcji równoważnej, a schowanej trudno tak nazwać.
- Prośba o numer telefonu i adres zaraz po logowaniu przez Apple, choć aplikacja ich nie potrzebuje. Apple radzi nie opóźniać startu pytaniami o zbędne dane.
- Blokowanie adresów przekazujących wiadomości jako „podejrzanych”.
- Wymuszanie logowania na pierwszym ekranie, zanim użytkownik zobaczy, co aplikacja robi.
- Brak łączenia kont, przez co jeden klient ma dwa konta i dwie historie zamówień.
Jak możemy pomóc
Ekran logowania łatwo zmienić na etapie projektu, a trudniej po publikacji, gdy klienci mają już konta. Możemy przejrzeć Twoje logowanie pod kątem wytycznych 4.8 i 5.1.1(v) i zaplanować zmianę razem z łączeniem kont. Ekrany logowania i rejestracji projektujemy w ramach projektowania aplikacji mobilnych. O tym, jak konta i dane użytkowników mogą działać po stronie serwera, piszemy w porównaniu Supabase czy Firebase.
Źródła
Autor: Marcin Tyc, założyciel Tycode · opublikowano 24 października 2026 · aktualizacja 24 października 2026