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

Но перед тем как приложение попадёт в руки пользователей, его должны одобрить модераторы App Store и Google Play. И вот тут начинается самое интересное. За последние годы требования стали такими, что даже опытные разработчики получают реджекты по полной программе. 

В данной статье приведем простые действия и технические моменты, которые по нашему опыту помогут быстрее пройти модерацию и зарелизиться в сторах. 

Размещение приложения в App Store

Процесс выхода приложения в экосистеме Apple сопровождается рядом строгих требований в области безопасности, дизайна и защиты пользовательских данных. Несоблюдение даже незначительных из них может привести к отклонению сборки на этапе модерации.

Ну что ж, начнем.

1. Регистрация аккаунта в Apple Developer Program

Перед началом работы нужно, соответственно, оформить аккаунт разработчика, корректно настроить проект и подготовить всю необходимую информацию для App Store Connect.

Подробнее о регистрации аккаунта можно почитать на официальном сайте. Отдельно отмечать нюансы регистрации из России не будем — все уже описано в сети.

Существует два типа аккаунтов: 

• Individual для индивидуальных разработчиков.  

• Organization для юридического лица. 

Зарегистрировать аккаунт можно на developer.apple.com. Стоимость подписки составит $99 в год.

Для юридических лиц обязательно потребуется получить D-U-N-S Number  — это уникальный девятизначный идентификатор компании, который присваивается международным агентством Dun & Bradstreet, его можно получить бесплатно на сайте Dun & Bradstreet (есть форма для разработчиков Apple).

Процесс занимает от 3 до 10 рабочих дней. Российские компании тоже могут его получить — регистрация проходит через локальное представительство D&B.

2. Создание нового приложения

После регистрации аккаунта разработчика следующий шаг — добавить проект в App Store Connect. На этом этапе формируется карточка приложения, в которой указываются основные параметры, необходимые для дальнейшей загрузки сборки и прохождения модерации.

При создании нового приложения требуется указать: 

• Платформа — выберите целевую платформу (например, iOS, iPadOS, macOS и др.).

• Название приложения (Name) — до 30 символов; должно быть уникальным в пределах App Store.

• Основной язык (Primary Language) — язык локализации интерфейса и описания (например, English или Russian).

• Идентификатор пакета (Bundle ID) — должен в точности совпадать с идентификатором, указанным в Xcode; изменить его после создания невозможно.

• SKU — внутренний идентификатор проекта, произвольная строка (например, myapp2025).

3. Подготовка приложения к публикации

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

С апреля 2025 года все новые сборки должны выполняться с использованием Xcode 16 и SDK для iOS 18 или более новой версии. Это требование является обязательным для всех релизов, проходящих App Review.

С мая 2024 года Apple ввела обязательное требование для всех новых приложений и обновлений: если приложение или сторонний SDK используют API, требующие указания причины (Required Reason APIs), необходимо добавить в проект специальный файл Privacy Manifest (PrivacyInfo.xcprivacy).

Без корректно оформленного манифеста приложение не пройдет модерацию, если использует такие API или SDK.

Privacy Manifest — это файл, описывающий:

• Какие категории данных приложение собирает и для каких целей;

• Какие API из списка Required Reason APIs оно использует и по каким причинам;

• Какие домены могут использоваться для отслеживания активности (если применимо).

Файл манифеста включается в ресурсы приложения или SDK и считывается Xcode при сборке. На основании этого файла формируется сводка конфиденциальности приложения, отображаемая в App Store.

Required Reason APIs — это API, использование которых может потенциально применяться для скрытого отслеживания активности пользователя или устройства. Apple требует указывать обоснование (reason code) для каждого такого API в манифесте.

Примеры категорий API:

• NSPrivacyAccessedAPICategoryFileTimestamp — доступ к временным меткам файлов;

• NSPrivacyAccessedAPICategoryUserDefaults — чтение пользовательских данных и настроек приложения;

• NSPrivacyAccessedAPICategorySystemBootTime, NSPrivacyAccessedAPICategoryDiskSpace и др.

