Как опубликовать приложение в App Store и Google Play

Опубликовать приложение в App Store и Google Play — это не одна кнопка «загрузить», а цепочка: аккаунт разработчика, подпись сборки, страница в магазине, анкеты о данных, ревью и потом обновления. Каждое звено по отдельности несложное, но пропущенное звено стоит дней ожидания.

Ниже — порядок, в котором это делается, и места, где обычно спотыкаются.

Аккаунты разработчика

Нужно два аккаунта: Apple Developer Program и Google Play Console. Первое решение — на кого их заводить: на физлицо или на компанию. Это влияет на то, чьё имя увидят пользователи под названием приложения, и сменить владельца потом сложнее, чем кажется.

Для компании Apple попросит идентификатор организации и подтверждение, что ты вправе её представлять. Google проверяет личность и, для новых личных аккаунтов, требует закрытое тестирование с группой реальных тестировщиков, прежде чем откроет публикацию для всех. Закладывай на всё это недели, а не дни.

Ещё одно правило: аккаунты заводятся на почту компании, а не на личный ящик подрядчика. Приложение принадлежит тому, у кого доступ к аккаунту.

Подпись и сборки

Магазины принимают только подписанные сборки. Подпись доказывает, что обновление пришло от того же автора, что и первая версия.

• iOS. Сертификат разработчика, идентификатор приложения (bundle ID) и профиль, который их связывает. Xcode умеет делать это автоматически, и для начала этого хватает.
• Android. Ключ загрузки, которым ты подписываешь файл .aab, и ключ приложения, который хранит Google (Play App Signing). Потерянный ключ загрузки можно сбросить через поддержку, но лучше не проверять.

Ключи и пароли к ним хранятся в менеджере секретов команды, а не в репозитории и не на ноутбуке одного человека. Идентификатор приложения (com.company.app) выбирай один раз и навсегда: после публикации он не меняется.

Тестовые сборки до публикации

Прежде чем отправлять на ревью, раздай сборку живым людям: на iOS через TestFlight, на Android через внутреннее или закрытое тестирование в Play Console. Это те же механизмы, которые потом доставляют обновления, так что заодно проверишь сам процесс.

Тестировать стоит на реальных устройствах, включая старый недорогой Android. Эмулятор не покажет, как приложение ведёт себя без сети, с крупным шрифтом или после возвращения из фона.

Страница в магазине

Это лендинг, на который у тебя одна попытка. Что понадобится:

• название и короткое описание без обещаний, которые приложение не выполняет;
• скриншоты в нужных размерах для телефонов (и планшетов, если ты их поддерживаешь);
• иконка, ссылка на политику конфиденциальности и контакт поддержки;
• возрастной рейтинг — его определяет анкета, отвечай честно.

Отдельно — анкеты о данных: «App Privacy» у Apple и «Data safety» у Google. В них ты перечисляешь, какие данные собирает приложение и сторонние SDK внутри него. Аналитика и реклама тоже считаются. Расхождение между анкетой и реальным поведением — частая причина отказа.

Ревью и частые причины отказа

Apple смотрит каждую сборку руками, Google — в основном автоматически, с выборочной ручной проверкой. Отказывают обычно за одно и то же:

• приложение падает или виснет на первом экране;
• проверяющий не может войти — дай ему тестовый аккаунт в заметках к ревью;
• заглушки, «lorem ipsum», неработающие кнопки;
• приложение — просто обёртка над сайтом без собственной пользы;
• цифровые товары продаются в обход встроенных покупок;
• есть регистрация, но нет способа удалить аккаунт изнутри приложения.

Отказ — это не бан. Тебе пишут причину, ты исправляешь и отправляешь снова, а если не согласен — отвечаешь в той же переписке.

Обновления после публикации в App Store и Google Play

После первой публикации жизнь только начинается. Номер версии и номер сборки растут с каждой загрузкой — магазин не примет сборку с тем же номером.

Выкатывай постепенно: и Apple, и Google умеют раздавать обновление части пользователей. Если крэшей стало больше, выкатку можно остановить. Откатить приложение у тех, кто уже обновился, нельзя, поэтому сервер должен уметь работать со старыми версиями клиента ещё какое-то время. Полезно заранее предусмотреть экран «обнови приложение» для версий, которые поддерживать уже невозможно.

Коротко

• Аккаунты разработчика заводи на компанию и её почту, проверка займёт время.
• Ключи подписи и идентификатор приложения — навсегда, храни их как секреты.
• Тестируй через TestFlight и закрытое тестирование на реальных устройствах.
• Анкеты о данных должны совпадать с тем, что реально делает приложение и его SDK.
• Обновления выкатывай постепенно: откатить версию у пользователя нельзя.

Если не хочется проходить этот путь впервые на своём продукте, SUBXCAT может провести публикацию вместе с тобой.