Как пройти модерацию в Google Play и App Store в 2026 году

Почему Фора Софт написала этот плейбук

Отказы при модерации почти никогда не связаны с плохим кодом — они возникают из-за бумажной работы, которую можно было легко избежать: отсутствует privacy manifest, описание не соответствует приложению, демо-аккаунт не работает, устаревший target API. Команды, которые публикуют обновления быстрее всех, — это не самые сильные разработчики, а те, кто лучше всех подготовили подачу. Этот гайд — чек-лист, по которому мы в Фора Софт проходим перед каждым мобильным релизом, адаптированный под реалии 2026 года: EU DMA, privacy manifests, target API Android 15 и новые правила Apple по согласию на использование ИИ.

С 2005 года мы разработали более 99 мобильных и видеоприложений для iOS и Android, с долей пятизвёздочных отзывов на Upwork — 98%. Через нашу модерацию прошли образовательные платформы вроде BrainCert, телемедицинские приложения вроде CirrusMED и потребительские видеоприложения — и наши рекомендации основаны на реальных кейсах, а не на маркетинговых текстах очередных SaaS-сервисов для проверки приложений.

Контекст рынка: почему модерация — это стратегия, а не формальность

В 2026 году в App Store около 1,8 млн приложений, в Google Play — 2,5–3 млн. Apple обрабатывает более 200 000 заявок в неделю по всему миру и за прошлый год отклонила примерно 1,93 млн из 7,77 млн. Google только за 2025 год заблокировал более 255 000 приложений за избыточный доступ к данным и закрыл более 80 000 аккаунтов разработчиков. Вывод: сторы больше не одобряют всё подряд. Небрежная заявка сегодня почти наверняка застрянет — поэтому несколько недель, потраченные на правильный compliance-слой, окупаются скоростью запуска и тем, что вам не придётся в последний момент переделывать всё перед релизом.

Планка модерации в 2026 году: что реально изменилось

Политики сторов — движущаяся мишень. Четыре сдвига 2025–2026 годов определяют, что вы обязаны отгрузить сегодня, хотя год назад без этого ещё могли обойтись.

1. Privacy manifest обязателен на iOS. С мая 2024 года каждое iOS-приложение должно содержать файл PrivacyInfo.xcprivacy, в котором перечислены типы собираемых данных, сторонние SDK с целями их использования и одобренные коды причин для каждого API, требующего обоснования. В 2025–2026 годах контроль станет жёстким: Xcode не даст загрузить приложение, а живой модератор всё равно отклонит его, если манифест не соответствует реальному поведению приложения.

2. Согласие на использование ИИ обязательно. С ноября 2025 года, если ваше приложение передаёт персональные данные сторонним провайдерам ИИ (OpenAI, Anthropic, Gemini, ElevenLabs и др.), вы обязаны показывать экран согласия с указанием провайдера и перечнем передаваемых данных. Без такого экрана — отказ по 5.1.1.

3. Минимальный target API 35 в Google Play в 2025–2026. С 31 августа 2025 года новые приложения и обновления должны поддерживать Android 15 (API 35). С 31 августа 2026 года минимальная версия станет Android 16 (API 36). Если не успеваете — не сможете выпускать обновления, пока не обновите приложение.

4. DMA перекроил дистрибуцию в ЕС. С 26 июня 2025 года европейские приложения могут распространяться через Web Distribution или альтернативные маркетплейсы, предлагать внешние платежи и больше не могут быть заблокированы за ссылки на офферы вне App Store. С 1 января 2026 года Core Technology Fee за установку упразднена в пользу единой Core Technology Commission — это влияет на ценообразование, не на модерацию, но меняет то, что должна проверить ваша юридическая команда.

Главные причины отказов — по частоте в 2026 году

Примерно 25% заявок в App Store отклоняются на первой проверке; доля отказов в Google Play ниже, но контроль через Data Safety и разрешения стал жёстким. Рейтинг ниже объединяет данные о прозрачности Apple, отчёт Google по безопасности за 2025 год (255 000+ заблокированных приложений, 80 000+ заблокированных аккаунтов разработчиков) и нашу собственную выборку из примерно 60 мобильных подач за последние 12 месяцев.

App Review Guidelines от Apple — правила, которые реально кусают