Использование таких API разрешено только при наличии утверждённой причины (reason code), соответствующей функциональности приложения.

Например: 

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

Список допустимых кодов опубликован в разделе Describing use of required reason API

Если приложение включает сторонние SDK (рекламные, аналитические, для уведомлений и т. д.), тогда каждый SDK также должен иметь собственный файл манифеста PrivacyInfo.xcprivacy.

Если SDK использует API, требующие указания причины, то этот SDK обязан задекларировать использование и причины в своём манифесте. Согласно документации Apple, при сборке Xcode объединяет данные из всех манифестов — как приложения, так и SDK — в единый отчёт конфиденциальности.

Помимо Privacy Manifest, если приложение запрашивает доступ к данным или системным функциям (геолокация, камера, микрофон, фото и т. д.), в Info.plist по-прежнему необходимо указывать purpose strings — пояснения для пользователя о целях доступа.

Примеры ключей:

• NSLocationWhenInUseUsageDescription — доступ к местоположению при активном использовании приложения;

• NSCameraUsageDescription, NSPhotoLibraryUsageDescription, NSMicrophoneUsageDescription и др. — аналогично для камеры, фото, микрофона и прочих ресурсов.

Текст объяснения должен быть понятен пользователю и отражать реальную цель запроса, например: “Приложению нужен доступ к камере для сканирования QR-кодов.”

Если объяснение отсутствует, Xcode выдаст ошибку Missing Purpose String, и сборка не пройдет проверку. Apple также рекомендует не использовать упоминания Apple, App Store или маркетинга в этих строках.не

4. Заполнение данных приложения

После подготовки сборки и проверки всех технических параметров необходимо оформить карточку приложения в App Store Connect. На этом этапе задаются ключевые элементы, которые будут отображаться на странице приложения в App Store и влияют на восприятие пользователями, индексацию и прохождение модерации.

Основные разделы

• Краткое описание (Subtitle) — отображается под названием приложения в App Store и должно содержать не более 30 символов.

• Описание (Description) — основной текст, раскрывающий функциональность и преимущества приложения. Должно быть кратким, точным и не превышать 4000 символов.

• Ключевые слова (Keywords) — набор ключевых слов, вводимых через запятую. Они влияют на индексирование и поиск, поэтому не рекомендуется дублировать название приложения. Общая длина — до 100 символов.

• Категория (Category) — выберите категорию, наиболее точно соответствующую назначению и содержанию вашего приложения.

Скриншоты и иконки

• Скриншоты — обязательны для всех устройств, на которых доступно приложение.

• Разрешения должны точно соответствовать требованиям Apple (например, для iPhone 6.7″ — 1290×2796 px).

• Иконка 1024×1024 px без прозрачности - Apple строго отклоняет иконки с рамками, надписями или имитацией UI.

Требования к политике конфиденциальности Privacy Policy

С 2023 года Apple требует, чтобы у каждого приложения был публичный URL на политику конфиденциальности, даже если приложение не собирает пользовательские данные.

Рекомендуется разместить страницу с политикой конфиденциальности на Notion, GitHub Pages или собственном сайте. Недопустимо указывать PDF-файлы на Google Drive с ограниченным доступом, страницы с редиректами, формы или временные заглушки.

Кроме того, необходимо добавить ссылку на страницу поддержки (Support URL). Если отдельной страницы нет, можно использовать Yandex Forms как форму обратной связи для пользователей.

Приложения без корректной политики конфиденциальности не допускаются к модерации.

Возрастной рейтинг Age Rating

App Store обязывает корректно указать возрастное ограничение, чтобы ограничить доступ несовершеннолетних пользователей к потенциально чувствительному контенту.

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

Конфиденциальность данных (App Privacy)

Apple требует от разработчиков указывать, какие данные собирает приложение, как они используются и применяются ли для отслеживания пользователей (tracking).

Эта информация заполняется в разделе App Privacy Details в App Store Connect.

В соответствующем разделе необходимо ответить на вопросы о сборе и использовании пользовательских данных, а также указать, применяется ли сбор данных для отслеживания пользователей (tracking).

