Відхилення App Store за 2.1 App Completeness: план тестування релізної збірки перед повторною подачею (2026)

Відхилення App Store за пунктом 2.1 App Completeness означає, що перевіряльник не зміг користуватися вашим застосунком так, як це робив би клієнт. Можливо, застосунок упав, показав шаблонний контент, заблокував його на екрані входу або приховав вбудовану покупку. Рідко буває так, що все виправляє один рядок коду. Перш ніж подавати повторно, проженіть короткий план тестування на релізній збірці — з чистого встановлення й з тими самими обліковими даними, які ви надаєте App Review. У цій статті ми розберемо цей план і покажемо, як інші розробники виправляли таке саме відхилення.

Що перевіряє пункт 2.1 App Completeness правил App Store?

Пункт 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-збірка працює не так, як копія перевіряльника. Перевіряльник встановлює релізну збірку з дистрибутивним підписом на чистий пристрій — без збереженої сесії та без debug-скорочень.

У вашому симуляторі ви вже увійшли. Локальний API може дивитися на staging-сервер, який ніколи не падає. Debug-прапорці пропускають пейвол, а feature-прапорці за замовчуванням увімкнені. У перевіряльника нічого цього немає. На сторінці перевірки 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. Відкрийте кожну вбудовану покупку. Увійдіть як новий акаунт. Перевірте, що кожен продукт, поданий разом із версією, відображається з ціною, його можна купити в пісочниці (sandbox), а 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». Розробник повідомив: «It passed after adding : NSUserTrackingUsageDescription».
• Входи через соцмережі, якими перевіряльник не зміг скористатися. Розробник на Apple Developer Forums повідомив про повторні відхилення за 2.1, бо перевіряльники «were unable to use social logins» (не змогли скористатися входом через соцмережі). Він надав демо-акаунти Apple і Google, але вхід через Apple ID вимагав коду підтвердження, який надходив на телефон розробника. Співробітники Apple відповіли, що App Review зв’яжеться з ним напряму. Публічного рішення так і не опублікували.
• Вбудовані покупки «could not be found in the submitted binary». У треді спільноти 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 часто повертаються в наступних оновленнях: новий feature-прапорець, змінений API-ключ або прострочений демо-акаунт. Додайте цей план тестування до свого релізного процесу разом із чеклістом подачі в App Store. Для оновлень поетапний реліз обмежує кількість користувачів, яких зачепить пропущений баг. Щоб отримати друге фахове рішення щодо відхиленої збірки, напишіть на yagyeshsrbobde@gmail.com і додайте повідомлення про відхилення.