Запоминать все 300+ пунктов гайдлайнов не нужно — важно знать конкретные правила, которые Apple указывает в реальных отказах. Ниже — краткий список и то, как должен выглядеть «соответствует» в 2026 году.

Правило 2.1 — Полнота приложения

Никаких заглушек, никаких TODO, никаких битых ссылок, никаких мёртвых пейволлов. Каждая кнопка, до которой можно добраться с первого экрана, должна выполнять реальную функцию. Ваш бэкенд должен работать во время модерации — если ревьюер открывает приложение с 08:00 до 18:00 по тихоокеанскому времени, а ваш стейджинг падает, отказ по 2.1 гарантирован.

Правило 2.3 — Точные метаданные

Скриншоты должны соответствовать приложению, которое вы подаёте, а не будущей версии. Не используйте имена конкурентов в названии, подзаголовке или описании. Избегайте перегрузки ключевыми словами для ASO. Если приложение находится в бета-версии — укажите это на скриншотах; если нет — перед подачей удалите все плашки «Beta».

Правило 3.1 — Payments

Цифровой контент, который используется внутри приложения, должен продаваться через In-App Purchase — если только вы не относитесь к категории reader app или не находитесь в ЕС и не подключили External Purchase Link Entitlement по DMA. Размещение ссылки на внешние способы оплаты без соответствующего права — это нарушение пункта 3.1.1.

Правило 4.8 — Вход через Apple

Если вы предлагаете вход через сторонние сервисы (Google, Facebook, X, LinkedIn и другие), вы обязаны предложить и вход через Apple — наравне с ними, без скрытия в подменю. Корпоративный SSO и государственные e-идентификационные потоки освобождаются от этого требования.

Правило 5.1 — Конфиденциальность

Рабочий URL политики конфиденциальности. Заполненная карточка App Privacy в App Store Connect, соответствующая реальному сбору данных. Privacy manifest, в котором перечислены все сторонние SDK. Промпт App Tracking Transparency с одобренной формулировкой, если используется IDFA. Экран согласия на использование ИИ, если персональные данные передаются внешним моделям. Не хватает хотя бы одного — отказ.

Google Play: три этапа, которые нужно пройти

1. Минимум target API 35 (Android 15). Установите targetSdkVersion = 35 в Gradle, проверьте все вызовы устаревших API и протестируйте на реальном устройстве с Android 15. Продление дедлайна возможно, но оно ограничено — планируйте так, будто его не будет.

2. Форма Data Safety совпадает с реальным поведением. Задекларируйте каждый тип данных, которые вы или сторонние SDK собираете, — как они используются и с кем делятся. Уточнение Google от апреля 2025 года жёсткое: если ваша SDK (рекламная сеть, аналитика) использует данные для собственных целей — это считается передачей. Прочешите ваш build.gradle построчно.

3. Пермишены обоснованы или убраны. Разрешения на SMS и журнал вызовов доступны только приложениям по умолчанию для отправки сообщений и звонков. Доступ к сервису доступности запрещён для любых сценариев «автономного действия» — таких как фреймворки автоматизации, кликботы и подобные. Для работы в фоне требуется указать тип сервиса foregroundServiceType. Удалите всё, что вам не нужно.

Ловушка закрытого тестирования Google Play для новых личных аккаунтов

Если ваш аккаунт разработчика создан после 13 ноября 2023 года как личный, вы обязаны провести закрытый тест с участием минимум 12 верифицированных тестировщиков в течение не менее 14 дней перед публикацией приложения в магазине. Это правило остаётся в силе и в 2026 году, и особенно сильно затрагивает соло-разработчиков.

Обходы: завести аккаунт организации (он освобождается от ограничений) или запустить таймер закрытого тестирования в тот же день, когда открыли аккаунт разработчика, а не когда приложение готово. Набирайте тестировщиков из сообществ (Reddit, Slack-группы, Discord), а не из друзей и семьи — в спорных случаях Google смотрит на качество списка.

Чек-лист из 25 пунктов, который мы проверяем перед каждым релизом

Это буквально тот чек-лист, который мы вставляем в релизный тикет на каждом мобильном проекте. Идите по порядку — порядок важен, потому что поздние пункты предполагают, что ранние уже выполнены.

Сборка и качество

