Какие правила магазина касаются вашего приложения?
Начинайте ещё на этапе разработки, не откладывая до последней недели перед запуском. Запишите, в каких магазинах вы планируете публикацию, на кого оформлен каждый аккаунт разработчика и какие функции подпадают под правила платформы. Этот список входит в любой проект разработки мобильного приложения. Чувствительные места обычно одни и те же: как приложение собирает и использует личные данные, какие разрешения устройства запрашивает и зачем, как оплачиваются цифровые покупки и подписки, как пользователи входят в аккаунт и удаляют его, какой контент они могут создавать или видеть.
Разберите актуальные требования по каждому из этих пунктов вместе с теми, кто отвечает за них в вашей компании, например с сотрудником, который ведёт платежи или вопросы персональных данных. Правила меняются и могут отличаться для разных типов аккаунтов и регионов, поэтому опирайтесь на официальную документацию, не на чужой пересказ годичной давности. Отдельно проверьте анкеты о сборе данных и возрастном рейтинге: магазины сверяют их с тем, что приложение делает на самом деле.
Самый дорогой сюрприз — узнать при подаче, что основной сценарий, например покупку или вход, придётся переделывать. Именно поэтому дата выпуска должна зависеть от фактической готовности и результата проверки. Честно пообещать одобрение к определённому числу не может никто.
Сможет ли проверяющий протестировать приложение?
Проверяющий может одобрить только то, что он в состоянии увидеть. Отправьте правильную сборку и убедитесь, что в ней работают все сценарии, описанные в карточке. Если часть приложения доступна только после входа, дайте рабочий демо-аккаунт и понятную инструкцию: Apple просит указать это в сведениях для проверки, а в Play Console у Google Play для этого есть отдельный раздел о доступе к приложению.
Позаботьтесь о том, чтобы сервисы, от которых зависит приложение, — ваш сервер, тестовая среда платежей, системы партнёров — работали всё время, пока идёт проверка. Если проверяющий увидит пустой экран или ошибку сервера, у него нет причин считать, что у настоящих клиентов всё работает. Если сценарий необычный, например нужен специальный прибор, QR-код или определённое место, объясните, как его проверить, или приложите короткое видео. Чем проще проверяющему, тем меньше лишних вопросов и повторных подач.
Скриншоты и описание должны показывать функции и языки именно той сборки, которую вы отправили, а не возможности следующей версии. И наконец, запишите, из какого исходного кода и какой сборки получен отправленный файл, чтобы любое исправление можно было надёжно воспроизвести и пересобрать. Удобно завести короткий внутренний список «что нужно для проверки» — демо-аккаунт, тестовые данные, работающие серверы, актуальные скриншоты — и сверяться с ним перед каждой подачей.
Что делать, если магазин прислал замечание?
Относитесь к замечанию магазина как к конкретной задаче релиза. Внимательно прочитайте указанную причину, найдите правило, на которое ссылается проверяющий, и воспроизведите описанный им сценарий. Иногда исправлять нужно код, а иногда — карточку приложения, пояснения для проверки или демо-аккаунт, который перестал работать.
После исправления повторите и смежные проверки, а не только тот шаг, о котором написал проверяющий: правка экрана оплаты легко может задеть восстановление покупок или страницу аккаунта. Если вы считаете, что проверяющий что-то понял неверно, ответьте через официальный канал — спокойно, с объяснением и доказательствами.
Проверку, поэтапный выпуск и дальнейшую поддержку стоит рассматривать как отдельные решения. Одобрение не обязывает выпускать обновление сразу для всех: в обоих крупных магазинах есть способы выпускать версию постепенно. Следуйте действующему порядку для вашей платформы и типа аккаунта — чек-лист, составленный для другого вида аккаунта или по старой редакции правил, может увести не туда. Записывайте каждое замечание и то, как его исправили: при следующих подачах это сэкономит время и поможет не повторить ту же ошибку.
Чек-лист: подача в магазин приложений
- Уточните, на кого оформлен каждый аккаунт разработчика, и прочитайте действующие правила платформы.
- Ещё во время разработки сверьте с этими правилами работу с данными, разрешения, оплату и вход.
- Убедитесь, что отправленная сборка, карточка и скриншоты описывают один и тот же продукт.
- Подготовьте рабочий аккаунт для проверки, понятную инструкцию и доступные сервисы.
- Воспроизведите каждое замечание, исправьте его и повторите смежные проверки.
Пример: приложение, где нужен вход
Сервисное приложение показывает заказы только клиентам, которые вошли в аккаунт. Перед подачей команда создаёт аккаунт для проверки с тестовыми заказами, пишет короткую инструкцию, как открыть и отследить заказ, и убеждается, что тестовый сервер будет работать всё время проверки. Заодно проверяют, что срок действия демо-аккаунта не истечёт и что его не заблокируют посреди проверки.
Кроме того, команда сверяет карточку со сборкой: программа лояльности, запланированная на следующую версию, убрана из описания и скриншотов. Всё это делает проверку проще и предсказуемее, но решение об одобрении всё равно остаётся за магазином.
