Отказ App Store по 2.1 App Completeness: тест-план релизной сборки перед повторной отправкой (2026)

Отказ App Store по правилу 2.1 App Completeness означает, что проверяющий не смог пользоваться вашим приложением так, как это делал бы клиент. Возможно, оно упало, показало контент-заглушки, не пустило дальше экрана входа или скрыло встроенную покупку. Исправление редко сводится к одной строке кода. Перед повторной отправкой прогоните короткий тест-план на релизной сборке — с чистой установкой и теми же учётными данными, которые вы передаёте App Review. В этой статье мы разберём этот план и покажем, как другие разработчики исправляли такой же отказ.

Что проверяет правило App Store 2.1 App Completeness?

Правило 2.1 проверяет, что отправленная сборка — это готовое, работающее приложение. Нужны полные метаданные, рабочие ссылки, демо-вход, работающий бэкенд и встроенные покупки, которые проверяющий может найти и использовать.

App Review Guidelines от Apple делят 2.1 на две части. 2.1(a) гласит, что отправки «должны быть финальными версиями со всеми необходимыми метаданными и полностью рабочими URL», а текст-заглушки и пустые сайты нужно удалить. Там же сказано тестировать приложение на устройстве на ошибки и стабильность и «указать данные демо-аккаунта (и включить бэкенд-сервис!), если в приложении есть вход». Apple «отклонит неполные пакеты приложений и бинарники, которые падают или демонстрируют очевидные технические проблемы». 2.1(b) требует, чтобы встроенные покупки были «полными, актуальными, видимыми проверяющему и рабочими». Если настроенную покупку нельзя найти в приложении, объясните причину в заметках для проверки.

Это частый отказ. На странице Apple Preparing for App Review сказано: «В среднем более 40% нерешённых проблем связаны с правилом 2.1: App Completeness, которое охватывает падения, контент-заглушки, неполную информацию и многое другое».

Почему тестирование debug-сборки не выявляет проблемы по 2.1?

Debug-сборка работает не так, как копия у проверяющего. Проверяющий устанавливает релизную сборку с дистрибутивной подписью на чистое устройство — без сохранённой сессии и без отладочных обходных путей.

В вашем симуляторе вы уже вошли в аккаунт. Локальный API может смотреть на staging-сервер, который никогда не падает. Отладочные флаги пропускают пейволл, а фича-флаги по умолчанию включены. У проверяющего ничего этого нет. Страница Apple о проверке также просит «тщательно тестировать на устройствах с последней версией ПО», так что у проверяющего может стоять более новая iOS, чем на вашем тестовом телефоне.

TestFlight — самый близкий к условиям проверяющего вариант. Согласно обзору TestFlight, можно добавить до 100 внутренних тестировщиков из вашей команды в App Store Connect и до 10 000 внешних. Сборку можно тестировать до 90 дней. Загрузите ровно ту сборку, которую планируете отправить, установите её из TestFlight на устройство, где приложение ещё не запускалось, и тестируйте именно эту копию.

Что должен охватывать тест-план релизной сборки перед повторной отправкой?

Тест-план релизной сборки проверяет все места, где может застрять новый проверяющий: запуск, разрешения, вход, бэкенд, контент, ссылки, покупки, сбои сети и iPad. Выполняйте шаги по порядку на сборке из TestFlight и записывайте каждый результат, чтобы потом сослаться на него в заметках для проверки.

1. Чистая установка на последней iOS. Удалите предыдущую копию, установите приложение из TestFlight и запустите без сохранённого состояния. Сделайте три холодных запуска и убедитесь, что онбординг не падает.
2. Один раз отклоните каждый запрос разрешения. Откажите в уведомлениях, геолокации, камере и отслеживании. Приложение всё равно должно доходить до рабочего экрана. Также проверьте, что в Info.plist есть описание использования для каждого защищённого ресурса, к которому обращается приложение или его SDK.
3. Войдите с точными демо-данными. Скопируйте их из App Store Connect, а не из менеджера паролей. У аккаунта должны быть реалистичные данные, он не должен требовать подтверждения email и не должен использовать двухфакторную аутентификацию, привязанную к вашему телефону.
4. Убедитесь, что бэкенд продакшен и работает. Сборка должна обращаться к продакшен-эндпоинтам. Лимиты запросов, списки разрешённых IP и геоблокировка не должны отрезать проверяющего. Правило 2.1(a) прямо говорит включить бэкенд-сервис.
5. Пройдите каждую вкладку и экран. Ищите lorem ipsum, экраны «Скоро», пустые состояния без пояснений, тестовые картинки и кнопки, которые ничего не делают.
6. Нажмите каждую ссылку. Включая политику конфиденциальности, поддержку, условия использования и любые web view. Apple пишет: «Ссылка на поддержку пользователей с актуальной контактной информацией и ссылка на политику конфиденциальности обязательны для всех приложений».
7. Откройте каждую встроенную покупку. Войдите под новым аккаунтом. Проверьте, что каждый продукт, отправленный вместе с версией, отображается с ценой, покупается в песочнице, а восстановление покупок (Restore Purchases) работает.
8. Протестируйте на медленной или пропадающей сети. Включите авиарежим посреди сценария. Понятное сообщение об ошибке — нормально. Бесконечный спиннер или падение — нет.
9. Проверьте iPad, если поддерживаете его. Если приложение работает на iPad, запустите его там и убедитесь, что вёрстка не загоняет пользователя в тупик.

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