1. Доля сессий без сбоев выше 99,5% в Firebase Crashlytics или Sentry за последние 500 сессий. 2. Холодный старт менее 2 секунд на самом медленном поддерживаемом устройстве. 3. Никаких текстов-заглушек на экранах, доступных с холодной установки. 4. Каждая кнопка действия в онбординге ведёт в реальное место, включая финальный экран «успех».

Приватность и соответствие требованиям

5. URL политики конфиденциальности работает по HTTPS и соответствует данным, собираемым в приложении. 6. Карточка App Privacy в App Store Connect заполнена и совпадает с политикой. 7. PrivacyInfo.xcprivacy закоммичен и успешно проверен Xcode. 8. Каждая сторонняя SDK (Firebase, Adjust, Mixpanel, Crashlytics и т. д.) указана с описанием целей использования. 9. Текст ATT-промпта соответствует рекомендациям Apple, а не собственной формулировке. 10. Экран согласия на использование ИИ отображается до первого вызова LLM и содержит информацию о провайдере.

Метаданные

11. Скриншоты соответствуют загружаемой сборке, которую вы отправляете. 12. В названии, подзаголовке, ключевых словах и описании отсутствуют упоминания конкурентов. 13. Анкета возрастного рейтинга заполнена и обновлена с учётом новых категорий 2025 года (13+/16+/18+). 14. Support URL и email работают и регулярно проверяются. 15. Локализация выполнена для всех регионов, выбранных в разделе «Цены и доступность».

Тестирование и поддержка ревьюера

16. Реквизиты демо-аккаунта заполнены в поле App Review Information, рабочая проверка проведена за 5 минут до подачи. 17. Review notes объясняют любой неочевидный сценарий (например, «Чтобы увидеть AI-тьютора, нажмите Library → Tutor → Start Session»). 18. Сборка TestFlight (iOS) или Closed Testing (Android) тестировалась минимум 7 дней на реальных пользователях. 19. Стейджинг бэкенда полностью совпадает с продакшеном и работает на той же инфраструктуре во время модерации.

Особенности платформ

20. Sign in with Apple реализован, если используется сторонний способ входа. 21. Target API 35+ на Android, с проверкой устаревших API. 22. Форма Data Safety заполнена для каждой SDK и соответствует действительности. 23. Типы foreground-сервисов задекларированы в манифесте Android. 24. Правила категории Kids (родительский контроль, запрет поведенческой рекламы, отсутствие сторонней аналитики) соблюдены, если применимо. 25. Export compliance указан честно в App Store Connect.

Apple vs Google — шпаргалка для релиз-менеджера

Два стора выглядят похоже, но работают совершенно по-разному. Держите в голове такую модель:

Apple — ручная модерация, ссылки на правила, строгие метаданные. Ожидайте персонального ревьюера, точную ссылку на гайдлайн в каждом отказе и высокие требования к скриншотам, описаниям и демо-аккаунтам. Главное препятствие — до публикации.

Google — автоматизация first, системные политики, контроль после публикации. Опубликоваться можно за часы, но Play Integrity API, проверки Data Safety и политические боты всё равно проверяют. Баны приходят через дни или недели после одобрения — без предупреждений. Храните логи.

Privacy manifest, ATT и экран согласия на ИИ

Приватность — вторая по популярности причина отказа и самая быстрорастущая категория. Большинство команд сталкиваются с трудностями на трёх ключевых элементах.

Privacy manifest. PrivacyInfo.xcprivacy — это plist-файл, который находится в таргете вашего приложения и отдельно в каждой сторонней SDK, поставляемой вместе с ним. В нём нужно указать каждый тип собираемых данных, цели их сбора (аналитика, работа приложения, персонализация, реклама), все трекинговые домены и для каждого API с обязательным обоснованием доступа (UserDefaults, временные метки файлов, объём диска, время загрузки системы, доступ к клавиатуре) — соответствующий код причины. Xcode проверяет файл при сборке архива, а App Store Connect — при загрузке.

App Tracking Transparency. Если вы используете IDFA или передаёте идентификаторы рекламным сетям, вы обязаны вызвать ATTrackingManager.requestTrackingAuthorization с системным запросом. Текст в поле purpose в Info.plist должен соответствовать требованиям Apple — никаких провоцирующих формулировок, типа «Включите трекинг, чтобы открыть премиум» или угроз. Средний уровень согласия по миру — около 25–30%; при планировании атрибуционного стека учитывайте, что 70% пользователей откажутся.

