Что нужно для публикации приложения в сторах
Что подготовить для App Store и Google Play: аккаунты, карточку приложения, сведения о данных, тестовый доступ и план проверки релиза.
Для публикации приложения нужны не только рабочая сборка, но и аккаунт разработчика, материалы карточки, сведения об обработке данных и доступ для проверки. App Store и Google Play оценивают приложение по своим правилам. Поэтому завершение разработки и появление приложения в магазине — разные этапы, между которыми возможны вопросы и исправления.
Ниже — рабочий список для владельца бизнеса. Он помогает распределить ответственность до релиза, но не заменяет проверку актуальных требований выбранного стора. Условия зависят от функций, типа аккаунта, аудитории и регионов распространения; обещать одобрение к фиксированному дню без этих вводных нельзя.
1. Подготовьте аккаунты и распределите доступы
Заранее решите, кто будет владельцем аккаунта разработчика и кто сможет выпускать обновления. Для бизнеса разумно сохранять контроль над аккаунтом у заказчика, а исполнителю выдавать необходимые рабочие права. Это организационное решение стоит зафиксировать вместе с передачей исходников и доступов.
Проверьте доступность регистрации и распространения для вашей страны, выбранного типа аккаунта и способа оплаты. Не откладывайте подтверждение сведений до дня готовности приложения. Какие документы понадобятся, нужно смотреть в процессе регистрации конкретного аккаунта, а не переносить список из чужого проекта.
Составьте список ответственных: кто подтверждает сведения о компании, принимает соглашения, отвечает на письма стора и согласует описание. Отдельно определите, кто хранит доступы к сервисам приложения. Аккаунт магазина, сервер, аналитика и почта поддержки — разные части проекта; один пароль не заменяет управление ими.
При заказе разработки мобильного приложения полезно сразу уточнить границу работ: подготовка сборок, оформление карточек, отправка на проверку, ответы на замечания и последующие обновления. Слово «публикация» без этого списка допускает разные ожидания.
2. Соберите карточку и сведения о данных
Подготовьте название, описание, иконку, снимки рабочих экранов и контакты поддержки. Материалы должны показывать то, что действительно доступно в отправляемой версии. Не добавляйте на скриншоты будущую функцию, если пользователь не сможет её найти после установки.
Отдельно составьте перечень данных: контакты, идентификаторы, сведения о заказах, аналитика, отчёты об ошибках. Учитывайте не только собственный код, но и подключённые библиотеки и сервисы. Apple требует раскрывать практики обработки данных, включая сторонних партнёров; в Google Play сведения указываются в разделе Data safety по его правилам.
Политика конфиденциальности должна соответствовать реальной работе продукта. Скопированный текст не объяснит, какие данные уходят вашему сервису аналитики или где пользователь управляет аккаунтом. Юридическое содержание согласует ответственное лицо заказчика; разработчик помогает описать фактические потоки данных.
Если приложение позволяет создавать аккаунт, проверьте требования к его удалению. Apple предусматривает запуск удаления внутри приложения; Google Play для приложений в области действия требования предусматривает путь внутри приложения и веб-ссылку для запроса. Продумайте этот сценарий заранее, а не добавляйте неработающую кнопку перед проверкой.
3. Дайте проверяющему пройти рабочие сценарии
Проверяющий должен иметь возможность увидеть заявленные функции. Если нужен вход, подготовьте рабочую тестовую учётную запись или иной допустимый стором способ демонстрации. Apple прямо просит предоставить необходимые сведения и доступ. Убедитесь, что сервер работает, а инструкции не требуют звонка вашему сотруднику в определённый час.
В тестовом доступе не должно быть реальных персональных данных клиентов. Заполните демонстрационные заказы и объясните нестандартные шаги: выбор организации, подключение оборудования, работу с отдельной ролью. Если функция зависит от внешнего устройства или специальных условий, заранее проверьте, какие материалы потребует магазин.
Пройдите установку на чистом устройстве, первый вход, отказ в разрешениях, потерю соединения и восстановление сеанса. Проверьте ссылки поддержки и политики данных. Отправленная сборка должна соответствовать карточке приложения, а не отличаться от версии, которую показывали заказчику.
Для новых личных аккаунтов Google Play, созданных после 13 ноября 2023 года, предусмотрены отдельные требования к тестированию перед доступом к production. Это не универсальное правило для всех аккаунтов. Применимые условия и состояние доступа проверяют в Play Console конкретного владельца.
4. Согласуйте действия после отправки
Зафиксируйте, кто отслеживает статус проверки и готовит ответ на замечания. Отправка сборки ещё не означает одобрение, а одобрение не всегда означает немедленную доступность пользователям: настройки выпуска тоже нужно проверить.
До запуска подготовьте короткий контрольный список: приложение находится в выбранном регионе, устанавливается по публичной ссылке, вход работает, поддержка получает обращения. Назначьте ответственного за первые ошибки и следующие версии. Если объявлена рекламная кампания, её старт лучше связывать с подтверждённой доступностью, а не только с датой отправки.
В кейсе SplitCash показан мой собственный выпущенный продукт. Его публикация не гарантирует решение магазина по другому приложению. Для вашего проекта я сначала уточню функции, аккаунты и недостающие материалы, чтобы план выпуска отражал реальные зависимости.