Все сведения должны быть согласованы с содержимым файла Privacy Manifest (.xcprivacy) и фактическим поведением приложения. Если Apple обнаружит несоответствие между заявленными сведениями и реальной логикой работы приложения или SDK, сборка может быть отклонена при проверке (App Review).

Информация для проверки приложения (App Review Information)

В этом разделе необходимо указать контактные данные разработчика, к которому смогут обратиться модераторы в случае возникновения вопросов во время проверки приложения.

Если приложение требует авторизацию, обязательно добавьте тестовый логин и пароль для доступа к функциональности. Это позволит модераторам корректно протестировать все основные сценарии работы и ускорит процесс прохождения App Review.

Цена и доступность (Pricing and Availability)

Даже если приложение бесплатное, Apple требует заполнить этот раздел перед отправкой на модерацию.

• Установите цену (или “Free”).

• Укажите регионы, где приложение будет доступно.

• При необходимости настройте предзаказы (Pre-order) или отложенный релиз.

5. Загрузка билда через Xcode

Билд должен быть подписан тем же сертификатом, что и аккаунт. После успешной отправки билда он появится в App Store Connect во вкладке “TestFlight” – “iOS Builds”.

6. Предрелизное тестирование приложения

Перед тем как отправлять приложение на модерацию и публиковать в App Store, Apple рекомендует провести предрелизное тестирование через TestFlight.

Это помогает проверить стабильность работы, интерфейс, функциональность и собрать обратную связь от тестировщиков до официального релиза.

Для тестирования используется специальный инструмент — TestFlight, встроенный в App Store Connect.

Существует два типа тестирования: внутреннее и внешнее.

Внутреннее тестирование предназначено для проверки приложения небольшой командой разработчиков и участников проекта:

• Максимум до 100 тестировщиков.

• В качестве тестировщиков можно приглашать только пользователей, которые добавлены в команду Apple Developer (с ролями Admin, App Manager, Developer и др.).

• Билд становится доступным почти сразу после загрузки через Xcode, без прохождения модерации.

Внешнее тестирование позволяет раздавать приложение ограниченному числу внешних пользователей — не входящих в команду разработчиков.

• Максимум до 10 000 тестировщиков.

• Пользователи могут присоединяться через публичную ссылку или по email-приглашению.

• Перед тем как билд станет доступен внешним тестировщикам, он должен пройти обязательную проверку Apple (App Review for TestFlight). Проверка обычно занимает 1–2 дня и менее строгая, чем публикация в App Store.

• Внешние тестировщики могут оставлять обратную связь напрямую через TestFlight.

Каждый билд доступен для тестирования в течение до 90 дней.

7. Обновление версии приложения

При загрузке новой версии обновления приложения в App Store важно указать номер версии, который должен быть выше текущей. 

Это связано с тем, что App Store воспринимает каждую версию как отдельный релиз, и если номер останется прежним, система просто не примет билд. 

При указании версии приложения желательно соблюдать правила версионирования, с ними вы можете ознакомиться по ссылке. Обычно номер версии увеличивают в формате X.Y или X.Y.Z в зависимости от характера изменений, например:

Обновление с 1.0 на 1.1 — если появились новые функции.

Обновление с 1.0 на 1.0.1 — если это небольшие исправления.

Если вы загружаете новый билд в TestFligt для тестирования, то обязательно только поднять Version Code.

Кроме этого, при обновлении нужно заполнить поле “What’s New in This Version”. Именно этот текст отображается пользователям в App Store в блоке об обновлении. В этом поле кратко описывают, что изменилось в приложении: новые функции, улучшения, исправления ошибок, обновления интерфейса и другие важные детали. 

8. Отправка на модерацию (App Review)

Если вы все указали корректно и приложили рабочий проверенный билд, то можно отправлять приложение на проверку. 

Сроки проверки:

• Первое приложение от физ лица: 3–7 рабочих дней (иногда до 2 недель).

• Организация с D-U-N-S: 2–5 рабочих дней.

• Обновления: 1–3 дня.

9. Возможные причины отказа

• Несоответствие гайдлайнам.