Экран согласия на использование ИИ (появился в конце 2025). Перед первым обращением к любой сторонней LLM или речевой API покажите понятный экран согласия, в котором (а) указан провайдер, (б) перечислены передаваемые персональные данные, и (в) предложен реальный способ отказаться. Одной фразы «Продолжая, вы соглашаетесь с условиями» уже недостаточно.

Сквозной процесс подачи: неделя за неделей

Реалистичный таймлайн для первой подачи, если приложение уже полностью готово по функционалу:

Week 0  Dev accounts opened, DUNS requested, target API upgraded
Week 1  Privacy policy drafted, ATT copy finalized, SDK audit done
Week 2  Privacy manifest completed, AI-consent screen shipped
Week 3  TestFlight + Closed Testing (Play) opened to real testers
Week 4  Screenshots, icons, localized metadata, age rating filled
Week 5  Demo account + review notes prepared, final QA pass
Week 6  Submission: App Store + Play production track
Week 6+ Response within 24-72h; fix & resubmit in 3-5 days if needed

Как работать с письмом об отказе — и как точно не надо

Каждый отказ — это ссылка на конкретный пункт гайдлайна плюс краткая записка от ревьюера. Прочитайте её дважды, сами воспроизведите проблему, а затем напишите ответ, в котором (а) признаёте правило, (б) описываете, что вы изменили, (в) указываете ревьюеру точный путь, как проверить исправления, и (г) заканчиваете прямым вопросом: всё ли понятно или что-то осталось неясным. Избегайте оборонительного тона.

Хороший ответ: «Гайдлайн 2.1: Исправили сбой при холодном старте. Проблема была в гонке на SDK аналитики. В сборке 1.2.4 аналитика теперь запускается через dispatch на main queue. Как воспроизвести: запустить приложение, перейти в Library → Lesson 1. Демо-аккаунт: test@fora-soft.ru / password123».

Плохой ответ: «Мы считаем, что это к нашему приложению не относится. Пересмотрите, пожалуйста». — Получите тот же отказ, но с меньшим терпением.

Если вас действительно отклонили по неверному правилу, у вас есть одна формальная возможность подать апелляцию через App Review Resolution Center. Используйте её только в тех случаях, когда вы можете доказать, что модератор неправильно применил политику — а не чтобы убедить его, что ваш дизайн красивый.

Стоимость и сроки: во что реально обходится модерация

Сами по себе сборы копеечные — Apple Developer Program стоит 7 425 ₽ в год, Google Play — 1 875 ₽ единовременно. Реальная стоимость — это время инженеров на соблюдение требований и прохождение итераций.

Реалистичный бюджет первой подачи для небольшой команды — около 2–3 недель инженерного времени на выполнение задач по compliance (privacy manifest, форма Data Safety, согласие на ИИ, апгрейд target API) плюс один-два цикла отказов. Используя agent-engineering, мы обычно сокращаем этот срок до 6–10 дней — потому что большинство пунктов из чек-листа автоматизируем.

Для аккаунта организации добавьте 5–30 рабочих дней на бесплатный запрос DUNS у Dun & Bradstreet; без него Apple не оформит компанию. Для нового личного аккаунта Google Play добавьте 14-дневное окно закрытого тестирования, прежде чем можно будет публиковать приложение в магазине.

Фреймворк решения — выберите путь релиза за пять вопросов

В1. Личный аккаунт или организация? Если приложение привязано к юрлицу, контрактам или платной дистрибуции — выбирайте аккаунт организации и закладывайте время на DUNS. Личные аккаунты проще открыть, но потом с ними сложнее: в листинге будет указано ваше имя, деньги за покупки пользователей придут на физлицо, а ответственность по соблюдению правил — на вас лично.

В2. Какова ваша экспозиция в ЕС? Поставка пользователям в ЕС после вступления в силу DMA означает выбор: использовать внешние платежи (меньше комиссии, но больше работы), web-дистрибуцию или альтернативные магазины приложений (большая аудитория, но нужна нотаризация) или остаться в App Store с IAP. Каждый из этих вариантов меняет состав документов для подачи.

В3. Интегрируете ли вы сторонний ИИ? Если да — экран согласия на использование ИИ обязателен на iOS. Делайте его с самого начала, а не добавляйте за неделю до подачи приложения.

