Guideline 4.8 Login Services: чи потрібен Sign in with Apple

Guideline 4.8 застосовується, щойно твій застосунок використовує Google, Facebook чи інший сторонній вхід для створення основного акаунта. Тоді вона вимагає ще один, рівноцінний варіант входу, який обмежує дані іменем і e-mail, дає змогу приховати свій e-mail і не відстежує користувача для реклами без його згоди. Із січня 2024 року цим варіантом не обов'язково має бути «Sign in with Apple», але саме його Apple сам згадує у своїх повідомленнях про відмову.

У моїх застосунках Solys і Nolera пропонують вхід через Apple, Google і e-mail. Цей гайд спирається на чинний текст Apple, а далі показує, як я додаю вхід через Apple у застосунок на Expo, підключений до Supabase, і що це змінює для видалення акаунта. Якщо потрібна загальна картина причин відмов, краще почитай, чому Apple відхиляє застосунок.

Що каже guideline 4.8 Login Services?

Правило 4.8 є в розділі 4, «Design», документа App Review Guidelines. Воно стосується застосунків, які використовують «a third-party or social login service», щоб створити або автентифікувати основний акаунт: Facebook Login, Google Sign-In, Log in with X, LinkedIn, Amazon чи WeChat. Такі застосунки мають також пропонувати, «as an equivalent option», інший сервіс входу, що відповідає трьом умовам.

Умова Apple	Простими словами
Обмежені дані	Ім'я та e-mail, нічого більше
Можливість приватного e-mail	Користувач може його приховати
Без реклами без згоди	Жодного рекламного стеження без згоди

Текст також визначає основний акаунт: це той, який людина створює у твоєму застосунку, щоб ідентифікуватися, входити й отримувати доступ до функцій. За цим визначенням, кнопка Google, яка служить лише для імпорту файлу, не створює основного акаунта. Правило 4.8 стосується екрана, через який заходять у твій застосунок.

Що змінилося в січні 2024 року

До 2024 року правило вимагало «Sign in with Apple» від застосунків, які використовували сторонній вхід для основного акаунта. 25 січня 2024 року Apple пом'якшив цю вимогу: можна запропонувати вхід через Apple або рівноцінний сервіс, що захищає приватність. Багато сторінок досі стверджують протилежне. Документація Expo і далі пише, що застосунок зі стороннім входом мусить пропонувати Apple.

На практиці повідомлення про відмову 4.8, опубліковане на форумах розробників Apple, закінчується так: «Note that Sign in with Apple meets the requirements specified in guideline 4.8». Жодного іншого відповідного сервісу Apple не називає. Щоб не грати з рев'юером у вгадайку, я додаю вхід через Apple.

П'ять винятків, передбачених текстом

Apple перелічує п'ять випадків, коли інший вхід не потрібен:

1. Твій застосунок використовує лише власну систему акаунтів, наприклад e-mail із паролем або код, надісланий на e-mail.
2. Твій застосунок є альтернативним магазином застосунків або поширюється через такий магазин, із власним входом цього магазину.
3. Твій застосунок освітній, корпоративний чи професійний і вимагає наявного шкільного або корпоративного акаунта.
4. Твій застосунок використовує систему електронної ідентифікації, яку підтримує держава чи галузь.
5. Твій застосунок є клієнтом конкретного стороннього сервісу: людина входить у свою пошту чи соцмережу, щоб отримати доступ до власного контенту.

Ще до цих винятків постав собі запитання: чи потрібен твоєму застосунку акаунт узагалі? Якщо ні, guideline 5.1.1(v) вимагає, щоб ним можна було користуватися без входу, як я пояснюю в гайді з guideline 5.1.1.

Твій екран входу	Чи діє 4.8?
Без акаунта	Ні
Лише e-mail або код	Ні
Лише Google	Так
Google і e-mail	Імовірно, так
Google і Apple	Так, і все відповідає
Наявний шкільний акаунт	Ні
Google для імпорту	Ні, акаунта немає