• Баги в сборке.

• Недействующие ссылки на политику конфиденциальности или на страницу поддержки.

• Недействующие ссылки в приложении. 

• Не предоставлен тестовый аккаунт или логин/пароль невалидные. 

• Недействительные скриншоты, например, скриншоты сделаны не на iPhone или не соответствуют приложению.

Размещение приложения в Google Play

Google Play традиционно считается более гибкой платформой для публикации приложений – модерация проходит быстрее, а процесс кажется менее формализованным по сравнению с App Store. Однако в последние годы Google существенно ужесточил требования к качеству и безопасности приложений.

1. Регистрация аккаунта в Google Play Console

Для размещения приложений в Google Play необходимо зарегистрировать аккаунт разработчика. Сделать это можно на странице play.google.com/console.

Процесс регистрации включает несколько обязательных шагов:

• Наличие действующего Google-аккаунта;

• Оплата единовременного регистрационного взноса в размере $25;

• Прохождение процедуры подтверждения личности (Identity Verification).

Как и в случае с Apple Developer Program, существуют два типа учётных записей:

• Индивидуальные — предназначены для частных разработчиков и привязаны к личным данным;

• Бизнес-аккаунты — создаются от имени компаний и требуют указания юридической информации с подтверждением организации.

2. Создание нового приложения в Google Play

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

Необходимо указать:

• Язык по умолчанию — основной язык приложения.

• Название приложения — название, которое будет отображаться в Google Play.

• Приложение или игра — выбрать тип продукта.

• Бесплатное или платное — определить модель распространения.

• Принять правила и подтвердить, что приложение соответствует требованиям разработчиков Google Play.

После создания карточки вы перейдёте в основной дашборд приложения, где нужно будет заполнить все обязательные разделы перед публикацией.

3. Подготовка приложения к публикации

Перед тем как загружать билд и отправлять приложение на проверку в Google Play Console, необходимо тщательно подготовить проект и убедиться, что он соответствует всем техническим и контентным требованиям.

Подготовка включает несколько ключевых аспектов:

• Корректную сборку приложения.

• Проверку версии и подписи.

• Заполнение обязательных данных о конфиденциальности.

• Техническую совместимость с требованиями Google.

С 2021 года Google требует, чтобы все новые приложения загружались в формате Android App Bundle (.aab). Формат APK больше не подходит для первой публикации.

• versionCode — должен быть уникальным и больше, чем у предыдущих билдов.

• Сборка должна быть без дебажных флагов (debuggable=false).

• Подпись должна выполняться release-ключом, а не debug.

Также Google ежегодно обновляет минимальные требования к Target API Level, с 2025 года для новых приложений минимальное требование targetSdkVersion = 34 (Android 14).

4. Заполнение данных приложения

Перед тем как публиковать приложение в Google Play, нужно корректно заполнить его карточку в консоли разработчика. Этот этап подробно описан в официальной документации Google Play. Основные разделы включают:

• Описание — до 4000 символов, подробно раскрывает функциональность;

• Краткое описание — до 80 символов, отображается в поисковой выдаче;

• Категория — тип и направление приложения;

• Теги — помогают с индексированием и улучшением видимости в поиске.

Скриншоты и иконки

• Иконка — квадратная, 512×512 px, без прозрачности.

• Картинка для описания -  отображается перед скриншотами на странице приложения в Google Play, должна быть с разрешением 1024 x 500 px.

• Скриншоты — обязательны для каждой поддерживаемой категории устройств (телефоны, планшеты). Рекомендуемые размеры скриншотов для каждой категории можно посмотреть на официальном сайте. Можно загрузить от 1 до 10 скриншотов, но Apple настоятельно рекомендует загружать как минимум 3–5, чтобы пользователь мог понять функциональность приложения. Обязательно необходимо использовать реальные изображения интерфейса приложения, иначе приложение на пройдет модерацию. 

• Feature graphic — баннер 1024×500 px, отображается в витрине приложения.

Контент приложения - источник