В4. Ваше приложение в чувствительной категории? Kids, здоровье, финансы, гемблинг, дейтинг — каждая из этих категорий требует усиленной модерации, дополнительных документов и соблюдения региональных правил. Запланируйте на проверку вдвое больше времени и подключите юристов до подачи, а не после.

В5. Нужно ли вам выйти в конкретный день? Если да — подавайтесь за 14 дней, держите задокументированный план ускоренной модерации и резервный маркетинговый план на случай, если сроки одобрения сдвинутся. Не привязывайте анонс запуска к ненадёжным срокам — это самая частая причина провала в день старта.

Пять типичных ошибок, на которые наступают каждый квартал

1. Хардкоженные стейджинговые URL в проде. Ревьюер видит 500-ю ошибку, потому что вы забыли поменять API-эндпоинт. Запустите pre-flight-скрипт, который проверяет, что все URL в релизной сборке указывают на прод.

2. Политика конфиденциальности, которая не совпадает с манифестом. Карточка App Privacy, файл PrivacyInfo.xcprivacy и опубликованная политика должны быть одинаковыми. Любое несоответствие — это нарушение пункта 5.1.1. Генерируйте все три документа из единого источника — YAML-файла в репозитории.

3. SDK, которые тихо обновляются и добавляют трекинг. Даже незначительное обновление рекламной или аналитической SDK может незаметно начать собирать новые данные. Фиксируйте версии SDK и проверяйте privacy manifest при каждом релизе, а не только один раз.

4. Злоупотребление Accessibility Service на Android. Использование Android Accessibility Service для автоматизации кликов, напоминаний или управления приложениями приведёт к бану, а не просто к отказу. Если вам нужны такие возможности — используйте MediaProjection, Notification Listener или паттерны на базе ContentProvider.

5. Полупустые review notes. «Приложение для видеоконференций» — это не review notes. Напишите для ревьюера один абзац-экскурсию: что делает приложение, как залогиниться, какой флоу демонстрирует ядро ценности и какие необычные пермишен-промпты будут. Экономит один раунд обмена в 80% случаев.

KPI: как измерять здоровый релизный пайплайн

KPI качества. Доля одобрений с первого раза (цель — более 70% после третьего релиза), доля сессий без сбоев на момент подачи (более 99,5%) и количество аномалий в диффе privacy manifest между релизами (цель — ноль необъяснённых изменений).

Бизнес-метрики. Количество календарных дней от code-freeze до запуска (цель — менее 10 дней), частота релизов на приложение за квартал (цель — 6–12) и стоимость отказов в часах инженерного времени на релиз (цель — менее 8 часов).

KPI надёжности. Частота экстренных исправлений после выхода релиза (цель — менее 1 на релиз), доля отзывов вроде «зачем приложению этот доступ?» (цель — менее 0,5% от всех отзывов) и доля ускоренных проверок, одобренных при запросе (цель — более 50%).

Когда подавать заявку ещё рано

Соблазн «просто попробовать», когда вы уже близко, велик — но преждевременный отказ обойдётся дороже, чем неделя, которую вы могли бы сэкономить. Подождите ещё один цикл, если верно хоть что-то из этого: доля сессий без сбоев ниже 99%, вы не провели 7+ дней TestFlight или Closed Testing с реальными пользователями, политика конфиденциальности и privacy manifest не совпадают построчно, у бэкенда ещё нет стейджингового «review mode» с детерминированными seed-данными или в команде нет ясного владельца коммуникации с ревьюером. Сначала закройте эти проблемы — одна чистая подача дешевле трёх грязных.

FAQ

Что почитать дальше

Готовы выпустить чистую первую подачу?

Модерация — это игра в подготовку. Команды, которые публикуют приложения быстрее всех, — не самые опытные, а те, кто относится к privacy manifests, демо-аккаунтам и review notes как к первоклассным артефактам релиза, а не как к срочным задачам последней недели. Чек-лист выше — тот, по которому Фора Софт проходит на каждом мобильном релизе; пройдите его по порядку, и доля одобрений с первого раза должна превысить 70% в течение трёх циклов.

Если вы создаёте новое приложение, обновляете существующее под правила 2026 года или просто не можете выйти из цикла отказов — мы с радостью проведём аудит и подготовим план исправлений. Два часа нашей работы обычно экономят вам недели.