Чому публікація в Huawei AppGallery провалюється на модерації
Публікація в Huawei AppGallery провалюється не на коді, а на формальностях: застосунок зібрано, протестовано й він працює, а модерація повертає його з сухим формулюванням, яке ще треба розшифрувати.
Найчастіше причина — розбіжність із вимогами магазину застосунків: заявлені дозволи не збігаються з фактичною поведінкою.
Друга за частотою причина — підпис застосунку. Збірка релізу, підписана налагоджувальним ключем або ключем з іншого сховища, магазином не приймається.
Окрема пастка — зміна ключа між версіями: оновлення перестає встановлюватися поверх попереднього, і частина користувачів залишається на старій збірці.
Третій блок — картка застосунку: опис, скриншоти, іконка, віковий рейтинг, посилання на політику конфіденційності. Відсутність політики — майже гарантоване відхилення модерації, навіть якщо застосунок збирає мінімум даних. Неповна картка публікацію не блокує, але знижує позиції у внутрішньому пошуку магазину.
Ціна кожного провалу вимірюється не в годинах розробки, а в зірваному вікні запуску. Ітерація перевірки триває дні, правки потребують нової збірки й нового циклу очікування, реліз зсувається, а канал залучення, який уже почав розігріватися, охолоджується.
Розбираємо, що саме перевіряє модерація і як готувати збірку, щоб проходити її з першого разу.
Чим відрізняються вимоги магазинів застосунків одне від одного
Кожен магазин перевіряє свій набір правил, і збірка, що пройшла модерацію в одному, не гарантує приймання в іншому.
Відмінності магазинів застосунків стосуються підпису, цільової версії системи, складу картки та політики роботи з даними — повернення на доопрацювання надходять саме за цими пунктами.
Підпис і сертифікати
Майданчики по-різному ставляться до ключів: одні приймають збірку, підписану лише у вашому сховищі, інші вимагають додаткового підпису майданчика й окремого сертифіката. Окремий рядок — строк дії ключа: коли він спливає, оновлення перестають прийматися, навіть якщо код готовий.
Тому ключі заводимо із запасом за строком, зберігаємо поза репозиторієм, а релізний підпис перевіряємо до завантаження.
Склад картки й локалізація
Картка — друге джерело повернень: набір скриншотів під різні розміри екранів, тексти описів, віковий рейтинг, посилання на політику конфіденційності застосунку та розкриття складу даних, що збираються.
Локалізація описів на частині майданчиків обов'язкова для цільових регіонів, інакше картку не показують у добірках.
| Вимога | Відмінність між магазинами | Чим загрожує невідповідність |
|---|---|---|
| Підпис і сертифікати | Своя схема підпису й окремий сертифікат майданчика | Відхилення на етапі завантаження |
| Цільова версія системи | Свій мінімум за версією системи й набором дозволів | Оновлення не проходить перевірку |
| Політика конфіденційності | Публічне посилання обов'язкове, склад даних розкривається суворіше | Блокування картки до усунення |
| Картка й локалізація | Різний набір розмірів і вимог до перекладу | Повернення метаданих на доопрацювання |
| Перевірка збірки магазином | Ручний і автоматичний розбір займають різний час | Зсув дати релізу |
Правила публікації застосунку майданчики правлять регулярно, тому перед кожним релізом звіряємося з актуальною документацією Huawei AppGallery та інших магазинів, а не з торішніми чек-лістами.
Процес розміщення застосунку: від збірки до схвалення
Маршрут релізу в AppGallery будується навколо однієї ідеї: на момент завантаження збірки в магазин картка, підпис і дані акаунта розробника вже узгоджені між собою. Тоді проходження перевірки — це читання зауважень, а не перезбирання з нуля. Порядок, у якому ми ведемо публікацію:
- Аудит поточної збірки: вхід, оплата й сповіщення не мають залежати від сервісів, яких немає на пристроях Huawei, — їх закривають альтернативною реалізацією.
- Підготовка підпису: ключ створюється один раз і перевикористовується в усіх оновленнях, тому зберігається в захищеному сховищі, а не на ноутбуці інженера.
- Заповнення картки: назва, опис, скриншоти під потрібні роздільні здатності екранів, категорія, віковий рейтинг, політика конфіденційності та відомості про збір даних.
- Завантаження збірки в магазин: формат, зони розповсюдження й поетапне розкочування відсотками.
- Закрите тестування на обмеженому списку акаунтів — до появи застосунку у відкритій видачі.
- Проходження перевірки й випуск оновлення: відповіді на зауваження, публікація в загальний доступ, далі релізи за розкладом.
Закрите тестування перед релізом
Це не формальність, а спосіб упіймати те, що не видно на стенді: оновлення поверх попередньої версії, пристрої без звичних сервісів, різні діагоналі екранів.
Ми розділяємо встановлення «з нуля» й «поверх старої версії» та звіряємо звіти — регресії знаходяться раніше за потік нових встановлень.
Що робити при зауваженнях перевіряльника
Зауваження майже завжди вказує на розбіжність між карткою та поведінкою застосунку, тому відповідаємо не текстом, а новою збіркою або точним поясненням із записом екрана. Кожну ітерацію фіксуємо: версія збірки, причина відмови, що змінили — так перевірка не ходить по колу.
Режими випуску та строки перевірки в магазинах застосунків
Перша публікація й оновлення вже встановленого застосунку йдуть різними чергами перевірки: стартова версія проходить ручний розбір політик і магазин може дивитися її кілька робочих днів, оновлення поверх встановленого — зазвичай від кількох годин до двох діб.
Дату випуску ми завжди рахуємо від найгіршого строку й закладаємо вікно на правку зауважень модератора.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повний випуск | Версію перевірено, готові віддати її всім одразу | Відкат лише новою збіркою, помилка доходить до всієї аудиторії |
| Поетапний випуск | Великі зміни, є ризик збоїв на частині пристроїв | Розкочування частками з паузою між кроками |
| Закрите тестування | Нова функціональність до загального релізу | Обмежене коло учасників, окрема гілка збірки |
| Оновлення поверх встановленого | Допрацювання й дрібні правки | Політики перевіряють заново, частина користувачів відкладає встановлення |
Поетапний випуск і відкат версії
Поетапний випуск відкриває нову версію частками — наприклад, 5%, 20%, 50% і 100% з паузою між кроками.
Ми дивимося на частку успішних запусків і аварійних завершень у перші години: якщо показник просідає, розкочування зупиняється, і решта аудиторії залишається на попередній версії.
Відкат у магазинах не миттєвий: знизити версію не можна, тому заздалегідь тримаємо стабільну збірку-попередника й випускаємо її як оновлення. Користувацькі дані при цьому зберігаються, якщо схема зберігання сумісна, — це перевіряємо на закритому тестуванні до старту розкочування.
Артефакти релізу: збірки, ключі, доступи й регламенти
Після релізу в замовника залишається комплект, достатній, щоб випускати оновлення власними силами або з іншою командою: збірки, ключі, права в консолі розробника й регламенти. Нижче — що саме входить у передачу й як це зберігається.
- Підписані збірки — опубліковані пакети у форматах AAB і APK з номером версії, датою та контрольною сумою файлу.
- Сховище ключів підпису — сам ключ, паролі до нього й відбиток сертифіката: без них оновлення в магазині неможливе, а відновити ключ не можна.
- Доступи до консолі розробника — акаунт власника на замовнику, окремі ролі для розробки й тестування, контакт для листування з перевіряльниками.
- Інструкція з випуску — порядок дій: збірка, підпис, завантаження, заповнення картки, надсилання на перевірку, розбір зауважень.
- Регламент оновлень і підтримки — періодичність випусків, відповідальні, строк реакції на відмову та правила відкату на попередню збірку.
Передача доступів і ролей
Власником акаунта стає замовник — на свою юридичну особу й контактні адреси. Наші інженери залишаються з роллю розробника й мінімальним набором прав під двофакторною автентифікацією, а після завершення робіт доступ відкликається однією операцією, а не зміною пароля.
Регламент випуску оновлень
Регламент фіксує періодичність планових збірок, відповідальних і строк розбору відхиленої перевіряльниками версії.
Окремим пунктом — реакція на зміну вимог магазину, щоб оновлення правил публікації не перетворювалося на аврал, та порядок відкату, якщо свіжа збірка погіршила стабільність.
Кейс: реліз без відхилень і зростання встановлень з нового каналу
Що було до звернення
Замовник — сервіс доставки — двічі не пройшов перевірку в Huawei AppGallery: спершу набір дозволів був ширшим, ніж вимагали функції застосунку, потім фонова синхронізація запускалася без дії користувача.
Кожна ітерація означала перезбирання, нове обґрунтування для перевірки й очікування. Випуск розтягнувся на шість тижнів замість планових двох, а сам канал не приніс жодного встановлення.
Що змінили і що вийшло
Ми пройшли за вимогами майданчика рядок за рядком: залишили лише ті дозволи, без яких сценарій не працює, фонові задачі прив'язали до явної дії користувача, додали коректну обробку відмови у видачі прав.
Картку, скриншоти й опис привели до форматів майданчика, а збірку до надсилання прогнали за перевірками на тестових пристроях.
Третє надсилання пройшло з першого разу. Строк випуску — дев'ять робочих днів від старту робіт; за перший місяць з нового каналу прийшло 23% встановлень, частка відмов при запуску впала з 4,1% до 0,6%. Канал перестав бути експериментом і увійшов у регулярний план релізів.
«Раніше випуск у новий магазин був лотереєю. Тепер це планове завдання, як оновлення в основному каналі».
— керівник продукту замовника
Що робити, якщо публікацію в AppGallery відхилив модератор?
Відмова модератора — це завжди конкретне формулювання: код причини й текст зауваження в консолі розробника Huawei AppGallery.
Розбираємо його буквально: технічні причини (підпис збірки, набір дозволів, поведінка при запиті доступів) правляться в маніфесті, контентні (опис, скриншоти, категорія, віковий рейтинг) — у картці застосунку. Клас причини й задає обсяг виправлень.
Виправлення зауважень закінчується не правкою коду, а перевіркою за списком: відтворюємо сценарій, на який указав модератор, на чистому встановленні й на оновленні поверх попередньої версії.
Повторне подання збірки йде з піднятим номером — модерація звіряє його з відхиленою і ту саму збірку повторно не розглядає.
Якщо зауваження спірне, працює оскарження відмови магазину: додаємо відео сценарію, скриншоти екранів і посилання на пункт політики, який поведінку допускає.
Відповідь приходить за кілька робочих днів, і аргументоване звернення знімає зауваження частіше, ніж повторне подання без пояснень.
Окрема категорія — уже розгорнута збірка. Правки не повинні ламати сумісність: міграції даних і контракти обміну із сервером перевіряємо на оновленні з попередньої версії, інакше магазин прийме збірку, а користувачі отримають падіння.
Якщо ключі підпису втрачено, оновити наявний застосунок не можна — публікується новий з іншим ідентифікатором, і аудиторія з відгуками не переноситься.
Тому ключі тримаємо в захищеному сховищі з резервними копіями, а формулювання зауважень і відповіді модерації ведемо в журналі — це скорочує розбір відмови до годин.
Часті технічні запитання про розміщення й оновлення
Перед стартом замовники зазвичай ставлять один і той самий набір запитань: скільки чекати перевірку, що буде з відгуками при перенесенні, чи доведеться збирати окрему версію під кожен магазин і хто відповідає за оновлення після релізу. Нижче — короткі відповіді за нашим досвідом розміщення в Huawei AppGallery та інших каталогах.
Скільки триває перевірка і що найчастіше її гальмує?
Первинний розбір займає від кількох годин до трьох робочих днів, оновлення проходять швидше. Заявку повертають через невідповідність опису й функціональності, відсутність політики конфіденційності, зайві дозволи й тестові облікові дані, які не працюють у перевіряльника. Ми проходимо цей чек-ліст до надсилання — повернень стає в рази менше.
Чи можна перенести застосунок з іншого магазину разом з відгуками?
Технічно — так, збірку й метадані переносимо, застосунок продовжує працювати в наявних користувачів. Відгуки, рейтинг та історія встановлень не переносяться: вони прив'язані до запису в конкретному каталозі.
Рейтинг набирається заново, тому перші тижні після релізу ми особливо уважно опрацьовуємо зворотний зв'язок.
Чи потрібно збирати окрему версію під кожен магазин?
Так, і це нормальна практика. Окрема збірка підписується своїм ключем і підключає сервіси конкретного каталогу — сповіщення, карти, оплату, аналітику. Спільне ядро при цьому одне, тож підтримка кількох збірок не перетворюється на розробку кількох застосунків.
Що робити, якщо втрачено ключ підпису?
Ключ підпису — критичний артефакт, його резервна копія зберігається окремо від репозиторію, з обмеженим доступом. Якщо ключ утрачено або скомпрометовано, відновлення йде через підтримку каталогу з підтвердженням прав на запис.
Без резерву оновити встановлені копії не вийде — доведеться публікувати новий запис і заново збирати аудиторію.
Хто відповідає за оновлення після релізу?
Власник запису й прав на акаунт розробника — завжди замовник, це гарантія контролю над продуктом.
Ми ведемо технічну частину: стежимо за вимогами каталогу, перезбираємо під нові версії системи, закриваємо уразливості залежностей, проганяємо регрес і випускаємо оновлення з описом змін.
Обговорімо розміщення вашого застосунку в магазині
Оцінка завдання з публікації в AppGallery займає одну розмову, якщо в нас на руках є вхідні дані. Нижче — перелік того, що знімає майже всі питання на старті: план робіт будується за ним, а строки розміщення називаються вже без застережень «залежить від магазину».
- Збірка релізу: підписаний пакет, готовий до завантаження, номер версії, список змін для опису оновлення.
- Ключ підпису й порядок його зберігання — без доступу до нього оновлення й відновлення публікації перетворюються на окреме завдання.
- Доступ до акаунта розробника: роль із правом публікації, прив'язані сервіси, статус перевірки акаунта.
- Картка застосунку: іконка, графічні матеріали під різні розміри екранів, локалізації назви й опису, ключові слова.
- Політика конфіденційності та екрани згод — найчастіше саме це повертає застосунок на доопрацювання.
- Сервіси, від яких залежить робота застосунку на пристроях магазину: сповіщення, карти, оплата, вхід за акаунтом — що вже підключено і на якому етапі.
- Обмеження за строками: дата, до якої застосунок має бути доступний користувачам, із запасом на перевірку модератором.
- Поточні зауваження магазину, якщо публікацію вже відхиляли: текст відмови й матеріали з консолі розробника.
Із цим набором ми повертаємося з оцінкою завдання та планом робіт: що закриваємо зі свого боку, що потрібно від вас, скільки займає кожен етап і коли застосунок з'явиться в магазині. Опишіть завдання — обговоримо його предметно.