Как сопоставить сообщение об отказе по 2.1 с исправлением?

Чтобы сопоставить отказ по 2.1 с исправлением, прочитайте предложение после номера правила. Оно называет симптом, а каждый симптом указывает на конкретный шаг тест-плана.

Допустим, приложение-трекер привычек отклонено с сообщением «We were unable to review the app because it crashed on launch» («Мы не смогли проверить приложение, потому что оно упало при запуске»). Во втором замечании сказано, что проверяющий не смог найти встроенные покупки. В таблице ниже частые симптомы сопоставлены с причиной, тестом и исправлением.

Более общий подход к разбору любого сообщения об отказе описан в статье Отказ App Store: как исправить его по каждому правилу.

Как выглядели отказы по 2.1 у других разработчиков?

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

• Падение из-за отсутствующего описания использования. На форумах Solar2D разработчику ответили «We were unable to review the app because it crashed on launch» («Мы не смогли проверить приложение, потому что оно упало при запуске») на iPhone 13 mini с iOS 18.3.2, хотя в TestFlight приложение работало. Другой участник нашёл в приложенном логе падения: «This app has crashed because it attempted to access privacy-sensitive data without a usage description» («Приложение упало, потому что попыталось получить доступ к конфиденциальным данным без описания использования»). Разработчик сообщил: «Прошло после добавления NSUserTrackingUsageDescription».
• Вход через соцсети, которым проверяющий не смог воспользоваться. Разработчик на форумах Apple Developer рассказал о повторных отказах по 2.1, потому что проверяющие «не смогли воспользоваться входом через соцсети». Он предоставил демо-аккаунты Apple и Google, но вход через Apple ID требовал кода подтверждения, приходившего на телефон разработчика. Сотрудник Apple ответил, что App Review свяжется с ним напрямую. Публичного решения так и не опубликовали.
• Встроенные покупки «не удалось найти в отправленном бинарнике». В ветке сообщества RevenueCat разработчик получил отказ, потому что месячный тариф не нашли в бинарнике, хотя покупки в песочнице работали. Один из отвечавших рассказал, что похожий отказ удалось снять, ответив подробной инструкцией со скриншотами каждого пути к пейволлу. Сотрудники RevenueCat посоветовали показывать все отправленные продукты на пейволле по умолчанию и не включать тестовые файлы StoreKit в схему Archive.

Во всех трёх случаях собственное тестирование разработчика проходило успешно. Сбой проявлялся только с позиции проверяющего — без телефона для 2FA, без предыдущей сессии и без знания, где находится пейволл. Именно эту стартовую позицию и воссоздаёт тест-план выше.

Что писать в заметках для App Review после отказа по 2.1?

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

Страница Apple о проверке советует указывать данные аккаунта и особые настройки в разделе App Review Information. Если функция требует оборудования или окружения, которое сложно настроить, «будьте готовы предоставить демо-видео или само оборудование». Правило 2.3.1(a) добавляет, что новые функции нужно описывать в Notes for Review «конкретно», а «общие описания будут отклонены». Хорошо работает короткая структурированная заметка:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Если юридические требования или требования безопасности не позволяют дать демо-аккаунт, правило 2.1(a) допускает встроенный демо-режим, но только с предварительного одобрения Apple, и этот режим должен показывать все функции и возможности приложения. Не переходите на демо-режим без такого одобрения.

Как повторно отправить приложение или обжаловать отказ по 2.1?

Чтобы повторно отправить приложение после отказа по 2.1, загрузите или выберите протестированную сборку, ответьте App Review в App Store Connect с описанием изменений, обновите заметки для проверки и отправьте снова. Апелляцию подавайте, только если считаете, что проверяющий неправильно понял приложение.

1. Проверьте, что номер сборки, привязанной к версии в App Store Connect, совпадает с протестированной сборкой из TestFlight.
2. Ответьте на сообщение об отказе кратким описанием каждого исправления. Для проблем с покупками или навигацией добавьте пошаговую инструкцию и скриншоты.
3. Обновите раздел App Review Information актуальными учётными данными и заметками.
4. Отправьте на проверку. По состоянию на октябрь 2026 года Apple сообщает, что обычно проверяет «не менее 50% отправок менее чем за 24 часа и 90% — менее чем за 48 часов».

Если вы считаете, что Apple ошиблась, страница App Review позволяет подать апелляцию в App Review Board. Приведите конкретные доводы, почему приложение соответствует правилам, и «подавайте только одну апелляцию на каждую отправку, не прошедшую проверку». Впрочем, при отказе по 2.1 воспроизвести проблему на чистом устройстве обычно быстрее, чем спорить. Если хотите передать повторную отправку специалисту, наша услуга по публикации в App Store включает подготовку к проверке и работу с замечаниями по отказам в обоих магазинах за $599; взносы за аккаунт разработчика оплачиваются отдельно.

Проблемы по 2.1 часто возвращаются в последующих обновлениях: новый фича-флаг, сменённый API-ключ или истёкший демо-аккаунт. Добавьте этот тест-план в свой релизный процесс вместе с чек-листом публикации в App Store. Для обновлений поэтапный релиз ограничивает число пользователей, до которых дойдёт пропущенная ошибка. Чтобы получить второе мнение по отклонённой сборке, напишите на yagyeshsrbobde@gmail.com и приложите сообщение об отказе.