В Play Console нужно заполнить раздел “Контент приложения” — это обязательный раздел, в котором разработчик указывает сведения о содержании и функциональности своего приложения, чтобы подтвердить его соответствие правилам Google Play.

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

В этом разделе представлены несколько основных пунктов:

• разрешения для фото и видео, где объясняется, почему приложение запрашивает доступ к камере или галерее; 

• доступ к приложениям, который описывает использование внешних сервисов или взаимодействие с другими приложениями; 

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

• рекламный идентификатор, через который декларируется использование идентификатора для аналитики или рекламы; 

• безопасность данных, в которой подробно раскрывается, какие сведения собираются, как обрабатываются и защищаются.

5. Ключи подписи приложения (App Signing Keys)

Перед публикацией в Google Play необходимо настроить корректную систему подписи сборок. Google проверяет ключ подписи при каждой загрузке билда, поэтому любая ошибка на этом этапе может привести к тому, что в будущем приложение невозможно будет обновить.

В Android используются два типа ключей:

• Debug key — автоматически создаётся Android Studio и используется только для локальной сборки и тестов. Такой ключ нельзя использовать для публикации.

• Release key — создаётся вручную и используется для финальной подписи сборок перед загрузкой в Google Play. Этот ключ должен храниться в надёжном месте, так как он определяет владельца приложения.

Для публикации в Google Play соответственно всегда используется только release key.

С 2017 года Google ввёл систему Play App Signing, которая сегодня является обязательной для всех новых приложений.

Суть в том, что Google хранит основной ключ подписи приложения (App Signing Key) на своих защищённых серверах, а разработчик использует отдельный Upload Key для загрузки сборок.

Если вы потеряли upload key, его можно легко сбросить через поддержку Google Play. Но если вы потеряли app signing key, то обновить приложение уже не получится.

Обновление утерянного ключа подписи в Google

1) Генерируем новый ключ

keytool -genkey -v -keystore key.jks -keyalg RSA -keysize 2048 -storepass <storepass> -alias <alias> -keypass <keypass> -dname "name" -validity 10000

2) Генерируем upload_certificate.pem

keytool -export -rfc -alias alliancerentalKey -file upload_certificate.pem -keystore key.jks

3) Ключ сохраняем в проект 

4) upload_certificate.pem отправляем в поддержку google с просьбой обновить upload key.

6. Загрузка билда

После заполнения данных о приложении создайте новый выпуск и добавьте для него данные:

• Загрузите .aab файл.

• Проверьте подпись и результаты автоматических проверок.

• Укажите Название выпуска (для внутреннего учёта) и Примечания к выпуску — это текст обновления, который увидят пользователи в Google Play.

Release notes лучше писать коротко и понятно: что добавлено, исправлено или улучшено.

7. Предрелизное тестирование

Перед публикацией приложения в Google Play у разработчиков есть возможность провести предрелизное тестирование, чтобы проверить стабильность, производительность и корректность работы приложения на реальных устройствах до того, как оно станет доступно широкой аудитории.

Google предоставляет для этого три типа тестирования:

• Внутреннее 

• Закрытое 

• Открытое

Эти режимы тестирования настраиваются в Google Play Console в разделе “Тестирование”, и позволяют раздавать доступ к приложению ограниченному кругу пользователей или публично.

Начиная с 13 ноября 2023 года, Google ввёл новое правило для всех новых личных аккаунтов разработчиков (personal accounts). Чтобы получить возможность опубликовать приложение в Production, необходимо пройти этап обязательного закрытого тестирования.

Требования Google:

• Провести закрытое тестирование приложения.

• Пригласить не менее 12 тестировщиков.

• Тестировщики должны быть зарегистрированы и пользоваться приложением минимум 14 дней подряд.

Приложение, запущенное в режиме закрытого тестирования, станет доступно для скачивания в Google Play только тем пользователям, чьи адреса электронной почты вы добавили в список тестировщиков.

Только после выполнения этих условий станет доступна публикация приложения в открытом доступе.

8. Обновление версии

Как и в App Store, при публикации новой версии нужно:

• Увеличить versionCode — это технический номер версии, который определяет обновление.

