Перейти к содержимому

Apple удалила приватные email-адреса для входа через Apple ID

Apple удалила все приватные email, связанные с нашим сервисом для всех пользователей использовавших вход с Apple ID (ошибка на стороне Apple, которую мы исправить не можем), и теперь мы не можем отправлять вам письма, включая информационные и письма с кодом доступа.

Сбой произошел на стороне Apple 03 мая 2025г. во время плановых работ.

Что именно произошло:

3 мая 2025 года у нас произошёл критический сбой: “Вход с Apple” перестал работать корректно у всех пользователей, и мы полностью потеряли треть пользователей, зарегистрированных через приватный email от Apple.

Что произошло:

  • У всех пользователей сменился userIdentifier - Apple теперь возвращает другой идентификатор для того же Apple ID.
    Это делает авторизацию невозможной, потому что мы не можем сопоставить нового пользователя с его предыдущими данными.
  • Поле email теперь всегда null. Это нормальное поведение для повторного входа, но в данном случае это не имеет значения, потому что userIdentifier тоже изменился, и система вообще не может распознать пользователя.
  • Ранее выданные email-адреса @privaterelay.appleid.com перестали принимать письма - они отскакивают, мы это проверили.
  • Пользователи сообщают, что наше приложение исчезло из списка разрешённых в их Apple ID.

Контекст

  • Год назад мы перевели Apple Developer аккаунт с физлица на организацию.
  • Всё работало отлично до 3 мая 2025 года.
  • Сбой произошёл в тот же день, когда Apple выкатили обновление интерфейса Developer Console (Accounts, Profile и др.).
  • Мы уверены, что это следствие внутренних изменений Apple, затронувших авторизационные токены/механизмы.

Последствия

  • У всех пользователей userIdentifier стал новым → система считает их “новыми” и не даёт доступ к старым данным.
  • 1/3 пользователей, использовавших приватный email от Apple, полностью потеряны:
  • Мы не можем им отправить письмо (relay-адреса больше не работают).
  • Мы не можем восстановить им доступ (новый ID не соответствует старому).
  • Мы отправили 3 обращения в поддержку Apple по email - ответа нет, нет возможности эскалировать, нет live-чата, нет статуса инцидента.

🧠 Нас спасло только то, что в ASO.dev предусмотрена альтернативная авторизация - вход по email и одноразовому коду.
Без этого мы бы потеряли всех пользователей, использующих “Sign in with Apple”.


Мы делимся этой историей, чтобы:

  • Предупредить других разработчиков, использующих “Sign in with Apple” и relay-адреса.
  • Найти тех, кто столкнулся с аналогичной проблемой (давайте сравним ситуацию).
  • Привлечь внимание команды Apple - потому что восстановить доступ невозможно, а поддержки нет.

Никогда не полагайтесь только на Apple ID. Добавляйте резервный способ входа. Сбои возможны даже в крупнейших экосистемах.


Обновление

08 Августа 2025г. (3 месяца спустя)

Прошло долгих три месяца с момента инцидента 3 мая.
Мы неоднократно связывались с Apple, но так и не получили никакого ответа или объяснения - даже простого «мы разбираемся».

И вот… на прошлой неделе, без всяких предупреждений, всё снова заработало.

  • Вернулись исходные значения userIdentifier.
  • Пользователи с приватными адресами Apple теперь могут входить без проблем.
  • Письма на старые relay-адреса больше не отскакивают.
  • Наше приложение снова появилось в списке авторизованных для «Sign in with Apple» у затронутых пользователей.

Ни уведомлений, ни заметок о выпуске, ни комментариев. Просто бах - и починилось.

Мы можем лишь предположить, что это была внутренняя проблема Apple, связанная с их майскими обновлениями, и кто-то тихо всё откатил или исправил. Хотя мы рады, что проблема решилась, больше всего настораживает молчание со стороны Apple.


Обновление

28 Августа 2025г. (+20 дней)

Прошло почти четыре месяца с момента инцидента 3 мая.
Ответа от Apple мы так и не получили.
Мы запланировали новостную рассылку по базе пользователей и обнаружили, что некоторые пользователи снова не могут войти через Apple ID с приватными email или получить письмо, для аккаунтов созданных до инцидента от 3 Мая 2025г.


Выводы

Если вы зависите от Apple Sign-In, всегда предлагайте альтернативный способ входа.
Даже крупнейшие платформы могут сломаться непредсказуемо - без видимости и сроков восстановления.

Обновление (октябрь 2025): Apple ответила — но потребовалось 5 месяцев, чтобы написать «прочитайте документацию»

3 мая 2025 года функция Sign in with Apple внезапно перестала работать.
Примерно 30% пользователей больше не могли войти в систему: их userIdentifier тихо изменился, а поле email стало возвращать null.
Некоторые аккаунты даже временно “ожили”, а потом снова исчезли. Это совсем не выглядело как обычная миграция или проблема интеграции.

Мы отправили подробный баг-репорт и DTS-запрос (FB17664946 / Case 13610776) с описанием проблемы:
тот же bundle ID, без изменений в коде, стабильная сборка с 30 апреля — и вдруг ошибка из ниоткуда.

На ответ Apple ушло пять месяцев.
И финальное сообщение от Developer Technical Support свелось к следующему:

«Ваше приложение когда-то было передано между командами.
Ознакомьтесь с TN3159: Migrating Sign in with Apple users for an app transfer.»

И всё.
Без объяснений, почему проблема появилась почти через год после передачи приложения.
Без пояснений, почему некоторые пользователи ненадолго восстановились.
Без ответа, зачем вообще был изменён userIdentifier.


Почему менять userIdentifier — абсурдно

userIdentifier — это не токен, не псевдоним и не email.
Это постоянный внутренний идентификатор, единственный надёжный способ связать учётные записи пользователей с их данными.

Изменить его — всё равно что заменить каждому пользователю первичный ключ в продакшн-базе данных только потому, что приложение передали другой команде.
Обновлять email или JWT можно объяснить соображениями приватности.
Но менять основной идентификатор пользователя, который должен быть неизменным, — это ошибка архитектуры.

Такое решение вынуждает разработчиков вручную “мигрировать” Apple ID пользователей, что во многих случаях либо невозможно, либо крайне рискованно.
Большинство систем просто не рассчитаны на изменение первичного ключа идентичности — и не должны быть рассчитаны.


Почему это должно решаться в App Store Connect

Если такие сбросы могут происходить, App Store Connect должен:

  • автоматически мигрировать идентификаторы при передаче приложения, или
  • хотя бы показывать чёткое предупреждение вроде:
    «Пользователи, вошедшие через Sign in with Apple, могут потерять доступ после передачи приложения.»

Вместо этого единственный документ, где упомянуто это поведение — Technote TN3159, — спрятан глубоко на сайте Apple, без какой-либо видимости или подсказок, пока уже не поздно.


Пять месяцев спустя

Да — Apple всё же ответила.
Но потребовалось пять месяцев, чтобы просто написать «прочитайте документацию», не объяснив:

  • зачем вообще существует такое поведение,
  • почему оно сработало с опозданием почти на год,
  • и кто решил, что менять постоянный идентификатор пользователя — допустимо.

Пока Apple не пересмотрит подход к управлению идентичностью в Sign in with Apple, этот механизм остаётся фундаментально ненадёжным для разработчиков, которым важна целостность данных и непрерывность доступа пользователей.