Почему Apple отклоняет приложение: причины и решения

Почему Apple отклоняет приложение? С этим сталкиваются многие компании при первом релизе, и обычно это не катастрофа. В сообщении об отказе указано, какое правило нарушено, и чаще всего причина техническая: приложение падает, не дан демо-аккаунт, нет политики конфиденциальности или приложение — просто копия сайта. Большая часть таких проблем исправляется за день-два.

Ниже разбираем самые частые причины App Store review rejection и отказов в Google Play, отдельно — сложные guideline 4.3 и 4.2, и что делать после отказа. Правила актуальны на 2026 год; сверяйтесь с официальными App Store Review Guidelines.

Как читать сообщение об отказе

В App Store Connect в сообщении указан номер правила (например, «Guideline 2.1 - Performance - App Completeness») и комментарий, иногда со скриншотом. Первый шаг — прочитать этот пункт в официальных правилах. Часто проверяющий прямо пишет, что увидел: «приложение падает при запуске», «вход не сработал».

Почему Apple отклоняет приложение: частые причины

2.1 — приложение не завершено

По данным Apple, к этому пункту относится более 40 процентов нерешённых проблем. Правило требует финальную версию, рабочие ссылки и отсутствие временного контента. Если есть вход — нужно дать демо-аккаунт и не выключать бэкенд.

Что делать: полный тест на устройстве, удалить тестовые данные, указать рабочий демо-логин в App Review Information.

5.1.1 — конфиденциальность

Ссылка на политику конфиденциальности должна быть и в App Store Connect, и внутри приложения на видном месте. Политика объясняет, какие данные собираются, кому передаются и как удаляются. Если в приложении можно создать аккаунт, обязательно и удаление аккаунта внутри приложения (5.1.1(v)).

2.3 — неточные метаданные

Скриншоты, описание и сведения о конфиденциальности должны соответствовать реальным возможностям. Обещание в карточке, которого нет в приложении, — повод для отказа.

4.8 — сервисы входа

Если в приложении есть вход через Google или Facebook, Apple требует равноценную альтернативу, соблюдающую приватность, например Sign in with Apple. Есть исключения, например приложения только со своей системой аккаунтов.

3.1.1 — оплата цифрового контента

Если внутри приложения продаётся цифровой контент или функции (премиум-режим, подписка, курсы), Apple, как правило, требует встроенные покупки (In-App Purchase). Для физических товаров и услуг вне приложения — доставка, такси, бронирование — можно использовать платёжные системы вроде Click или Payme.

Не тот отправитель

По данным Apple, приложения регулируемых сервисов — банки, криптовалюты, медицина, авиаперевозки — как правило, должно отправлять юрлицо, которое оказывает услугу. Если такое приложение отправлено из аккаунта разработчика или студии, его отклонят. Поэтому в таких проектах аккаунт с самого начала открывают на компанию — подробнее в статье Apple Developer: физлицо или организация. Сменить отправителя после отказа можно, но это означает новый аккаунт и перенос приложения.

Guideline 4.3 и 4.2: самые сложные отказы

4.3 — Spam

Пункт запрещает две вещи:

• (a) выпускать одно и то же приложение под несколькими Bundle ID — например, отдельное приложение для каждого города или филиала. Apple советует одно приложение с вариантами внутри;
• (b) приложения, неотличимые от уже широко представленных. Apple отдельно перечисляет перенасыщенные категории: простые таймеры, фонарики, обои и т. п.

Практический риск для бизнеса — шаблонные приложения. Если разработчик выпускает десятки приложений магазинов или ресторанов на одном коде, возможен отказ по 4.3 или 4.2.6.

4.2 — минимальная функциональность

Приложение должно давать больше, чем «переупакованный сайт». Приложения, которые просто открывают сайт в WebView, часто отклоняют по этому пункту. А 4.2.6 прямо говорит, что приложения из коммерческих шаблонов и генераторов отклоняются, если их отправляет не сам владелец контента.

Google Play отклонил приложение: что делать

В Google Play решение видно на странице Policy status в Play Console: какая политика нарушена и что сделать. По данным Google, при отклонении в магазине остаётся последняя успешно опубликованная версия, а при блокировке (suspension) приложение удаляется из магазина. Повторно отправлять, не исправив нарушение, не рекомендуется.

Частые причины:

• проверяющий не смог войти — нет логина в App access;
• декларация Data safety не совпадает с тем, что собирают приложение и SDK;
• есть регистрация, но нет удаления аккаунта в приложении и веб-ссылки;
• лишние или необоснованные разрешения;
• вводящая в заблуждение карточка.

Про сам процесс — как опубликовать приложение в Google Play.

После отказа: план действий

1. Прочитайте сообщение целиком и найдите пункт в официальном тексте.
2. Воспроизведите проблему — увидьте то, что видел проверяющий.
3. Исправьте и прокомментируйте — в App Store Connect коротко и конкретно напишите App Review, что изменено.
4. Если вас не так поняли — у Apple сначала объясните через App Store Connect, затем при необходимости подайте апелляцию в App Review Board; Apple просит одну апелляцию на отклонённую заявку. В Google апелляция подаётся со страницы Policy status.
5. Сделайте выводы — добавьте пункт в чек-лист перед релизом.

Apple также предлагает 30-минутные онлайн-встречи с App Review и ускоренную проверку для критических исправлений.

Как избежать отказа

• тестировать на реальных устройствах через TestFlight и закрытый тест;
• давать демо-аккаунт и держать бэкенд включённым;
• политика конфиденциальности, удаление аккаунта и корректный Data safety;
• отправлять приложение из аккаунта самой компании;
• вместо WebView-обёртки — настоящие мобильные функции.

Весь процесс — в статье как опубликовать приложение в App Store.

Проведём приложение через ревью

SyncLab разбирает причины отказа, вносит изменения, ведёт переписку с App Review и отправляет приложение повторно. Если приложение разрабатываем мы, публикация и прохождение проверки — бесплатно, в остальных случаях цена по запросу. Подробнее: публикация в App Store и Google Play и разработка мобильных приложений.

Частые вопросы