• При необходимости обновить versionName — пользовательскую версию (например, с 1.0 на 1.1).

Без увеличения versionCode загрузка билда не будет возможна — Google Console выдаст ошибку.

9. Отправьте на модерацию

После загрузки билда и заполнения всех данных отправьте приложение на модерацию.

Сроки проверки:

• Первое приложение от нового разработчика — от 3 до 7 дней, иногда дольше (Google может проводить ручную проверку).

• Обновления существующих приложений — 1–3 дня.

Google может приостановить публикацию до завершения верификации личности или тестирования Pre-launch report.

10. Возможные причины отказа

• Отсутствует публичная политика конфиденциальности, несмотря на то что приложение обрабатывает данные (это одна из самых частых причин отказа!).

• Ссылка на политику конфиденциальности не работает, ведёт на пустую страницу или Google Docs с ограниченным доступом

• Если номер версии совпадает с предыдущим, Google не принимает билд.

• Приложение подписано неверным ключом или debug-ключом.

• Target API Level не соответствует минимальным требованиям (например, targetSdkVersion < 34).

• Если приложение падает при автотестировании (Pre-launch report), оно может быть отклонено.

• Несоответствие фактического поведения приложения описанию в Data Safety или на странице.

Если приложение требует авторизацию, но вы не предоставили рабочие тестовые логины для ревью.

Ключ подписи 

Перед публикацией приложения в магазине необходимо обеспечить его корректную цифровую подпись. Подписанный файл APK или AAB подтверждает подлинность разработчика и защищает пользователей от подмены или изменения сборки после выпуска. Без действительного ключа подписи приложение не будет принято к публикации, а его обновления — установлены на устройствах пользователей.

В данном разделе рассмотрен процесс создания и настройки ключа подписи (.keystore), его подключение к проекту через файл key.properties и конфигурацию подписи в build.gradle. Также приведены команды для проверки корректности подписи и сравнения отпечатков сертификата (SHA1/SHA256) с зарегистрированными в магазине значениями.

Создание ключа подписи (.keystore)

Необходимо выполнить команду:

keytool -genkey -v -keystore key.jks -keyalg RSA -keysize 2048 -storepass <storepass> -alias <alias> -keypass <keypass> -dname "name" -validity 10000

• key— имя файла с ключом (можно поменять)

• alias — alias (псевдоним ключа)

• validity 10000 — срок действия ключа (в днях, ≈ 27 лет)

• storepass — пароль от контейнера

• keypass — пароль от ключа
   

storepass и keypass могут быть одинаковыми

Не рекомендуется класть ключ в git, нужно хранить его отдельно и сделать резервную копию.

Создание key.properties

Создай в корне Flutter-проекта файл android/key.properties:

storePassword=ТВОЙ_ПАРОЛЬ_ОТ_KEYSTORE
keyPassword=ТВОЙ_ПАРОЛЬ_ОТ_КЛЮЧА
keyAlias=alias
storeFile=key.jks

Настройка build.gradle для подписи

Нужно модифицировать файл android/app/build.gradle

def keystoreProperties = new Properties()
def keystorePropertiesFile = rootProject.file('key.properties')
if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
}

android {


***

    signingConfigs {
        release {
            keyAlias keystoreProperties['keyAlias']
            keyPassword keystoreProperties['keyPassword']
            storeFile keystoreProperties['storeFile'] ?  file(keystoreProperties['storeFile']) : null
            storePassword keystoreProperties['storePassword']
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release

            ***

        }
    }
}

Теперь при сборке релизной версии APK или AAB будут подписаны. 

Через команду можно проверить подпись сборки:

jarsigner -verify -verbose -certs app-release.aab 

Альтернативно команда покажет отпечаток SHA1/SHA256, который можно сравнить с тем, что зарегистрировано в Google Play или AppGallery

keytool -printcert -jarfile path/to/app-release.aab

Заключение

В последнее время публикация приложений происходит всё труднее и труднее, в статье постарались описать большинство моментов, которые помогут вам успешно выпустить приложение в сторы.

А какой у вас опыт публикации? Поделитесь об этом в комментариях.