Первую отправку приложения в магазин следует выполнять за несколько недель до запуска, а не в день завершения сборки. Не потому, что проверка проходит медленно, а потому, что работа с аккаунтом и метаданными вокруг неё систематически недооценивается.
Настройка аккаунта занимает больше времени, чем проверка
Прежде чем что-либо можно будет отправить, должна существовать учётная запись разработчика. Для корпоративной учётной записи обычно требуются документы о регистрации компании и этап верификации, который занимает от нескольких дней до нескольких недель в зависимости от юрисдикции и того, насколько быстро удаётся сопоставить документы.
Задержки банальны и предсказуемы: название компании не совпадает в точности с регистрационными данными, формат адреса не принимается системой верификации, тип юридического лица требует дополнительных подтверждений. Ничего из этого несложно, но всё требует календарного времени.
Этим следует заняться в начале проекта, а не в конце. Это самая распространённая причина переноса даты запуска по причинам, не связанным с разработкой.
Повторяющиеся причины отклонения
Большинство отклонений при первой отправке относится к небольшому числу категорий:
- Неполная информация для проверки. Если приложению требуется вход в систему, необходимо предоставить рабочие тестовые учётные данные. Проверяющие, которые не могут войти, отклоняют отправку. Если для рабочего процесса нужны определённые данные или конкретное состояние устройства, это необходимо объяснить.
- Сбои или очевидные ошибки. Проверяющие используют приложение и отклоняют его при сбоях.
- Отсутствующие или противоречивые сведения о конфиденциальности. Политика конфиденциальности обязательна, должна быть доступна по действующему URL и соответствовать тому, какие данные приложение действительно собирает. Указание об отсутствии сбора данных при запросе разрешений на доступ к контактам — противоречие, которое проверяющие выявляют.
- Запрос разрешений без очевидной цели. Запрос доступа к геолокации, камере или контактам требует обоснования, которое проверяющий сочтёт правдоподобным, а текст объяснения в приложении должен быть конкретным, а не общим.
- Временное содержимое. Lorem ipsum, пустые экраны, неработающие кнопки, разделы с пометкой «скоро». Страница приложения в магазине предназначена для готового продукта.
- Обработка платежей с нарушением правил платформы. Правила о том, какие платежи должны проходить через собственный платёжный механизм платформы, конкретны и строго применяются. Ошибка в этом вопросе может потребовать переработки основного пользовательского сценария.
- Несоответствия в метаданных. На скриншотах показаны функции, которых нет в приложении, или в описаниях обещана несуществующая функциональность.
Каждую из этих проблем можно предотвратить до отправки, а проверка перед отправкой по этому списку занимает час.
Метаданные — это отдельная задача
Для страницы приложения на каждой платформе и для каждого языка требуются:
- Название и подзаголовок приложения в пределах ограничений по количеству символов.
- Описание, обычно в краткой и полной версиях.
- Ключевые слова, если платформа их использует.
- Скриншоты в требуемых размерах для нескольких классов устройств.
- Иконка в нескольких разрешениях.
- Категория, возрастной рейтинг и сведения о содержимом.
- Действующие URL службы поддержки и политики конфиденциальности.
Скриншоты для устройств конкретных размеров чаще всего становятся причиной аврала, поскольку для их подготовки нужна рабочая сборка на устройствах этих размеров. Их корректное создание занимает день, а спешка приводит к странице приложения, которая преуменьшает достоинства продукта.
Сроки проверки
На основных платформах проверка обычно завершается в течение дня или двух, хотя сроки меняются и увеличиваются в период праздников. Планируйте несколько дней и рассчитывайте как минимум на одно отклонение при первой отправке — это нормально, а не признак неудачи; повторная отправка после исправления обычно проходит быстрее.
Не назначайте мероприятие по случаю запуска на день после отправки. Отправьте приложение, получите одобрение и отложите выпуск до готовности — обе основные платформы поддерживают одобрение сборки с последующим выпуском, что полностью устраняет риск, связанный со сроками.
После первого выпуска
Обновления также проходят проверку. Для всего, что связано со сроками, например исправления серьёзной ошибки, закладывайте день или два на проверку, а не рассчитывайте на немедленную публикацию.
Также учитывайте, что обновляются не все пользователи. Значительная их часть долго остаётся на старых версиях, поэтому изменения на стороне сервера должны сохранять совместимость с версиями, которые всё ещё используются, и стоит заранее решить, как долго вы будете их поддерживать.
Связанные услуги Manboo
- Разработка приложений на Flutter для MVP под iOS и Android.
- Разработка бизнес-программного обеспечения для CRM, систем бронирования, учёта запасов и управления рабочими процессами.
- Разработка административных панелей для операционных дашбордов и управления серверной частью.
- Интеграция ИИ API, когда ваш продукт готов к интеллектуальному поиску, чату или автоматизации.
- Запросить проверку объёма работ и оценку проекта, когда вы готовы спланировать первую версию.