Як додати «Sign in with Apple» у застосунок на Expo

1. Встановити модуль і оголосити capability

npx expo install expo-apple-authentication

Далі документація Expo просить увімкнути capability в конфігурації застосунку:

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

Другий рядок показує кнопку мовою iPhone. З EAS Build capability вмикається для ідентифікатора твого застосунку під час збірки. Це нативне налаштування: воно потрапляє в застосунок лише з новим білдом, ніколи через віддалене оновлення.

Пастка, яку я знайшов, перечитуючи стартовий код своїх кітів: ця capability вимагає підпису навіть для запуску в симуляторі. На Mac без сертифіката «Apple Development» локальна компіляція падала з помилкою «No code signing certificates are available to use». Рішення: вмикати вхід через Apple лише тоді, коли налаштовано сервер автентифікації.

2. Показати офіційну кнопку, так само помітну, як Google

Правила дизайну Apple чіткі: кнопка Apple не має бути меншою за інші кнопки входу, і щоб її побачити, не повинно бути потреби гортати екран. Компонент Expo малює офіційну кнопку з дозволеним 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 і веб: немає входу через Apple, немає кнопки.
  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 уточнює, що без ширини й висоти кнопка не з'являється. Колір і заокруглення задаються через buttonStyle і cornerRadius, а не через style.

3. Відкрити сесію в 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("Немає токена Apple");
    const { error } = await supabase.auth.signInWithIdToken({
      provider: "apple",
      token: credential.identityToken,
    });
    if (error) throw error;
    // Ім'я приходить лише під час першої авторизації: зберігаємо його одразу.
    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;
  }
}

Важливі чотири деталі, взяті з документації Supabase, документації Expo та правил дизайну Apple:

• У Supabase вкажи свій bundle identifier у Client IDs провайдера Apple. Суто нативному застосунку для входу не потрібен секретний ключ. Додай host.exp.Exponent, якщо тестуєш в Expo Go.
• Ім'я та e-mail приходять лише один раз. Під час наступних входів Apple їх більше не повертає: зберігай їх одразу з першої відповіді.
• E-mail може бути адресою-ретранслятором. Apple радить не просити потім особисту адресу.
• Скасування не є помилкою. У Nolera закриття вікна Apple не викликає жодного червоного повідомлення: це свідома дія.

Реальний випадок із Solys, серпень 2026 року: кнопки Apple і Google були в застосунку, але жоден із двох провайдерів не був увімкнений у Supabase. Код був правильний, виправлення зробили на сервері, без нового білда. Кнопка Apple, яка не працює перед рев'юером, означає відмову 2.1 замість відмови 4.8. Подробиці в гайді з guideline 2.1.

4. Протестувати на справжньому iPhone

Expo попереджає, що симулятор дає лише обмежене тестування, а ідентифікатори, отримані в Expo Go, відрізняються від ідентифікаторів опублікованого застосунку. Перевір вхід, вихід і повторний вхід на справжньому iPhone з білдом TestFlight.

Вхід через Apple і видалення акаунта

Guideline 5.1.1(v) вимагає, щоб акаунт, створений у застосунку, можна було видалити із застосунку. Для входу через Apple сторінка Apple про видалення акаунта додає ще один крок: використати REST API Sign in with Apple, щоб відкликати токени людини.

Для відкликання потрібні дві речі: токен людини, який отримують, валідуючи код авторизації, і секрет, підписаний твоїм приватним ключем Sign in with Apple. Навіть якщо нативний вхід обходиться без секретного ключа, відкликання його вимагає, і він залишається на твоєму сервері. Чому так, пояснюю в статті секретний API-ключ у застосунку Expo.

