Застосунок готовий, дату запуску оголошено, а з App Store приходить відмова. Кожне повторне подання — це нове очікування, зсунутий реліз і рекламна кампанія, яку доводиться переносити. Добра новина в тому, що відмови здебільшого передбачувані: магазини відхиляють застосунки з тих самих причин, і їх можна усунути ще до першого подання.
Коротко
- У більшості відмов знайомі причини: збої, незавершений контент, відсутня політика конфіденційності, незрозумілі дозволи чи вхід без демо-акаунта.
- До модерації готуються заздалегідь: акаунти розробника, сторінка в магазині, розкриття даних, нотатки для рецензента й бета-тестування.
- Правила Apple і Google часто змінюються, тому перед кожним поданням варто звірятися з їхньою актуальною версією.
Як влаштована модерація
Перш ніж застосунок зʼявиться в магазині, його перевіряють на відповідність правилам платформи. Apple перевіряє кожну нову версію за настановами App Review Guidelines, і в цьому процесі беруть участь живі рецензенти. Google поєднує автоматичні й ручні перевірки та звіряє застосунок із правилами для розробників (Developer Program Policies).
Час перевірки різниться: він залежить від платформи, типу застосунку й того, чи це перше подання. Тому в плані запуску завжди варто мати запас, а маркетингову дату не привʼязувати до дня подання.
Відмова — не вирок. Зазвичай вона приходить із поясненням і посиланням на правило, яке порушено, тож проблему можна виправити й подати застосунок знову. Але кожне таке коло забирає час, тому пройти перевірку з першого разу завжди дешевше.
Чому застосунки відхиляють
Причини відмов повторюються з проєкту в проєкт. Ось типові з них.
- Збої та помилки. Застосунок падає під час запуску, зависає на ключовому сценарії або має кнопки, які нічого не роблять.
- Незавершений контент. Тексти-заглушки, порожні екрани, розділи «скоро буде» й тестові дані виглядають як недороблений продукт.
- Немає політики конфіденційності. Обидва магазини вимагають посилання на неї, а сама політика має чесно описувати, які дані ви збираєте.
- Дозволи без пояснення. Запит доступу до камери, геолокації чи контактів потребує чіткої причини, зрозумілої користувачеві в момент запиту.
- Платежі за цифрові товари. Цифровий контент і підписки зазвичай треба продавати через вбудовані покупки платформи, а винятки залежать від країни й типу застосунку.
- Вхід без демо-доступу. Якщо головні функції сховані за реєстрацією, а рецензент не має логіна, перевіряти йому нічого.
- Опис, що вводить в оману. Скриншоти й текст на сторінці показують функції, яких у застосунку немає.
Що підготувати до подання
Підготовка до модерації починається задовго до останньої збірки. Ось чотири речі, які варто мати готовими.
- Акаунти розробника. Apple Developer Program і Google Play Console вимагають реєстрації, оплати й перевірки особи чи компанії. Для акаунта організації знадобиться, наприклад, номер D-U-N-S, тож почніть заздалегідь.
- Сторінка в магазині. Назва, опис, скриншоти, іконка, вікова категорія й контакти підтримки мають відповідати реальному застосунку.
- Розкриття даних. В App Store Connect це розділ App Privacy, а в Google Play Console — розділ Data safety. Вони мають збігатися з політикою конфіденційності й тим, як працює застосунок, включно зі сторонніми бібліотеками (SDK) для аналітики чи реклами.
- Доступ для рецензента. Створіть демо-акаунт із правдоподібними даними й коротко опишіть у нотатках, як перевірити ключові функції. Обидві платформи мають для цього окремі поля.
Тестування й бета-версії
Рецензент бачить застосунок так, як його побачить користувач, тож тестуйте не лише в симуляторі, а й на реальних пристроях. Перевірте різні розміри екрана, старіші версії операційної системи, повільний інтернет і сценарій, коли користувач відмовляє в дозволі.
Бета-тестування ловить те, що пропустила команда. Для iOS це TestFlight: ви запрошуєте тестувальників, і вони встановлюють збірку ще до публікації. Перш ніж збірка потрапить до зовнішніх тестувальників, її перевіряє Apple, тож це ще й рання репетиція модерації. У Google Play є тестові треки — внутрішній, закритий і відкритий, — через які збірку отримують лише обрані люди.
Для нових особистих акаунтів розробника в Google Play діє окрема вимога: перш ніж опублікувати застосунок для всіх (production), потрібно провести закрите тестування з певною кількістю тестувальників протягом визначеного часу. Актуальні умови перевірте в Play Console і закладіть цей етап у графік.
Чек-лист
- Зареєструйте акаунти розробника Apple і Google ще під час розробки.
- Приберіть заглушки, тестові дані й незавершені розділи з фінальної збірки.
- Опублікуйте політику конфіденційності й заповніть App Privacy та Data safety відповідно до реальної роботи застосунку.
- Поясніть кожен запит дозволу простими словами в момент, коли він потрібен.
- Створіть демо-акаунт і напишіть для рецензента, як перевірити ключові функції.
- Протестуйте збірку на реальних пристроях, у TestFlight і тестових треках Google Play.
- Перевірте, що скриншоти й опис показують лише те, що застосунок справді вміє.
Як ми це робимо в IANKO
Ми думаємо про модерацію ще на етапі «Втілити ідею», а не за тиждень до запуску. Бізнес-аналітик фіксує, які дані й дозволи потрібні застосунку і навіщо, щоб політика конфіденційності та форми розкриття даних відповідали дійсності. QA-інженери й тестувальники перевіряють кожну збірку на реальних пристроях і через бета-тестування. А на етапі «Вивести до людей» ми готуємо сторінку в магазині, демо-доступ і нотатки для рецензента, щоб публікація в App Store і Google Play була запланованим кроком, а не лотереєю.
Підсумок
Відмова в App Store чи Google Play рідко буває випадковою: вона має відому причину, і більшість таких причин можна усунути ще до подання. Сприймайте підготовку до публікації як частину розробки, а не формальність наприкінці, і закладайте в план час на перевірку.