Публікація мобільного застосунку в магазині App Store — це відповідальний етап релізу, який нерідко перетворюється на справжнє випробування для розробників та власників бізнесу. На відміну від Google Play, де первинна перевірка значною мірою автоматизована, Apple застосовує комбінований підхід: автоматичне сканування коду поєднується з ретельним ручним тестуванням реальною людиною (App Review Team).
За статистикою Apple, понад 40% усіх відхилень трапляються через недотримання базових вимог щодо функціональності, конфіденційності чи дизайну. У цій статті ми детально розберемо найпоширеніші причини відмови App Store та надамо практичні поради, які допоможуть пройти модерацію з першої спроби.
1. Технічні збої, баги та нестабільна робота
Найпростіший і найшвидший спосіб отримати відмову — надати модераторам нестабільний збірку. Якщо застосунок завершує роботу з помилкою (повисає або «падає») під час первинного перегляду, перевірка зупиняється негайно.
Поширені помилки:
- Непрацюючі кнопки та білі екрани: відсутність відповіді на натискання елементів інтерфейсу або застрягання на екрані завантаження.
- Відсутність тестових даних: модератор не може увійти в застосунок, тому що форма авторизації вимагає логін та пароль, які розробник забув вказати в примітках (App Review Notes).
- Тестові посилання чи «заглушки»: використання у коді або на екранах тексту на зразок «Lorem Ipsum», тестових REST API серверів (localhost чи staging), які недоступні ззовні.
Як уникнути: Перед відправкою білду проведіть повне тестування на реальних фізичних пристроях з різними версіями iOS та роздільностями екранів. Обов’язково переконайтеся, що тестовий обліковий запис (Demo Account) активний, а тестові дані повністю заповнені.
2. Неповна або некоректна інформація (App Metadata)
Опис та текстово-графічне оформлення сторінки застосунку в App Store Connect проходять таку ж сувору перевірку, як і сам вихідний код.
Чому Apple відхиляє метадані:
- Невідповідність скріншотів: зображення на сторінці додатка не відображають його реальний інтерфейс або демонструють функції, яких немає у поточній версії.
- Згадка інших платформ: наявність назв чи логотипів «Android», «Google Play» або зображень смартфонів інших брендів у скріншотах чи описі.
- Непрацюючі посилання: вказані URLs для Політики конфіденційності (Privacy Policy) чи Технічної підтримки (Support URL) повертають помилку 404.
Як уникнути: Заповнюйте метадані максимально чесно та лаконічно. Детальніше про те, як правильно підготувати проєкт до релізу, налаштувати обліковий запис розробника та уникнути адміністративних затримок, описано у нашому матеріалі про покроковий гайд із публікації в App Store.
3. Порушення вимог щодо конфіденційності (Privacy & Data Safety)
Захист персональних даних користувачів — головний пріоритет екосистеми Apple. Нехтування правилами обробки даних гарантовано призведе до запиту на доопрацювання або повної відмови.
Основні вимоги:
- Запит на доступи (App Tracking Transparency): якщо ваш застосунок збирає дані для реклами чи аналітики, ви зобов’язані використовувати фреймворк ATT для отримання дозволу від користувача.
- Зрозумілі описи системних дозволів (Info.plist): коли додаток запитує доступ до геопозиції, камери, гелереї чи мікрофона, системне вікно має містити вичерпне пояснення, навіщо це потрібно (наприклад, «Доступ до камери потрібен для сканування QR-кодів замовлення»).
- Видалення акаунту: якщо у застосунку є можливість реєстрації, Apple вимагає надати користувачеві пряму та зрозумілу можливість повністю видалити свій обліковий запис разом із персональними даними безпосередньо з інтерфейсу додатка.
4. Обхід системи вбудованих покупок (In-App Purchases)
Apple суворо контролює монетизацію цифрового контенту та послуг. Якщо ваш продукт продає цифрові товари (підписки, преміум-функції, віртуальну валюту, доступ до матеріалів), розрахунки повинні здійснюватися виключно через систему In-App Purchase (IAP).
- Виключення: фізичні товари та послуги (доставка їжі, квитки на події, таксі, ритейл) можуть оплачуватися через зовнішні еквайринги (Stripe, LiqPay тощо).
- Помилка: розміщення в додатку посилань на зовнішні сайти для оплати передплати в обхід комісії Apple без відповідного офіційного дозволу (Reader App Entitlement).
5. Низька цінність або копіювання (Minimum Functionality)
Apple прагне підтримувати високий стандарт якості у своєму каталозі. Якщо застосунок не надає користувачеві унікального досвіду або є простою обгорткою для вебсайту, його буде відхилено за пунктом Guideline 4.2 – Minimum Functionality.
Що не пройде модерацію:
- Звичайний WebView, який просто відображає мобільну версію сайту без використання нативних функцій пристрою (push-сповіщення, офлайн-режим, нативна навігація).
- Застосунки-клони або шаблони, які масово дублюють вже наявний у магазині функціонал без суттєвих змін.
Чеклист підготовки перед відправкою на App Review
Щоб мінімізувати ризик відмови, пройдіть цей короткий чеклист безпосередньо перед натисканням кнопки «Submit for Review»:
[ ] Додаток протестовано на реальних iOS-пристроях, баги та зависання відсутні.
[ ] Створено активний тестовий акаунт для модераторів (вказано в App Review Notes).
[ ] Посилання на Privacy Policy є активним та відкривається у браузері.
[ ] Усі запити на доступи (камера, геопозиція) мають зрозумілі тексти пояснень в Info.plist.
[ ] Додано функціонал видалення облікового запису (якщо є авторизація).
[ ] Скріншоти відповідають поточній версії інтерфейсу та не містять символіки інших платформ.
Дотримання гайдлайнів Apple та уважність до деталей на етапі підготовки збережуть ваш час та дозволять випустити продукт на ринок точно в запланований термін.
