Пять стран — Франция, Германия, Италия, Польша и Румыния — названы Apple как территории, для которых распространяемым там приложениям следует использовать альтернативную подсказку ATT (разъяснение Apple о приватности и использовании данных). Это не отменяет требования получать разрешение на отслеживание. Приёмку ATT в ЕС на iOS 27.2 разделите на проверку стран распространения, поведения системной подсказки и обработки выбора пользователя. Не принимайте решение о выпуске по одному снимку экрана или единственному успешному показу.
На этой неделе зафиксируйте целевые регионы, соберите матрицу сценариев и отдельно отметьте, какая версия системы использовалась для проверки. По сведениям, проверенным 1 ноября 2026 года, iOS 27.2 всё ещё обозначена как Beta; считать её вышедшей из бета-версии нельзя. В тот же период Apple выпустила Xcode 27.2, но этот факт сам по себе не подтверждает выпуск финальной версии iOS 27.2. Статус системы и публикации инструментов проверяйте раздельно по журналу релизов Apple.
Кому пригодится: инженерам iOS, которым нужно проверить вызов ATT и обработку выбора.
QA-командам, отвечающим за проверку стран распространения, подсказки и перехода Additional Information.
Инженерам CI, которым требуется воспроизводимая среда macOS/Xcode и сохраняемые доказательства тестирования.
Последняя проверка материала — 1 ноября 2026 года. Перед выпуском приложения повторно проверьте статус iOS 27.2, актуальный текст Apple об ATT и совместимость инструментов. Если система выйдет из Beta или Apple изменит региональные условия, обновите план приёмки и повторите затронутые проверки.
Для выпуска: региональное требование отдельно, статус системы отдельно
Для решения о релизе держите в поле зрения три разных вопроса: что Apple сообщила об альтернативной подсказке, в каких странах действует отдельное условие и каков текущий статус операционной системы. Если объединить их в один вывод, команда рискует либо распространить требование на весь ЕС без основания, либо принять бета-тест за доказательство поведения финальной системы.
| Проверяемый факт | Что это означает для приёмки | Что следует записать |
|---|---|---|
| Apple описала альтернативную системную подсказку ATT для ЕС. | Добавьте соответствующий путь в тест-план, но не трактуйте изменение интерфейса как отмену разрешения на отслеживание. | Использованную версию системы и результат запроса ATT. |
| В разъяснении Apple отдельно названы Франция, Германия, Италия, Польша и Румыния. | Сопоставьте страны фактического распространения приложения с указанным условием; не переносите его автоматически на все страны ЕС. | Перечень целевых стран и подтверждение, по которому выбрана конфигурация. |
| На дату проверки iOS 27.2 имела статус Beta. | Результат на бета-системе может быть предварительным, а не свидетельством работы финального релиза. | Версию и статус системы, а также версию Xcode. |
Требования к Xcode и совместимой macOS проверяйте по официальной странице системных требований Apple. Совпадение номера Xcode не доказывает, что тест выполнялся на финальной версии iOS. В протоколе фиксируйте систему и инструменты раздельно: это позволяет понять, какое именно сочетание было проверено, и повторить испытание после изменения одного из компонентов.
В каких странах следует проверять альтернативную подсказку? В разъяснении Apple названы Франция, Германия, Италия, Польша и Румыния. Для других стран ЕС нельзя автоматически предполагать тот же режим: перед выпуском сверяйте актуальную документацию Apple и фактическую конфигурацию распространения. Это технический план проверки, а не юридическое заключение о соответствии приложения.
| Область распространения | Действие команды | Если данных недостаточно |
|---|---|---|
| Одна из названных Apple стран | Сопоставьте регион распространения с настройкой альтернативной подсказки и проверьте путь в целевой среде. | Не отмечайте регион как проверенный, пока не подтверждены конфигурация и результат теста. |
| Другие страны ЕС | Уточните по текущему разъяснению Apple, какие варианты применимы к вашему сценарию. | Не копируйте региональную настройку без проверки её применимости. |
| Приложение распространяется в нескольких регионах | Проверьте, как определяется нужный вариант подсказки и какие сведения доступны для подтверждения региона. | Занесите непроверенные страны в список ограничений перед решением о выпуске. |
Решение владельца релиза о допуске и толкование требований Apple — не одно и то же. Команда может установить собственные критерии готовности и зафиксировать основания, но не должна представлять инженерную проверку как юридическое подтверждение. В записи о выпуске сохраните применённое региональное правило, дату его проверки и перечень сценариев, которые действительно прошли испытание.
Для инженера iOS: запрос разрешения отдельно от прочих согласий
Меняет ли новая подсказка требование получать разрешение на отслеживание? Нет. Изменение относится к варианту системного сообщения в ЕС, а не к отмене необходимости учитывать решение пользователя. Проверьте и вызов ATT, и последующее поведение приложения; одного совпадения текста подсказки с макетом недостаточно.
Начните с места, где приложение вызывает requestTrackingAuthorization(completionHandler:). Убедитесь, что вызов связан с понятным для пользователя действием и что его время соответствует логике приложения. Не запускайте зависимое от разрешения поведение раньше, чем получите и обработаете результат. Описание назначения приложения проверьте в поле NSUserTrackingUsageDescription: формулировка должна объяснять реальное использование данных. Назначение поля описано в документации Apple по NSUserTrackingUsageDescription, а детали запроса — в документации Apple по вызову ATT.
Затем проследите все ветви обработки ответа. Сопоставьте статус, получаемый приложением, с тем, какие функции запускаются после разрешения, отказа или отсутствия определённого решения. Не приравнивайте отсутствие ответа к согласию и не считайте разрешение на другую цель эквивалентом разрешения ATT. Допустимые значения и смысл статуса следует сверять с документацией Apple по authorizationStatus.
Внутренний экран согласия, настройки приватности и другие разрешения приложения проверяйте отдельно. Они могут решать другие задачи и не подменяют результат системного запроса ATT. В тестовом протоколе свяжите каждый шаг с наблюдаемым результатом: какое состояние было до вызова, что показала система, какой статус получил код и какое поведение приложения последовало за выбором. Если журналы не позволяют установить хотя бы одно из этих звеньев, отметьте пробел, а не выводите успешный результат по косвенным признакам.
Для QA: проверяйте пользовательский путь, а не один кадр
Снимок экрана показывает внешний вид подсказки в конкретный момент, но не подтверждает корректность полного сценария. Он не доказывает, что системный запрос появился в ожидаемых условиях, что приложение распознало результат или что после отказа оно прекратило действие, для которого требуется разрешение. Поэтому проверяйте путь от начального состояния до наблюдаемого поведения приложения.
Для каждого сценария подготовьте исходное состояние ATT и запишите, как именно оно получено. Проверьте разрешение, отказ и неопределённое состояние, если их можно воспроизвести в используемой среде. Отдельно фиксируйте ограничения, мешающие получить ожидаемое состояние. Не полагайтесь только на переустановку или сброс приложения: такой шаг сам по себе не доказывает, какой статус вернёт система. Сопоставляйте наблюдаемый результат с API статуса и сохранёнными журналами.
Как проверить переход Additional Information? Запустите его именно из проверяемой подсказки, запишите, куда он ведёт и какое содержание видит пользователь. Сверьте это содержание с объяснением целей обработки и предусмотренными приложением вариантами выбора. Затем проверьте возврат в основное приложение: просмотр дополнительной информации или закрытие этого раздела не должны незаметно трактоваться как разрешение ATT.
Разведите в отчёте факт и интерпретацию. «На экране отображена подсказка» — наблюдение. «Приложение использовало правильный регион» требует подтверждения тестовой конфигурацией. «Отказ обработан корректно» требует проверки состояния и действий приложения после выбора. Для каждого вывода укажите подтверждение: журнал, статус, снимок экрана или повторяемую последовательность шагов. Если доказательство подтверждает только внешний вид, не распространяйте вывод на обработку данных.
Не объединяйте системное разрешение и внутренние согласия в одну отметку «пользователь согласился». Проверяйте их отдельными сценариями и названиями в отчёте. Это помогает QA и владельцу релиза обнаружить ошибки, которые иначе скрываются за общим результатом теста, и даёт разработчику конкретную точку для исправления.
Не считайте один успешный показ окна критерием допуска. Если вы не подтвердили регион, статус разрешения или поведение после выбора, обозначьте соответствующий пункт как непроверенный и назначьте способ повторной проверки.
Для CI: сохраняйте среду и доказательства вместе
Чтобы другой инженер мог воспроизвести проверку, сохраняйте идентификатор сборки или коммита, версию Xcode, версию и статус iOS, способ запуска и результат сценария. Прикладывайте журнал теста, сведения о состоянии ATT и доказательства пользовательского перехода. Требования к совместимости инструментов сверяйте с системными требованиями Xcode, а статус операционной системы — с официальными сведениями Apple о выпусках.
Успешный запуск в Simulator подтверждает только то, что было проверено в этой конфигурации. Он сам по себе не доказывает региональное поведение во всех странах или работу на каждой целевой системе. В отчёте разделите проверенное в Simulator, подтверждённое иными доступными средствами и оставшееся без проверки. Не заявляйте, что среда воспроизводит определённые страну, учётную запись или условия тестирования, пока команда не подтвердила это на практике.
Порядок подготовки доказательств:
- Зафиксируйте сборку приложения, коммит и настройки распространения, относящиеся к тесту.
- Запишите версию Xcode, версию и статус iOS, а также способ запуска.
- Опишите исходное состояние ATT и способ его получения; подтвердите результат через статус, доступный приложению.
- Выполните сценарий и сохраните отображённую подсказку, выбор пользователя, результат вызова и поведение приложения.
- Отдельно проверьте Additional Information, его содержание и возврат в приложение.
- Свяжите полученные результаты с целевыми странами. Все ограничения, которые не удалось проверить, явно укажите в итоговом отчёте.
Эти шаги нужны не для того, чтобы увеличить объём артефактов, а чтобы связать вывод о выпуске с конкретным испытанием. Журнал без указания версии системы трудно сопоставить с результатом другого запуска; снимок экрана без состояния ATT не показывает, какую ветвь проходило приложение. Если доказательства нельзя связать с исходными условиями, повторите тест или обозначьте итог как неопределённый.
Повторный запрос ATT: не проектируйте его по календарному предположению
Гарантирует ли система ежегодное повторное появление запроса? Не планируйте повторный системный запрос как обязательное поведение без подтверждения в актуальной документации Apple и тестирования на целевой версии. Документация вызова и статуса помогает проверить конкретное состояние, но не даёт основания автоматически утверждать, что диалог повторится по годовому расписанию. Если продукту нужно снова объяснить пользователю цели обработки, проверяйте это как отдельную логику приложения.
Отделяйте внутреннее напоминание о настройках приватности от нового системного запроса. В тестовом плане укажите, какое действие выполняет приложение и какое состояние ATT ожидается после него. Не меняйте внутреннюю запись о согласии только потому, что пользователь увидел экран приложения, прошло время или он открыл дополнительные сведения. Подтверждайте фактический статус средствами, доступными приложению, а предположение о повторном системном диалоге не превращайте в критерий релиза.
Для владельца выпуска: решение по условиям, а не по одной удачной попытке
Используйте условия допуска как развилки:
- Если целевые страны определены, применимое региональное требование сверено с актуальными сведениями Apple, а подсказка и обработка выбора подтверждены, то передавайте сборку на решение о выпуске по регламенту команды.
- Если региональный сценарий не удалось воспроизвести, но вызов ATT, статусы и реакция приложения проверены, то рассматривайте только тот ограниченный пилот, который допускает ваш процесс, и явно укажите оставшиеся ограничения.
- Если после отказа приложение выполняет действие, требующее разрешения, или команда не может подтвердить фактический статус, то приостановите выпуск до исправления и повторной проверки.
- Если доступная бета-среда не позволяет получить нужное доказательство, то зафиксируйте этот пункт как непроверенный и повторите испытание в подходящей среде. Не обозначайте Beta как финальную версию.
Повторно оцените решение, если изменились системный статус, разъяснение Apple или требования к Xcode и macOS. Выпуск Xcode и статус iOS — разные факты, поэтому наличие нового инструмента не служит подтверждением выхода операционной системы. Сохраните версии, дату проверки и перечень непроверенных условий рядом с итоговым решением, чтобы следующий инженер мог понять, какие именно основания использовались.
Удалённый Mac: сначала проверьте пригодность среды
Если у команды нет подходящей macOS/Xcode-среды, удалённый Mac может дать временную площадку для сборки и тестового запуска. До выбора узла выясните, доступна ли требуемая версия Xcode, подходит ли хостовая macOS и можно ли выполнить именно ваш сценарий. Возможность запуска Simulator, проверки на физическом устройстве, доступа к нужной учётной записи и воспроизведения региональных условий подтверждайте отдельно. Не считайте ни одну из этих возможностей гарантированной без проверки.
| Вариант | Когда он уместен | Что требуется подтвердить |
|---|---|---|
| Собственный Mac | Команде постоянно нужна локальная среда или физическое подключение оборудования. | Совместимость macOS/Xcode, обслуживание и воспроизводимость настроек. |
| Имеющийся CI-узел | Среда уже подходит требованиям проекта и может выполнять нужные тесты. | Доступность журналов, восстановление конфигурации и фактическое покрытие сценариев. |
| Арендованный удалённый Mac | Требуется временная среда без покупки отдельного компьютера, а доступная конфигурация подходит задаче. | Нужные версии инструментов, тестовое назначение, способ подключения и сохранение результатов. |
| Только Simulator | Проверка ограничена логикой и интерфейсом, которые можно подтвердить в этой среде. | Какие физические или региональные условия остаются за границами такого испытания. |
У постоянного собственного узла есть смысл, если у вас длительная стабильная нагрузка, нужны физические подключения или вы хотите полностью контролировать обслуживание. Уже работающий CI-узел может быть рациональнее, если он совместим и уже выдаёт достаточные доказательства. Для временного проекта аренда позволяет не покупать отдельный компьютер, однако не устраняет необходимость проверить конкретный Xcode, систему и тестовое назначение. Изучить доступные условия можно на странице тарифов аренды Mac; принимайте решение после сопоставления предложенной среды с реальным планом тестирования.
Если проверка показала, что удалённая среда подходит, и вам нужно провести ограниченный прогон, рассмотрите заказ удалённого Mac. Если же команда регулярно выполняет тяжёлые задачи и нуждается в стабильном узле или физическом оборудовании, сравните аренду с покупкой и эксплуатацией собственного Mac. Для приёмки ATT важна не сама форма владения, а возможность воспроизвести целевой сценарий и сохранить подтверждения.
Итоговое решение должно отвечать на три вопроса: применима ли подсказка к целевым регионам, корректно ли приложение обрабатывает выбор, достаточно ли доказательств для конкретной версии системы. Зафиксируйте ответы и ограничения до выпуска. Если одного из подтверждений нет, не заменяйте его успешным снимком экрана: отметьте неопределённость, назначьте повторную проверку и принимайте решение после получения воспроизводимого результата.