Як опублікувати застосунок у Google Play: реальні кроки в Play Console

Щоб опублікувати застосунок у Google Play, зареєструйте обліковий запис розробника Google Play (разова плата 25 USD станом на листопад 2026 року), створіть застосунок у Play Console, заповніть сторінку в магазині та форми App content, завантажте Android App Bundle (.aab) у канал тестування, а потім випустіть його в продакшн після перевірки Google. Якщо у вас новий особистий обліковий запис, є один додатковий крок: закритий тест щонайменше з 12 тестерами протягом 14 днів поспіль, перш ніж подати заявку на доступ до продакшену. Цей посібник проходить кожен екран по порядку і пояснює деталі, які найчастіше спричиняють затримки.

Якщо ви ще не створили застосунок, почніть з як зробити застосунок для Android.

Перш ніж почати: що потрібно

• Застосунок у вигляді Android App Bundle (.aab). Google Play вимагає цей формат для нових застосунків.
• Актуальний цільовий рівень API. Станом на листопад 2026 року нові застосунки й оновлення мають орієнтуватися на Android 16 (рівень API 36).
• Політика конфіденційності за публічною веб-адресою. Це має бути звичайна веб-сторінка, а не PDF, і вона не повинна бути за логіном.
• Іконка, скріншоти та графіка для картки. Актуальні розміри перевірте в Play Console; на момент написання іконка має 512 × 512 пікселів, а графіка для картки — 1024 × 500.
• Електронна адреса підтримки.
• Державний документ, що посвідчує особу, і картка на ваше юридичне ім'я для реєстрації. Передплачені картки не приймаються.

Крок 1: Створіть обліковий запис розробника

Перейдіть до Play Console і зареєструйтеся. Ви обираєте один із двох типів облікового запису:

• Особистий. Для фізичних осіб. Ви підтверджуєте особу та доступ до пристрою Android через мобільний застосунок Play Console і виконуєте вимогу тестування, описану в кроці 6.
• Організація. Для зареєстрованих бізнесів. Перевірка вимагає даних про компанію і триває довше, але вимоги щодо 12 тестерів немає.

Вам має бути щонайменше 18 років. Плата 25 USD сплачується один раз і не повертається, якщо Google вважає ваші дані недійсними, тож введіть юридичне ім'я точно так, як воно вказано у вашому документі.

Крок 2: Створіть застосунок

У Play Console натисніть Create app і заповніть:

• Назву застосунку так, як її бачитимуть користувачі.
• Мову за замовчуванням.
• Застосунок або гра.
• Безкоштовний чи платний. Платний застосунок можна пізніше змінити на безкоштовний, але не навпаки.
• Декларації: погодьтеся з Політикою програми для розробників, законами США про експорт і умовами Play App Signing.

Імʼя пакета (на кшталт com.yourcompany.yourapp) задає ваше перше завантаження, і його не можна ні змінити, ні використати повторно, тож обирайте його уважно, якщо створюєте застосунок самостійно.

Крок 3: Напишіть сторінку в магазині

Відкрийте сторінку Main store listing (у розділі Store presence в лівому меню) і додайте:

• Назву застосунку, до 30 символів.
• Короткий опис, до 80 символів. Часто саме його й читають, тож починайте з того, що робить застосунок.
• Повний опис, до 4 000 символів. Поясніть, для кого застосунок, основні функції та все, що користувачі мають знати, простою мовою. Не напихайте ключовими словами; політика Google це забороняє.
• Графіку: іконку, графіку для картки і скриншоти телефону. Справжні екрани застосунку, а не макети функцій, яких немає.
• Категорію та контактні дані.

Крок 4: Заповніть форми App content

Відкрийте сторінку App content (у розділі Policy в лівому меню). Кожен пункт потребує відповіді, перш ніж можна буде випустити застосунок:

• URL політики конфіденційності.
• App access. Якщо частини застосунку потребують логіну, дайте рецензентам робочі облікові дані. Відсутній логін — типова причина відмови.
• Реклама. Вкажіть, чи показує застосунок рекламу, зокрема через сторонній код.
• Рейтинг контенту. Анкета, яка формує вікові рейтинги для кожного регіону. Якщо її пропустити, застосунок буде «Unrated», що блокує випуск.
• Цільова аудиторія та контент. Вікові групи, для яких застосунок. Якщо до аудиторії входять діти, діють суворіші вимоги політики для сімей.
• Безпека даних. Які дані застосунок збирає або передає, навіщо, чи вони шифруються і чи можна їх видалити. Відповідайте за все в застосунку, включно з аналітикою і провайдерами входу.
• Інші декларації, як запропоновано, наприклад для застосунків про новини, здоров'я, фінанси чи держсервіси, або для чутливих дозволів, таких як SMS.

