Почему Apple отклоняет приложения: чек-лист перед отправкой в App Store, чтобы не потерять недели на повторных проверках

Приложение готово, но релиз сорван отказом проверки. Каждый круг исправлений сдвигает запуск и маркетинговую кампанию. Здесь разобрано, почему Apple отклоняет приложения, глазами руководителя проекта, а не разработчика. Это чек-лист «как проверяющий»: что проверить за неделю до отправки и что заложить в план запуска и в бизнес-модель, включая оплату внутри приложения, удаление аккаунта и приватность по GDPR. Это не пересказ всей документации Apple, а где есть ссылка на раздел, сверяйте текущую редакцию правил.

Почему Apple отклоняет приложения: чем отказ в App Store дороже, чем кажется

Отказ это не только задержка на несколько дней. Это сорванная дата кампании, второй круг тестирования, разговор с теми, кому назвали день запуска, а иногда и смена плана для всей команды. Apple публикует правила проверки приложений (на английском), и большинство отказов приходит из нескольких разделов, которые легко проверить заранее. Apple смотрит приложения как покупатель, а проверяющие читают правила построчно. Сроки проверки мы здесь не называем, потому что они меняются, поэтому закладывайте запас в план, а не ориентируйтесь на цифру.

Что показывают собственные цифры Apple об отказах

Масштаб показывает отчёт Apple App Store Transparency Report за 2025 год (на английском). Apple проверила 9 100 620 заявок и отклонила 2 093 244, примерно 23%, а 387 087 заявок одобрили после отказа. По разделам правил на Performance пришлось 1 354 418 отказов, на Legal 495 673, на Design 415 532 (сюда входят копии, минимальная функциональность и спам), на Business 283 820 и на Safety 151 159. Одна заявка может не пройти сразу по нескольким разделам, поэтому суммы не равны общему числу. Другие материалы называют долю отказов 35-40% без источника, поэтому берите цифры Apple. Лидирует Performance, и это согласуется с разделом 2.1: падения, неполные сборки и нерабочий демо-доступ предотвратить дешевле всего. Чек-лист перед отправкой в App Store ниже и запас на проверку вместо жёсткой даты показывают, как пройти проверку App Store без повторных кругов, а причины отказа в App Store начинаются именно здесь.

Стабильность и полнота: что проверяют на реальных устройствах

Чего требует раздел 2.1

Раздел 2.1 о полноте приложения говорит, что на проверку отправляют финальные версии со всеми метаданными и рабочими ссылками, без текстов-заглушек и пустых сайтов, а приложение протестировано на устройстве на ошибки и стабильность. Apple отклоняет неполные сборки и приложения, которые падают или показывают очевидные технические проблемы. Если есть встроенные покупки, они тоже должны быть завершены и работать. Перед отправкой установите сборку на несколько реальных устройств, пройдите основные пути и уберите всё временное. Это первый пункт: чек-лист перед отправкой в App Store начинается именно с него, и он самый дешёвый в исправлении. Это же способ, как не получить отказ в App Store по самым простым причинам.

Демо-аккаунт и инструкция для проверяющего

Если в приложении есть вход, правила просят приложить данные демо-аккаунта и включить серверную часть. Если дать демо-аккаунт нельзя по юридическим причинам или из-за безопасности, можно предложить встроенный демо-режим с предварительного согласия Apple, и он должен показывать все функции. Отказ App Review из-за отсутствия демо-аккаунта одна из самых частых и самых устранимых причин отказа. Положите демо-аккаунт для проверяющего и короткую записку в заметки для проверки. Убедитесь, что он работает в день отправки.

Что проверить перед отправкой	Почему это важно	Кто отвечает
Сборка проверена на реальных устройствах	Падения и видимые ошибки отклоняют	Руководитель QA
Демо-аккаунт и серверная часть включены	Проверяющий должен дойти до каждой функции	Владелец продукта
Нет текстов-заглушек и пустых ссылок	Неполные приложения отклоняют	Ответственный за контент
Политика приватности и описание данных	Приватность проверяют на ревью	Юридический контакт
Оплата через встроенные покупки там, где требуется	Правила платежей соблюдаются строго	Владелец продукта

Минимальная функциональность: когда «сайт в обёртке» не проходит

Раздел 4.2 короткий. Он говорит, что приложение должно включать функции, контент и интерфейс, которые поднимают его выше упакованного заново сайта. Как пройти проверку App Store по разделу 4.2? Отказ по минимальной функциональности чаще всего получает сайт в оболочке без причин существовать как приложение, и именно эти причины, по которым Apple отклоняет приложения, самые упорные. Чтобы пройти, дайте приложению то, что сайт не умеет так же хорошо: камеру, уведомления, работу без сети, сохранённые настройки или сценарий, придуманный для телефона. Перед стартом спросите, что приложение делает, чего не делает сайт. Это чек-лист правил проверки App Store в одном вопросе. Как держать эту ценность со временем, показывает наш разбор сроков разработки мобильного приложения.

Приватность: политика, описание данных, удаление аккаунта, GDPR

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

Платежи и подписки: что должно идти через встроенные покупки

Если приложение открывает функции или контент внутри себя, правила раздела 3.1 ожидают встроенных покупок, с исключениями, которые меняются, поэтому читайте текущую редакцию. Отказ App Review по платежам обидно получать. Платёжный путь, который уводит пользователей из приложения купить цифровую функцию, типичная причина отказа. Правила платежей дороже всего исправлять поздно. Решите рано. Решите это на этапе бизнес-модели, а не после сборки: это влияет на цену, маржу и экраны подписки. Если платёжный путь ломается во время проверки, может провалиться вся отправка.

Карточка приложения: скриншоты и описание без лишних обещаний

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

План релиза с запасом на проверку

1. За неделю до отправки: пройдите чек-лист и протестируйте на реальных устройствах.
2. Отправьте сборку с демо-аккаунтом, описанием приватности и заметками для проверки.
3. Держите дату кампании гибкой с запасом на один возможный отказ.
4. Если пришёл отказ, прочитайте указанный раздел, устраните причину и ответьте проверяющему.
5. После релиза запланируйте обновления и поддержку, чтобы следующая версия тоже прошла.

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