


16 октября Apple обновила App Review Guidelines, правила проверки приложений перед публикацией в App Store. Уточнения касаются пользовательского контента, скрытых функций и материалов для представления приложения в магазине. В Mentoring.digital объясняем, что стоит включить в подготовку следующего релиза мобильного продукта.
Коротко: приложение с загружаемым или создаваемым пользователями контентом должно иметь работающие меры против злоупотреблений. Функции должны быть понятны пользователю и проверяющей команде Apple. При этом запрет скрытых возможностей существовал и раньше: обновление уточняет его формулировку и выделяет отдельный пункт.
В разделе 1.2 Apple явно перечисляет сервисы пользовательского контента и приложения для его создания с помощью AI. Правила требуют фильтрации недопустимых материалов, механизма жалобы, возможности заблокировать нарушителя и опубликованных контактов для связи с разработчиком.
Компания отдельно подчеркнула необходимость предотвращать и удалять интимные изображения людей, распространяемые без их согласия, включая сгенерированные. Если разработчик не внедряет необходимые меры или не устраняет нарушения после уведомления, это может повлечь меры в отношении приложения и разработчика.
Для команды продукта это повод проверить весь путь обращения, а не только наличие кнопки «Пожаловаться». Кто получает сигнал? Может ли ответственный найти спорный материал? Понимает ли пользователь результат блокировки? Наш редакционный вывод: интерфейс жалобы и процесс её обработки нужно рассматривать как одну функцию.
В новом пункте 2.5.19 Apple уточнила давний запрет на скрытые, неактивные и недокументированные функции. Возможности приложения должны быть ясны конечным пользователям и App Review. В пояснении Apple отдельно описывает ситуацию, когда продукт меняет поведение после одобрения и открывает возможности, которые не были представлены при проверке.
Рассмотрим условный пример: команда отправляет на проверку редактор изображений, а после одобрения планирует включить серверным переключателем ещё один генеративный режим. Переключатель сам по себе не отвечает на вопрос, раскрыты ли реальные возможности продукта проверяющей команде. Нужно заранее сопоставить описание, доступный сценарий и примечания к отправляемой сборке.
Из этого не следует, что любой технический переключатель запрещён. Существенный вопрос состоит в том, не скрывает ли он фактическую функциональность. Разобрать архитектуру такого выпуска и подготовку приложения можно с наставником по разработке для iOS.
Новый пункт 2.3.14 описывает creative assets, дополнительные визуальные материалы магазина. Они должны соответствовать содержанию, возможностям или бренду приложения и подходить для любой аудитории. В частности, правила исключают вводящие в заблуждение отсылки к другим приложениям, неподтверждаемые заявления о продукте и конкретные цены или скидки.
Для разработчика это ещё одна точка согласования с дизайнером и маркетологом. Если на обложке показана функция, которой нет в отправляемой версии, техническая готовность сборки не исправляет расхождение. Полезно проверять материалы рядом с реальным пользовательским сценарием, а не отдельной папкой картинок.
Этот список можно превратить в сценарии проверки приложения с QA-наставником. Его выполнение не гарантирует одобрения Apple: решение зависит от конкретного продукта и проверки платформы. Но он помогает обнаружить расхождения до отправки и распределить ответственность между разработкой, модерацией и оформлением страницы.
Это разбор действующих формулировок Apple. Собственное прохождение App Review по этим правилам редакция не проводила.
Обложка: редакционная иллюстрация, не скриншот App Store.