Будьте точними. Google порівнює ваші відповіді з тим, що застосунок справді робить.

Крок 5: Завантажте першу збірку у внутрішнє тестування

Відкрийте Internal testing (у розділі Testing в лівому меню), створіть реліз і завантажте .aab. Під час цього першого релізу налаштуйте Play App Signing: нехай Google згенерує й зберігатиме ключ підпису, якщо немає причин керувати ним самостійно. Додайте себе і кількох колег як внутрішніх тестерів за email, а потім розгорніть реліз. Тестери відкривають посилання для приєднання і встановлюють застосунок із Play Store.

Для кожного наступного завантаження потрібен вищий versionCode, ніж попередній.

Якщо ви збираєте з Mythex

На тарифі Pro Mythex збирає для вас AAB з опублікованого застосунку. Можна працювати двома способами:

1. Завантажити самостійно. Попросіть агента зібрати для Android, натисніть Download, коли картка покаже Ready to upload, і завантажте файл у Play Console. Файл залишається доступним для завантаження в Project settings приблизно 30 днів.
2. Під'єднати власний service account Google Play. Створіть service account і JSON-ключ у Google Cloud, запросіть його email у Play Console в розділі Users and permissions з доступом до цього застосунку і додайте ключ у Mythex. Відтоді кожна збірка Android автоматично йде у внутрішнє тестування з versionCode, вищим за все, що вже є в Google Play. Агент також може редагувати сторінку в магазині і запитує вас, перш ніж щось стане публічним, наприклад випуск у продакшн.

Створення застосунку (крок 2), форма Data safety і рейтинг контенту залишаються в Play Console; агент повідомить, якщо якоїсь із них бракує. Більше — на сторінці конструктора Android-застосунків Mythex.

Крок 6: Проведіть закритий тест (нові особисті облікові записи)

Якщо ваш особистий обліковий запис створено після 13 листопада 2023 року, ви мусите провести закритий тест щонайменше з 12 тестерами, які 14 днів поспіль залишаються підписаними, перш ніж подати заявку на доступ до продакшену. Той, хто вийшов і повернувся, починає відлік 14 днів заново.

Практичні поради:

• Набирайте більше ніж 12. Частина відпадає. Прагніть до 15–20.
• Використовуйте групу Google або список email для керування тестерами.
• Просіть реального використання, а не лише встановлення. Google запитує про ваше тестування під час подачі заявки, і ви навчитеся набагато більше.
• Випустіть оновлення під час тесту з виправленнями за відгуками.

Наш посібник з бета-тестування розповідає про набір і збір відгуків. Коли 14 днів минули, подайте заявку на доступ до продакшену з Dashboard і дайте відповіді про ваше тестування.

Крок 7: Випуск у продакшн

Коли доступ до продакшену відкрито, відкрийте Production у лівому меню:

1. Оберіть країни та регіони, де буде доступний застосунок.
2. Створіть новий реліз і додайте збірку з тестування або завантажте нову.
3. Напишіть примітки до релізу простими словами: що нового або виправлено.
4. Перегляньте і надішліть на перевірку. Зміни збираються в розділі Publishing overview, доки ви їх не надішлете.

Час перевірки різний. Оновлення часто проходять швидко; перші релізи можуть тривати кілька днів. Можна обрати managed publishing, якщо хочете самі схвалити момент, коли схвалений реліз стане доступним.

Крок 8: Після запуску

• Стежте за Android vitals щодо збоїв і звітів «застосунок не відповідає».
• Відповідайте на відгуки, особливо на ранні.
• Тримайте цільовий рівень API актуальним. Google підвищує його щороку, а застосунки, що відстають, перестають пропонувати новим користувачам на новіших телефонах.
• Оновлюйте форму Data safety щоразу, коли додаєте новий збір даних.

Для застосунку, обгорнутого у веб, як той, що зроблено в Mythex, більшість змін доходить до користувачів Android, коли ви публікуєте веб-застосунок, бо телефонний застосунок відкриває ваш опублікований застосунок. Новий випуск у магазині потрібен лише для таких речей, як іконка, назва, дозволи або новий цільовий рівень.

Типові причини відмови або затримки

• Немає робочого логіну для рецензентів.
• Політика конфіденційності відсутня, є у вигляді PDF або не відповідає відповідям у Data safety.
• Скриншоти або описи обіцяють функції, яких застосунок не має.
• Запит чутливих дозволів, яких застосунок явно не потребує.
• Зламаний або порожній застосунок: текст-заглушки, мертві кнопки.

Також публікуєте на iPhone?

Процес Apple інший: річне членство, TestFlight і людська перевірка кожного релізу. Ці кроки описано в як опублікувати застосунок в App Store.

Запитання