iOS 27 даёт Apple, и растущему списку региональных законов, формальный способ сообщить вашему приложению возраст пользователя ещё до того, как вы начнёте собирать о нём данные. Если ваше приложение собирает хоть что-то от несовершеннолетних — а большинство потребительских приложений делают это, даже не формулируя так, — способ запроса согласия и документирования собираемых данных должен измениться. Не когда-нибудь. Для растущего списка регионов — уже сейчас.
Раз тема касается комплаенса, оговорка сразу: эта статья — практическая ориентировка для маркетинговых и продуктовых команд, а не юридическая консультация. Ваши обязательства зависят от того, где находятся ваши пользователи и чем занимается приложение, и детали должен утвердить юрист. Этот материал показывает, что вводит iOS 27, что это значит для вашего трекинга и сегментации, и даёт чек-лист, который стоит пройти до того, как проверка App Store ужесточится ещё сильнее. Pushwoosh — платформа вовлечения пользователей, и там, где согласие и сбор данных касаются настроек, которые вы конфигурируете у нас, мы указываем на это точечно.
Что на самом деле вводит iOS 27
В центре — два API, и они работают вместе.
Declared Age Range API позволяет приложению запросить возрастную категорию пользователя, например 13+, 16+ или 18+, ни разу не спрашивая и не сохраняя дату рождения. Apple выдаёт категорию; вы получаете сигнал, а не дату. Фреймворк доступен с iOS 26, а в iOS 27 ужесточаются сопутствующие требования и их применение.
PermissionKit отвечает за родительское согласие. Когда приложение вносит существенное изменение, которое влияет на то, как им пользуется несовершеннолетний, PermissionKit — это флоу, который информирует пользователя и, в регулируемых регионах, запрашивает одобрение родителя или опекуна, прежде чем несовершеннолетний продолжит.
Важный момент дизайна: система сама сообщает, когда это применимо. Через сигналы вроде isEligibleForAgeFeatures и requiredRegulatoryFeatures ОС указывает, распространяются ли возрастные обязательства на конкретного пользователя и нужно ли запрашивать возрастную категорию или родительское согласие. Вам не приходится гадать по каждому пользователю — платформа сама передаёт применимость.
В чём заголовки про «обязательно с сентября» ошибаются
Здесь стоит быть точным, потому что обязательство — не единый глобальный переключатель, и «обязательно с сентября» — формулировка, которую сама Apple не использует. Происходят две отдельные вещи, а медиа-освещение склонно схлопывать их в один дедлайн.
Первое — это проверка App Store при ревью. Apple последовательно ужесточает требования к тому, что должна показывать документация о приватности и обработка возраста, и от приложений с социальными функциями или пользовательским контентом ожидается видимый пользователю возрастной ценз, опирающийся на Declared Age Range API. Это ужесточение растянуто на весь цикл iOS 27, а не включается в одно конкретное утро — но если в приложении есть социальные функции, отнеситесь к этому как к работе, которую нужно закончить до следующего релиза, а не после.
Второе, с жёсткими датами, — региональное законодательство, и оно уже действует в ряде мест. Сама Apple привязывает обязательства Declared Age Range к конкретным юрисдикциям: возрастные категории передаются для новых аккаунтов Apple в Юте с 6 мая 2026 года и в Луизиане с 1 июля 2026 года, а блокировку загрузок 18+ в Австралии, Бразилии и Сингапуре Apple начала 24 февраля 2026 года. Другие законы идут по собственным графикам — некоторые уже действуют, некоторые перенесены. Регуляторные сигналы системы существуют именно потому, что ответ на вопрос «нужно ли мне это для данного пользователя» зависит от его региона и текущего состояния закона в этом регионе.
Практический вывод: если у вас есть социальные функции или UGC, либо вы собираете данные несовершеннолетних в любом регулируемом регионе, это текущая работа, а не задача на будущее. Если ни то, ни другое к вам пока не относится, поддерживать документацию о приватности в актуальном состоянии всё равно ожидается, а региональная карта расширяется — так что выстроить возможность сейчас дешевле, чем достраивать её позже под давлением дедлайна.
Почему это ложится на маркетинг, а не только на юристов
Проверка возраста выглядит как задача на стыке юристов и разработки — пока не проследить, чего она касается. А касается она напрямую того, как вы трекаете и сегментируете.
Если вы собираете рекламные идентификаторы, генерируете автоматические поведенческие события или строите сегменты на активности в приложении, возрастной сигнал меняет, что вам разрешено собирать и о ком. Пользователь в защищённой возрастной категории — не тот, кого можно молча включить в тот же поведенческий трекинг и сбор рекламных ID, что и взрослого. В момент, когда ОС может сообщить, что пользователь в регулируемом регионе несовершеннолетний, «мы трекаем всех одинаково» перестаёт быть защитимым дефолтом.
Это же момент закрыть пробел, который тянут за собой многие приложения: нечёткая или недокументированная обработка рекламных идентификаторов (IDFA на iOS, GAID на Android). Если в документации о данных не сказано ясно, какие рекламные идентификаторы вы собираете и зачем, этот пробел уже был риском. По мере того как проверка при ревью ужесточается на протяжении цикла iOS 27, он становится риском отклонения. Исправить историю со сбором возраста и документацией рекламных ID за один проход эффективнее — они живут в одних и тех же разделах privacy-раскрытия.
Ваш чек-лист комплаенса
Пройдите его вместе с юристами и инженерной командой:
- Составьте карту, где находятся ваши несовершеннолетние пользователи. Определите, в каких регионах вашей работы уже действуют законы о проверке возраста, и есть ли в приложении социальные функции или UGC, которые запускают проверку App Store независимо от региона.
- Внедрите сигналы применимости. Используйте сигналы ОС, которые сообщают, распространяются ли возрастные обязательства на конкретного пользователя, вместо того чтобы строить собственные догадки. Пусть платформа сама подсказывает, когда запрашивать возрастную категорию или согласие.
- Запрашивайте возрастную категорию, а не дату рождения. Там, где нужен возрастной сигнал, используйте Declared Age Range API, чтобы получать категорию и никогда не собирать и не хранить дату рождения, которую потом придётся защищать.
- Настройте родительское согласие для существенных изменений. Если приложением пользуются несовершеннолетние, убедитесь, что флоу согласия на существенное изменение работает для регионов, где это требуется.
- Сегментируйте трекинг по возрастной категории. Убедитесь, что пользователи в защищённых возрастных категориях исключены из сбора рекламных ID и поведенческого трекинга, не разрешённого для несовершеннолетних. Это настройка сбора данных и согласия, а не ручная проверка по каждому пользователю.
- Обновите документацию о приватности. Приведите privacy-раскрытие App Store в актуальное состояние и заодно закройте пробел в документации рекламных ID, чтобы обработка IDFA и GAID была ясно указана. Это первое, что проверяет система ревью.
- Проверьте тексты согласия. Убедитесь, что формулировки согласия, которые видит несовершеннолетний или опекун, соответствуют тому, что вы реально собираете — в том же духе, что и ваша практика согласия по GDPR.
Аккуратный сбор данных с учётом возраста в Pushwoosh
Pushwoosh даёт управление согласием и контроль сбора данных, чтобы сегментировать трекинг по возрастной категории, исключать защищённых пользователей из сбора, в котором их быть не должно, и держать обработку рекламных ID документированной и чистой. Платформа сертифицирована по SOC 2 Type I и ISO 27001:2022, соответствует GDPR и HIPAA, дата-центры — в ЕС и США. Работа над комплаенсом никогда не бывает бесплатной, но её сторона с данными не должна быть самой сложной частью.