У Nolera під час видалення акаунта застосунок знову просить увійти через Apple, щоб отримати свіжий код авторизації. Він надсилає його серверній функції, яка обмінює код в Apple, а потім відкликає токен. Якщо людина скасовує, зрозуміле повідомлення про це каже, і нічого не видаляється. Решта процесу, включно з даними, підпискою й тестами, описана в статті видалення акаунта в iOS.

Що відповісти Apple після відмови 4.8

Повідомлення Apple пропонує два виходи. Або ти додаєш рівноцінний варіант. Або в застосунку він уже є: ти відповідаєш в App Store Connect, кажеш, який саме, і чому він відповідає трьом умовам. Apple також радить оновити скриншоти, на яких видно екран входу. Процедура, як відповісти App Review, така сама, як і для інших правил.

Ось шаблон англійською, адаптуй його (заміни номер білда):

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,

Чек-лист 4.8 перед відправкою

• Ти знаєш, чи потрібен застосунку акаунт. Якщо ні, ним можна користуватися без входу.
• Якщо акаунт створюють через Google, Facebook чи X, вхід через Apple є на тому самому екрані.
• Кнопка Apple офіційна, такого ж розміру, як інші, і видна без гортання.
• Провайдер Apple увімкнений на сервері, з твоїм bundle identifier.
• Скасування повертає на екран входу без повідомлення про помилку.
• Ім'я та e-mail зберігаються з першого входу.
• Видалення акаунта відкликає токен Apple з твого сервера.
• Усе протестовано на справжньому iPhone з акаунтом Apple, який ще ніколи не входив у застосунок.
• Твої скриншоти показують екран входу таким, яким він є у відправленому білді.

Виправ відмову, перш ніж надсилати застосунок знову

Якщо твій застосунок щойно відхилили за 4.8, Apple Review Kit зводить разом усе, що я перевіряю перед кожною відправкою, плюс два skills, які перечитують твій проєкт у Claude Code і готують відповідь, якщо Apple відмовить. Якщо потрібен погляд живої людини, забронюй годину зі мною: ми разом прочитаємо повідомлення й подивимося на твій екран входу. Повний план дій після відмови є на сторінці застосунок відхилено Apple.

Якщо готуєш свій перший реліз, пройди безкоштовну діагностику: вона підкаже, з якого етапу почати, і надішле тобі мій чек-лист проти відмов Apple.

Ніхто не може гарантувати, що Apple прийме твій застосунок. Але вхід через Apple у правильному місці принаймні прибирає цю причину зі списку.

Поширені запитання

Чи обов'язковий вхід через Apple в iOS?

Ні, не завжди. Він потрібен лише тоді, коли застосунок пропонує сторонній вхід, як-от Google чи Facebook, для створення основного акаунта. Із січня 2024 року його може замінити інший рівноцінний сервіс, але Apple називає відповідним лише вхід через Apple.

Що означає «Guideline 4.8 - Design - Login Services»?

Це назва відмови в повідомленні Apple. Вона означає, що застосунок пропонує сторонній вхід, але не дає рівноцінного варіанта, який обмежує дані іменем і e-mail, дозволяє приховати e-mail і не використовується для реклами без згоди.

Чи достатньо реєстрації через e-mail поряд із Google?

Це не гарантовано. Текст вимагає сервіс, який дозволяє зберегти e-mail приватним, а звичайна форма його якраз запитує. Apple не публікував позиції щодо цього випадку, а його повідомлення про відмову згадує лише вхід через Apple. Я б не ризикував.

Чи треба пропонувати вхід через Apple на Android?

Ні. 4.8 є правилом App Store, а модуль Expo працює лише на iOS. На Android isAvailableAsync() повертає false: кнопка Apple не показується, і Google може лишатися єдиним варіантом.

Чи потрібен новий білд після відмови 4.8?

Так, здебільшого. Вхід через Apple потребує нативної capability, яку вмикають під час збірки. Віддалене оновлення не може її додати. Єдиний виняток: у застосунку вже був відповідний варіант, і достатньо пояснити це Apple у відповіді.