В примечаниях Apple к бета-версии iOS/iPadOS 27.2 указаны альтернативное уведомление ATT для ЕС и возможность ежегодного повторного запроса для пользователей в ЕС (описание выпуска). Вывод для команды: сначала подтвердите, что приложению действительно требуется разрешение на отслеживание, а затем проверяйте экран по региону, версии системы и состоянию пользователя. Само появление нового варианта уведомления не означает, что нужно менять логику отслеживания или запрашивать разрешение у всех пользователей.
Материал предназначен разработчикам приложений, выпускаемых в ЕС и использующих рекламную атрибуцию или отслеживание между приложениями. Он также пригодится командам, которые проверяют локализацию и региональные сборки, а также поддерживают среду Xcode для регрессионных тестов.
Последняя проверка: 1 октября 2026 года. Сверено с актуальными примечаниями Apple к iOS/iPadOS 27.2 Beta, материалами об ATT в ЕС, документацией API и сведениями о конфиденциальности. Поскольку речь идёт о бета-версии, перед выпуском необходимо проверить актуальные документы и поведение целевых сборок.
iOS 27.2 ATT в ЕС: сначала определите применимость
ATT — не обязательное всплывающее окно для каждого приложения в европейском магазине. Проверять нужно фактические потоки данных: передаёт ли приложение данные о пользователе или устройстве другим компаниям для связывания с данными из приложений, сайтов или сервисов этих компаний в целях рекламы или измерения эффективности. Описание в политике конфиденциальности и формулировка «мы не отслеживаем» сами по себе не заменяют такой проверки. Начать следует с определения Apple о пользовательской конфиденциальности и использовании данных.
| Ситуация в приложении | Что проверить | Следующее действие |
|---|---|---|
| Данные остаются внутри приложения или используются только для заявленной внутренней функции | Нет ли передачи и связывания данных между компаниями для целей отслеживания | Зафиксировать основание решения; не добавлять запрос ATT только ради нового интерфейса |
| Используются сторонние рекламные или аналитические инструменты | Какие данные уходят поставщику, как они связываются с данными за пределами приложения и для чего используются | Проверить применимость ATT по реальному поведению интеграции |
| Есть рекламная атрибуция, но схема передачи данных неясна | Идентификаторы, события, SDK, настройки партнёров и серверные потоки | До выпуска собрать фактическую карту данных и разрешить неопределённость |
| ATT уже запрашивается | Место вызова API, описание в plist, обработка статуса и поведение после ответа | Сравнить старый и новый системные варианты на целевых сборках |
Полное описание фреймворка AppTrackingTransparency полезно для сверки с кодом, но решение о применимости нельзя сводить к тому, подключён ли этот фреймворк. Важно, что именно делает приложение и его SDK, включая отправку событий после закрытия экрана и последующую обработку данных на сервере.
Какие изменения относятся к системному уведомлению, а какие — к правилам отслеживания?
Для тестирования разделите два вопроса. Первый — какой вариант системного экрана показывает конкретная комбинация системы и условий пользователя. Второй — вправе ли приложение выполнять отслеживание и каким образом учитывает разрешение. Изменение дизайна или дополнительных объяснений интерфейса само по себе не меняет определение отслеживания и не превращает ранее необязательный запрос в обязательный.
На дату проверки Apple описывает альтернативный вариант уведомления в материалах для iOS/iPadOS 27.2 Beta. Это не основание утверждать, что поведение уже закреплено для финального выпуска или останется неизменным. В релизном процессе зафиксируйте точную сборку операционной системы и версию Xcode, на которых выполнена проверка.
Региональные условия и выбор тестового сценария
Apple указывает, что для Франции, Германии, Италии, Польши и Румынии альтернативный вариант является единственной применимой системной версией уведомления; для других условий в ЕС предусмотрен выбор альтернативного варианта. Это описание следует проверять по актуальным материалам Apple о конфиденциальности и ATT в ЕС, поскольку речь идёт о региональной логике, связанной с выпуском и применимостью функции.
| Область проверки | Что следует учитывать | Чего нельзя считать достаточным |
|---|---|---|
| Франция, Германия, Италия, Польша, Румыния | Проверить альтернативный вариант как единственную применимую системную версию уведомления | Один лишь язык устройства или аккаунта |
| Другие условия в ЕС | Проверить доступный выбор альтернативного системного варианта и поведение конкретной сборки | Предположение, что любой пользователь ЕС увидит одинаковый экран |
| Пользователь за пределами ЕС | Проверить поведение отдельно, если приложение распространяется и там | Переносить европейское правило на все страны |
| Несколько рынков и локализаций | Зафиксировать рынок распространения, системную версию, язык и способ тестирования отдельно | Считать, что страна в настройках устройства всегда равна квалифицирующему условию |
Какие приложения в отдельных странах ЕС увидят альтернативный вариант?
Проверка должна включать указанные Apple страны и условия, относящиеся к конкретной сборке. Не смешивайте страну распространения приложения, местонахождение пользователя, регион учётной записи и язык интерфейса: это разные признаки. Если тестовая конфигурация меняет только язык устройства, она не подтверждает региональную применимость.
Для воспроизводимой проверки заведите запись с такими полями:
app_build: <номер сборки приложения>
ios_build: <точная сборка iOS>
xcode_build: <точная сборка Xcode>
distribution_market: <рынок распространения>
device_region: <регион устройства>
account_region: <регион учётной записи, если известен>
app_language: <язык приложения>
att_status_before: <статус до запроса>
shown_ui: <описание или снимок экрана>
callback_status: <статус после завершения запроса>
Это не перечень условий, которые Apple гарантированно использует для определения допуска, а формат журнала тестирования. Он помогает не приписывать результат одному лишь региону устройства и позволяет сравнивать прогоны. Сам критерий выбора системного варианта следует сверять с официальными материалами Apple по ЕС.
Состояние разрешения, описание и дополнительный экран
Если приложению действительно нужен ATT, проверьте уже существующий поток запроса, а не только внешний вид системного уведомления. В plist должно быть осмысленное описание NSUserTrackingUsageDescription, если приложение вызывает запрос авторизации; Apple описывает назначение этого ключа в документации NSUserTrackingUsageDescription.
Расширенное объяснение, включая NSUserTrackingMarkdownUsageDescription, рассматривайте как дополнительный материал интерфейса, а не как новый обязательный ключ или новое основание для отслеживания. Поддерживаемый формат и условия использования нужно сверять с актуальной документацией Apple об интерфейсе ATT и обновлениях для ЕС. Дополнение должно понятно объяснять конкретное применение данных, а не скрывать его за общими обещаниями.
| Элемент | Проверка перед выпуском | Типичная ошибка |
|---|---|---|
NSUserTrackingUsageDescription |
Текст точно называет цель запроса и соответствует фактическим потокам данных | Общее описание вроде «для улучшения сервиса» без пояснения отслеживания |
NSUserTrackingMarkdownUsageDescription |
Ключ добавлен только при необходимости; разметка и локализации проверены в поддерживаемом системном интерфейсе | Представлять дополнительный текст как обязательный для любого приложения |
| Предварительный экран приложения | Ясно отделён от системного запроса и не имитирует его | Выдавать собственную карточку за системное разрешение |
| Дополнительное действие с информацией | Проверены вызов, открытие и возврат пользователя к запросу | Предполагать, что наличие кнопки автоматически означает согласие |
Как проверить дополнительное описание ATT?
Сначала выясните, действительно ли дополнительный текст улучшает понимание запроса. Затем проверьте, что он не подменяет системный диалог и не предлагает пользователю согласиться под давлением. Нельзя обещать, что базовые функции приложения будут доступны только после разрешения, если это не соответствует фактической работе продукта. Нельзя также использовать текст, создающий впечатление, что согласие необходимо для функции, не связанной с отслеживанием.
Проведите проверку как минимум по следующим направлениям:
- смысл текста совпадает с фактическим использованием данных и описанием в политике конфиденциальности;
- формулировки переведены для каждого поддерживаемого языка, а не оставлены в исходной локали;
- Markdown не ломает структуру, ссылки и читаемость на системном экране;
- кнопки и дополнительные действия имеют понятный результат;
- предварительное объяснение приложения визуально и функционально не маскируется под системное уведомление.
Условия для дополнительного интерфейса и API сверяйте с официальной документацией AppTrackingTransparency. Если для конкретной бета-сборки описание API изменилось, зафиксируйте это отдельно, не считая локальную удачную отрисовку подтверждением для всех версий системы.
Сценарии согласия и повторного запроса
До каждого прогона сохраните исходный статус ATT. Иначе отсутствие системного экрана легко принять за ошибку показа, хотя система может уже хранить решение пользователя или ограничивать запрос. Apple документирует варианты статуса в описании authorizationStatus.
| Исходное состояние | Что проверять | Как трактовать отсутствие нового уведомления |
|---|---|---|
| Решение ещё не принято | Условия вызова, системный экран и результат completion handler | Проверить, что приложение действительно дошло до вызова и запрос не ограничен системой |
| Пользователь разрешил отслеживание | Зафиксировать статус и проверить, как приложение применяет его дальше | Не считать повторное отсутствие экрана ошибкой |
| Пользователь отказал | Убедиться, что приложение уважает отказ и не запускает запрещённый сценарий | Статус отказа не равен сбою интерфейса |
| Запрос ограничен устройством или настройками | Проверить статус, настройки и диагностические записи тестового устройства | Не делать вывод, что система «забыла» показать уведомление |
| Проверяется возможность повторного запроса в ЕС | Зафиксировать предыдущие решения и условия теста, сверить правило с актуальной документацией | Не запускать таймер вручную и не считать любой отказ автоматически отменённым через календарный срок |
Можно ли повторить запрос ATT после отказа до истечения года?
Не считайте, что любой отказ можно обойти повторным вызовом API или что календарная дата сама по себе гарантирует появление уведомления. Apple сообщает о возможности ежегодного повторного запроса для пользователей в ЕС в примечаниях к iOS/iPadOS 27.2 Beta, но конкретный результат зависит от описанных системой условий. Поэтому проверяйте не только текст уведомления, но и исходный статус, историю теста и поведение callback.
API запроса следует сверять с официальным описанием requestTrackingAuthorization. Запишите статус до вызова и результат completion handler; отдельно отметьте ограничения устройства и способ подготовки состояния. Не выдавайте многократные прогоны на одном симуляторе за модель поведения разных реальных пользователей.
Порядок приёмки перед выпуском
Используйте последовательность ниже как рабочий регламент. Она отделяет проверку права на запрос от визуальной приёмки и помогает получить воспроизводимую запись для релизного решения.
Определите реальное поведение данных. Составьте карту SDK, событий и получателей данных. Отметьте, какие данные выходят за пределы приложения и используются ли они для связывания активности между компаниями. Если ответ неясен, сначала выясните поведение интеграции, а не добавляйте новый запрос наугад.
Проверьте точку вызова ATT. Найдите requestTrackingAuthorization и проверьте, вызывается ли он только при наличии основания. Убедитесь, что запрос не повторяется на каждом запуске и что экран приложения, предшествующий системному, не выдаётся за само разрешение. Сопоставьте поведение с документацией API запроса ATT.
Проверьте текст и локализации. Сверьте NSUserTrackingUsageDescription с назначением приложения и фактическими данными. Если используется NSUserTrackingMarkdownUsageDescription, отдельно проверьте форматирование и полноту перевода на системных экранах. Удалите обещания, которые не подтверждаются продуктом, и формулировки, подталкивающие к согласию.
Соберите региональные сценарии. В плане теста явно укажите рынок распространения, регион устройства, язык и сведения об учётной записи, если они доступны. Отдельно проверьте страны, для которых Apple указывает единственный альтернативный вариант системного уведомления. Не подменяйте квалифицирующие условия изменением только языка интерфейса.
Проведите проверки состояний. Подготовьте независимые прогоны для состояния без принятого решения, разрешения, отказа и ограниченного запроса. Для каждого прогона сохраните исходный статус, факт показа экрана и результат callback. Используйте одинаковую трактовку статусов авторизации ATT во всей команде.
Зафиксируйте инструментальную среду. Укажите точные версии iOS и Xcode, тип тестового устройства и сборку приложения. Примечания к Xcode 27.2 Beta следует проверять отдельно от примечаний к iOS/iPadOS: совпадение номера версии не подтверждает совместимость каждой конфигурации. Если воспроизводимость зависит от конкретной беты, повторите проверку после обновления инструментов.
Подготовьте доказательства для релизной проверки. Сохраните снимки системных вариантов, конфигурацию локализации, запись статусов и дату прогона. Укажите, что именно было изменено между тестами. Это позволяет отличить изменение UI в новой сборке от отличия пользовательского состояния или региона.
Для ручного журнала достаточно придерживаться одинакового формата:
Проверка: ATT / ЕС
Сборка приложения: <значение>
Сборка iOS: <значение>
Сборка Xcode: <значение>
Рынок распространения: <значение>
Исходный статус: <значение>
Показан системный экран: <да / нет>
Результат callback: <значение>
Дополнительные замечания: <локаль, ограничения, способ подготовки состояния>
Если системное уведомление не появилось, не меняйте сразу текст plist и не добавляйте второй запрос. Сначала проверьте, был ли вызван API, каков исходный статус, не ограничен ли запрос, какой рынок и сборка тестировались, и соответствует ли сценарий условиям Apple. Затем повторите прогон в контролируемой конфигурации.
Граница удалённого Mac и выбор тестовой среды
Удалённый Mac может служить отдельной macOS-средой для сборки проекта и работы с Xcode, но сам по себе не устанавливает региональную квалификацию пользователя и не доказывает, какой системный вариант увидит реальный пользователь. Для приёмки ATT нужны тестовые условия, соответствующие проверяемому сценарию, а при необходимости — проверка на реальном устройстве. Не следует выводить поведение iOS из одного факта, что Xcode запущен на удалённой машине.
Если у команды уже есть подходящий Mac и устройства для тестирования, дополнительная аренда может быть лишней. Если же нужен отдельный macOS-контур для сборок и проверки Xcode, а покупать машину ради временного этапа нецелесообразно, можно изучить варианты удалённого Mac от NodeMini и заранее уточнить в справочном центре NodeMini, подходит ли доступная среда для нужного процесса. Аренда решает задачу отдельного Mac, но не заменяет устройство, региональные условия или фиксацию пользовательского статуса.
Главное условие приёмки — не наличие нового экрана как такового, а доказуемая цепочка: приложение действительно подпадает под ATT, запрос выполняется корректно, системный вариант соответствует тестовым условиям, а ответ пользователя обрабатывается без подмены. После публикации новых примечаний к iOS/iPadOS или Xcode повторно сверьте условия ЕС и бета-поведение с актуальными документами Apple.