Приложение готово, дизайн утверждён, тестировщики довольны. Кажется, остался один клик, и пользователи уже скачивают продукт. На практике именно на этом этапе многие проекты застревают на недели.
Публикация приложения в App Store и Google Play — это не загрузка файла, а отдельный процесс со своими правилами, документами и рисками. Apple и Google проверяют не только код, но и политику конфиденциальности, описание, скриншоты, способы оплаты и даже то, как вы запрашиваете доступ к камере.
Ошибка в мелочи может стоить недели задержки. Если на запуск привязана рекламная кампания, анонс партнёрам или сезонная акция, такая пауза бьёт по бюджету напрямую.
В этой статье мы собрали практический опыт Likhachev Lab по выпуску мобильных продуктов. Вы узнаете, из каких шагов состоит публикация и сколько времени она занимает, какие аккаунты и документы нужны заранее, каким требованиям должны соответствовать сборка, метаданные и скриншоты. Отдельно разберём самые частые причины отказа и то, кто в проекте должен отвечать за релиз.
Материал рассчитан на владельцев бизнеса и маркетологов, поэтому без лишней технической глубины, но с конкретными цифрами и чек-листами, которые можно передать команде в работу.
Что входит в публикацию и сколько времени она занимает
Публикация — это цепочка из нескольких этапов: регистрация аккаунтов, подготовка сборки, заполнение карточки приложения, внутреннее и закрытое тестирование, отправка на ревью и выпуск. Каждый этап можно выполнить параллельно с разработкой, и это главный способ сэкономить время.
Ориентировочные сроки выглядят так. Аккаунт Apple Developer для организации оформляется от 2 до 14 дней, потому что нужен номер D-U-N-S. Аккаунт Google Play Console для организации проверяется от 2 до 7 дней. Ревью в App Store обычно занимает от нескольких часов до 2 дней, в Google Play первая проверка нового аккаунта может длиться до 7 дней.
Есть и особое требование Google для новых личных аккаунтов: перед выходом в продакшен нужно провести закрытое тестирование, как правило с группой минимум из 12 тестировщиков в течение 14 дней. Эти условия Google периодически обновляет, поэтому сверяйтесь с актуальной документацией в консоли.
Не планируйте релиз «день в день». Закладывайте минимум 3–4 недели от готовой сборки до публичного выхода, если аккаунты ещё не созданы, и 1–2 недели, если всё оформлено заранее.
Из чего складывается реальный график публикации:
- Регистрация аккаунтов и верификация организации — 1–3 недели.
- Подготовка метаданных, скриншотов и юридических страниц — 3–5 рабочих дней.
- Закрытое тестирование через TestFlight и Google Play Console — 1–2 недели.
- Отправка на ревью и исправление замечаний — 2–7 дней.
- Поэтапный выпуск и мониторинг ошибок — первые 48–72 часа.
Если у вас MVP, который нужно быстро показать рынку, лучше заранее заложить публикацию в план проекта. Мы разбираем такой подход на странице про разработку MVP: сторы входят в критический путь, а не в «финальные штрихи».
Подготовка аккаунтов разработчика и юридических документов
Самая частая причина срыва сроков — не код, а бумаги. Аккаунты нужно оформлять в первую очередь, пока команда ещё пишет функциональность.
Apple Developer Program стоит 99 долларов в год. Для организации потребуется юридическое лицо, номер D-U-N-S, официальный сайт с доменной почтой и полномочия подписанта. Apple может позвонить на указанный номер, поэтому контакты должны быть живыми.
Google Play Console берёт разовый взнос 25 долларов. Для организации нужны D-U-N-S и подтверждение контактных данных, для личного аккаунта — документ, удостоверяющий личность, и проверка телефона и устройства.
Регистрируйте аккаунты на компанию, а не на личную почту разработчика или подрядчика. Иначе при смене команды вы рискуете потерять контроль над приложением, отзывами и историей релизов.
Юридический минимум, без которого ревью не пройти:
- Политика конфиденциальности на публичном URL с описанием, какие данные вы собираете и зачем.
- Условия использования и пользовательское соглашение, особенно при подписках и платежах.
- Контакт поддержки: страница или email, который реально отвечает.
- Декларация о данных: App Privacy в App Store Connect и Data Safety в Google Play Console.
- Возможность удаления аккаунта, если пользователь может зарегистрироваться в приложении.
Отдельно проверьте, что описание сбора данных в формах сторов совпадает с реальным поведением приложения. Подключённые SDK аналитики, рекламы и push-уведомлений тоже собирают данные, и о них нужно заявить. Расхождения между декларацией и фактом — прямой путь к отклонению или блокировке обновления.
Требования Apple и Google к сборке, метаданным и скриншотам
Требования сторов меняются каждый год, поэтому перед релизом всегда сверяйтесь с актуальными страницами документации. Но базовая логика остаётся стабильной.
Для App Store Connect требования касаются сборки на актуальной версии Xcode и SDK, которую Apple обязывает использовать с весны каждого года. Приложение должно работать без падений, не содержать заглушек и тестовых данных, а демо-доступ для ревьюера должен быть рабочим. Если в приложении есть вход по логину, обязательно приложите тестовую учётную запись.
Для Google Play Console публикация подразумевает загрузку формата Android App Bundle (AAB), а не APK. Приложение должно указывать актуальный целевой уровень API: Google ежегодно повышает минимальный target SDK, и для новых релизов устаревшие значения не принимаются.
В App Store и Google Play размеры и количество скриншотов зависят от типов устройств. Apple требует набор для актуальных размеров iPhone, а для iPad — только если приложение поддерживает планшеты. Точные разрешения всегда уточняйте в консоли перед подготовкой графики.
Что обязательно подготовить для карточки приложения:
- Название до 30 символов без рекламных слов вроде «лучшее» и «№1».
- Краткое и полное описание без упоминания конкурентных платформ.
- Иконка 1024×1024 без прозрачности и скруглений, которые вы рисуете сами.
- Скриншоты, показывающие реальный интерфейс, а не только маркетинговые баннеры.
- Возрастной рейтинг, заполненный честно по анкете стора.
- Ключевые слова и категория, соответствующие назначению продукта.
Если ваш продукт связан с внешними сервисами, например платежами, CRM или картами, проверьте стабильность этих подключений до отправки. Мы часто видим отказы из-за недоступного API в момент ревью. Подробнее о надёжной связке сервисов — на странице про интеграции приложений.
Самые частые причины отклонения и как их избежать
Отклонение — это не катастрофа, а рабочая часть процесса. Но каждое лишнее ревью съедает от нескольких дней до недели. Вот что чаще всего приводит к отказу.
Отклонение приложения App Store чаще всего связано с несколькими пунктами правил App Store Review Guidelines:
- Сбои и баги (раздел о производительности): приложение падает или не открывается на устройстве ревьюера.
- Недоступные функции: нет демо-аккаунта, закрыт сервер, не работают ссылки.
- Минимальная функциональность: приложение выглядит как обёртка сайта без собственной ценности.
- Платежи: цифровые товары и подписки продаются в обход встроенных покупок.
- Приватность: нет политики, неверная декларация данных, нет объяснения запроса разрешений.
- Вход через соцсети без соответствующих альтернатив там, где этого требуют правила.
В Google Play типичные причины другие: нарушение политики пользовательских данных, избыточные разрешения, например доступ к SMS или геолокации в фоне без обоснования, вводящие в заблуждение описания, неверная декларация Data Safety и несоответствие целевой аудитории детским политикам.
В поле «Заметки для ревьюера» опишите, как проверить ключевые функции, и приложите видео прохождения основных сценариев. Это сокращает число уточняющих вопросов и ускоряет ревью.
Как снизить риск отказа до отправки:
- Проведите тест на реальных устройствах, а не только на эмуляторах.
- Пройдите официальный чек-лист Review Guidelines и Developer Program Policy.
- Запрашивайте разрешения только в момент, когда они нужны, с понятным текстом.
- Убедитесь, что все ссылки, формы и серверные части работают в день отправки.
- Сверьте скриншоты и описание с текущей версией интерфейса.
Если отказ всё же пришёл, внимательно читайте формулировку и номер пункта правил. Отвечайте по существу через Resolution Center, исправляйте причину и не пытайтесь повторно отправить ту же сборку без изменений.
Кто отвечает за публикацию: команда, подрядчик или сам владелец бизнеса
Здесь нет универсального ответа, но есть правило: владельцем аккаунтов должен быть бизнес, а исполнителем может быть кто угодно. Такое разделение защищает ваши активы и не тормозит работу.
Есть три типовые модели. В первой всё делает внутренняя команда: разработчик, менеджер продукта и маркетолог. Это удобно, если в штате уже есть опыт релизов. Во второй модели публикацию берёт на себя подрядчик: он готовит сборку, заполняет карточки и ведёт общение с ревью. В третьей, смешанной, бизнес отвечает за аккаунты, тексты и юридические документы, а подрядчик за техническую часть.
Смешанная модель чаще всего даёт лучший результат. Владелец бизнеса лучше всех знает, как описать продукт и какие данные он собирает, а разработчики лучше разбираются в сборках, сертификатах и подписи приложения.
Распределение ролей можно зафиксировать так:
- Владелец бизнеса: аккаунты, платёжные данные, юридические документы, финальное одобрение.
- Маркетолог: название, описание, ключевые слова, скриншоты, план запуска.
- Разработчик или подрядчик: сборки, сертификаты, TestFlight, исправление замечаний ревью.
- Менеджер проекта: график, коммуникация со сторами, контроль чек-листа.
После выхода работа не заканчивается. Нужно отвечать на отзывы, следить за крэшами и совместимостью с новыми версиями iOS и Android, а сторы регулярно меняют правила. Для этого удобно заключить договор на техническую поддержку приложения. Если вы только выбираете стратегию запуска, поможет консультация для стартапов.
Ключевые выводы
- Аккаунты и юридические документы оформляйте в начале проекта: они задерживают релиз чаще, чем код.
- Закладывайте 1–4 недели на публикацию и не назначайте запуск рекламы на день отправки.
- Большинство отказов вызваны багами, недоступным демо-доступом, платежами и ошибками в декларации данных.
- Аккаунты должны принадлежать бизнесу, а исполнителем может быть команда или подрядчик.
Заключение
Публикация в сторах — предсказуемый процесс, если подойти к ней как к отдельному проекту. Аккаунты, документы, метаданные и тестирование готовятся параллельно с разработкой, а не после неё.
Главные принципы просты. Начинайте с регистрации и верификации, сверяйтесь с актуальными требованиями Apple и Google, проверяйте приложение на реальных устройствах и честно описывайте сбор данных. Для ревьюера подготовьте демо-доступ и понятные заметки.
Если отказ всё же случился, это не повод паниковать. Прочитайте причину, исправьте её и отправьте обновлённую сборку с комментарием. Команды, которые делают это регулярно, обычно проходят ревью с первой или второй попытки.
И последнее: храните контроль над аккаунтами у бизнеса, а техническую часть доверяйте тем, у кого есть опыт релизов. Так вы защитите продукт, сэкономите время и выйдете на рынок без неприятных сюрпризов.