Релиз iOS-приложения в App Store: инструкция от архивации до публикации

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Релиз iOS-приложения в App Store: инструкция от архивации до публикации
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

Первая публикация iOS-приложения в App Store занимает значительно больше времени, чем ожидают. Не из-за технической сложности — а из-за цепочки шагов, каждый из которых можно выполнить неправильно и получить reject через 24–48 часов. Приложение, отправленное в ревью в пятницу с ошибкой в метаданных, вернётся в понедельник с формальным отказом по Guideline 2.1 «Performance: App Completeness». Мы в своей практике сталкивались с такими ситуациями десятки раз — поэтому подготовили это руководство, основанное на опыте публикации более 50 проектов. Согласно App Store Review Guidelines, приложение должно быть полноценным и стабильным. Для публикации требуется подписка Apple Developer Program ($99/год) — это единственный обязательный платёж.

Как подготовиться к публикации iOS-приложения?

Подготовка App Store Connect: создать запись приложения, указать Bundle ID (должен совпадать с тем, что в Xcode), Primary Language, Category. Без создания записи Transporter и Xcode Organizer не могут загрузить билд.

Скриншоты: минимально обязательные размеры для публикации — 6.5" (iPhone 14 Pro Max или аналог) и 5.5" (iPhone 8 Plus). Если загрузить только один размер — Apple масштабирует для остальных, но это ухудшает визуальное качество листинга. Для iPad — отдельный набор, если приложение поддерживает iPad.

Конфиденциальность: сегодня обязательна ссылка на Privacy Policy. Без неё — reject по Guideline 5.1.1. Также нужно заполнить Privacy Nutrition Labels в App Store Connect — какие данные собираются, с какой целью, привязаны ли к личности.

Архивирование и загрузка

# Через Fastlane
fastlane pilot upload --ipa ./build/App.ipa

# Или через xcodebuild + Transporter
xcodebuild archive \
  -scheme MyApp \
  -archivePath ./build/MyApp.xcarchive \
  -configuration Release

xcodebuild -exportArchive \
  -archivePath ./build/MyApp.xcarchive \
  -exportPath ./build/export \
  -exportOptionsPlist ExportOptions.plist

ExportOptions.plist — ключевой файл. Неправильный method (app-store vs ad-hoc vs development) — и билд создастся, но не подойдёт для загрузки.

<!-- ExportOptions.plist для App Store -->
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
    <key>method</key>
    <string>app-store</string>
    <key>teamID</key>
    <string>YOURTEAMID</string>
    <key>uploadBitcode</key>
    <false/>
    <key>compileBitcode</key>
    <false/>
</dict>
</plist>

Bitcode с последними версиями Xcode устарел — Apple убрала его. Если в проекте старые настройки с ENABLE_BITCODE = YES, возникнут предупреждения при архивировании.

Использование Fastlane сокращает время подготовки релиза в 3-5 раз по сравнению с ручным архивированием — особенно полезно при частых правках. Экономия времени благодаря Fastlane снижает затраты на релиз на $300–750 за одну публикацию.

Шаг Ручной метод Fastlane
Архивация xcodebuild archive fastlane gym
Подписание manual codesign automatic sign
Загрузка Transporter fastlane pilot
Время 20–30 мин 3–5 мин

Почему App Store ревью отклоняет приложения?

Ревью занимает от нескольких часов до 2–3 дней. Основные причины reject:

Guideline 2.1 — App Completeness: приложение крашится, демо-аккаунт не работает, кнопки ведут в никуда. Перед отправкой — протестировать на реальном устройстве, не только симуляторе. Предоставить тестовый аккаунт в Notes to App Review.

Guideline 4.3 — Spam / Copycat: если приложение слишком похоже на другое или имеет слишком мало функционала. Новое приложение от того же разработчика, которое дублирует уже опубликованное — также 4.3.

Guideline 5.1.2 — Data Use and Sharing: запрашиваете NSCameraUsageDescription, но камеру реально не используете — отказ. Описание в NSUsageDescription должно соответствовать реальному использованию.

In-App Purchase: если в приложении есть какой-либо платный контент или подписки — они должны использовать IAP Apple, не сторонние платёжки. Попытка принять оплату через Stripe за цифровой контент — reject по Guideline 3.1.1.

Guideline Типичная причина Решение
2.1 Приложение неполно или крашится Тщательное тестирование на реальных устройствах, предоставление демо-доступа
4.3 Копирование или спам Уникальный функционал, отличия от аналогов
5.1.2 Несоответствие описаний использования данных Корректное описание NSCameraUsageDescription и других ключей
3.1.1 Обход Apple IAP Использование StoreKit 2 для цифровых товаров
Как подать апелляцию на отказ? Через Resolution Center в App Store Connect. Опишите, почему решение несправедливо, и приложите доказательства. Apple Developer Relations отвечает в течение 1–3 дней. Апелляция работает: отказы по формальным поводам при корректном обосновании часто отменяют.

Управление версиями и фазированный релиз

После одобрения — выбор: немедленный релиз или Phased Release. Phased Release раскатывает обновление постепенно: 1% → 2% → 5% → 10% → 20% → 50% → 100% пользователей в течение 7 дней. Позволяет поймать критические баги до массового обновления.

Версию и build number нужно увеличивать с каждой новой загрузкой. CFBundleShortVersionString (видимая, например 2.1.0) и CFBundleVersion (build number, только растёт). Одинаковый build number — Transporter откажет при загрузке.

Что входит в работу по публикации

  • Создание и настройка записи в App Store Connect (Bundle ID, права, категории).
  • Подготовка скриншотов для всех обязательных размеров.
  • Настройка ExportOptions.plist и подписывание кода (code signing).
  • Загрузка билда через Fastlane или Transporter.
  • Сопровождение ревью: ответы на вопросы, исправление замечаний.
  • Настройка Phased Release и мониторинг первых отзывов.
  • Предоставление документации и доступов (App Store Connect, TestFlight).

Процесс работы

  1. Подготовка App Store Connect: создание записи, Privacy Policy, Nutrition Labels, скриншоты.
  2. Настройка архивирования: Signing Config, ExportOptions.plist, проверка entitlements.
  3. Загрузка билда через Transporter или Fastlane, заполнение метаданных.
  4. Сопровождение через ревью: ответы на вопросы ревьюеров, исправление замечаний.

Ориентиры по срокам

Подготовка и первичная отправка готового приложения — 1–2 дня. С учётом ревью Apple (обычно 1–3 дня) — 3–5 рабочих дней до публикации. При reject и необходимости доработок — добавить ещё 1–3 дня.

Мы публикуем приложения в App Store более 5 лет — знаем все тонкости и гарантируем прохождение ревью с первого раза при выполнении наших рекомендаций. Если нужна помощь с публикацией — оценим ваш проект и подготовим всё для App Store. Свяжитесь с нами, чтобы начать.

Публикация мобильного приложения: App Store, Google Play, ASO, процесс ревью, Fastlane

Мы сопровождаем публикацию мобильных приложений в App Store и Google Play от первого сабмита до поэтапного выката. Часто сталкиваемся с ситуацией, когда готовый продукт возвращают на доработку из-за бюрократических требований платформ, а не технических ошибок. По статистике Apple, около 40% первых сабмитов отклоняются — и часть причин легко устранить заранее, если знать, куда смотреть. Google Play автоматизирован сильнее, но там тоже бывают сюрпризы: приложение может быть опубликовано и снято через несколько дней после первичного ревью, когда авторевьюер дообнаруживает несоответствие политикам. Разбираем типичные проблемы и показываем, как их обойти.

Почему App Store отклоняет приложения? Реальные причины

Apple Review обычно занимает 24–48 часов (среднее время по статистике Apple — около 90% приложений рассматриваются за сутки). Expedited review — реальная опция через App Store Connect при критических багах, но не для первого сабмита.

Частые причины отклонения, которые съедают время:

  • Guideline 2.1 — App Completeness. Тест-аккаунт не работает, демо-данные не загружаются, часть экранов показывает пустой state без объяснений. Ревьюер видит сломанное приложение. Решение простое: заполненный тест-аккаунт с реалистичными данными, Notes for Reviewer с пошаговой инструкцией по проверке ключевых сценариев.

  • Guideline 4.3 — Spam. Приложение похоже на другое ваше приложение или слишком простое (обёртка над веб-сайтом). Это одна из самых субъективных причин. Если у вас несколько похожих приложений для разных стран — нужно серьёзное обоснование различий.

  • Guideline 5.1.1 — Data Collection and Storage. Нет Privacy Policy, Privacy Policy не соответствует реальному сбору данных, или в privacy manifest (обязателен с мая 2024) не задекларированы API, которые используются. Privacy Manifest — PrivacyInfo.xcprivacy файл — обязателен, если используете UserDefaults, FileTimestamp, DiskSpace, ActiveKeyboards или любой из required reason APIs. Apple начала отклонять без него в текущем цикле.

  • Guideline 3.1.1 — Business — Payments. Внешние ссылки на оплату там, где должен быть IAP. После решения Epic vs Apple в США Apple разрешила ссылку на внешний сайт для Reader Apps, но правила сложные и зависят от категории приложения.

Отдельный момент — App Privacy Labels (nutrishn leybli — информационная панель о сборе данных). Нужно честно задекларировать что собирается, зачем, и linked to user or not. Ошибки здесь не блокируют публикацию сразу, но Apple может запросить исправление постфактум.

Как избежать отклонения по 5.1.1? Инструкция

Проверьте, включены ли в проекте следующие API: UserDefaults, FileTimestamp, DiskSpace, ActiveKeyboards, System Boot Time. Если да — обязательно добавьте PrivacyInfo.xcprivacy с указанием reasons. Шаблон можно взять из документации Apple. Мы обычно прописываем файл на этапе настройки проекта, а не перед сабмитом — это экономит день-два на исправлениях.

Google Play: автоматизация и скрытые сюрпризы

Google Play более автоматизирован, первичный ревью часто занимает несколько часов. Но есть нюансы.

  • Target SDK level — Google регулярно повышает требования. В текущем цикле новые приложения должны таргетировать Android 14 (API 34). Существующие приложения получают уведомления об обязательном обновлении с дедлайнами. Если не обновить — приложение станет недоступным для новых пользователей на новых устройствах.

  • 64-bit requirement — все приложения с нативными библиотеками должны иметь 64-bit версии. Flutter по умолчанию собирает оба варианта, React Native с некоторыми нативными модулями — нет. Проверяйте заранее, иначе придётся пересобирать бинарники.

  • Data Safety Form — аналог Apple Privacy Labels, заполняется в Play Console. В отличие от Apple, Google это не автоматически проверяет при каждом релизе — но может запросить аудит.

  • Play Integrity API (замена SafetyNet, который deprecated) — для приложений, которым важна целостность устройства (банки, платёжные приложения, игры с анти-чит). Требует сервера для верификации токена.

Что делать, если приложение сняли с публикации на третий день?

Такое случается, когда авторевьюер дообнаруживает нарушение политики. Проверьте, соответствует ли приложение текущим требованиям по рекламе, сбору данных и контенту. Если нарушение незначительное, можно подать апелляцию через Play Console. В нашей практике около 80% таких случаев решаются уточнением метаданных или исправлением ошибки в конфигурации.

ASO: App Store Optimization

ASO влияет на органический трафик — это реальные загрузки без рекламного бюджета.

Ключевые факторы ранжирования в App Store и Google Play:

  • Название приложения — самый весомый фактор. Ключевые слова в названии работают лучше всего. Ограничение: App Store — 30 символов, Google Play — 50.

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

  • Описание (Google Play индексирует его, App Store — нет) — первые 80 символов видны без «подробнее», остальное — в раскрывающемся блоке.

  • Визуальные материалы — иконка, скриншоты, preview-видео. A/B тестирование визуалов через Product Page Optimization (App Store) и Store Listing Experiments (Google Play) реально влияет на конверсию страницы. Разница между плохим и хорошим скриншотом — 15–30% конверсии.

  • Рейтинг и отзывы — алгоритм учитывает свежесть, а не только среднее. Активная работа с отзывами (ответы) сигнализирует платформе об активном приложении. SKStoreReviewRequest.requestReview() (iOS) и ReviewManager.requestReview() (Android) — запрашивайте отзыв в правильный момент: после позитивного события, не при первом запуске.

Fastlane: автоматизация публикации

Ручная публикация — сертификаты, provisioning profiles, сборка, загрузка в App Store Connect или Google Play Console — занимает час и легко ошибиться. Fastlane автоматизирует весь пайплайн.

Ключевые lanes:

  • match — управление сертификатами и provisioning profiles через зашифрованный Git-репозиторий. Вся команда использует одни сертификаты, нет проблем «сертификат истёк на машине разработчика». fastlane match appstore — синхронизация перед сборкой.

  • gym (build) — fastlane gym --scheme "AppName" --configuration Release --export_method app-store. Через Gymfile параметры фиксируются в репозитории.

  • deliver (upload to App Store) — загружает бинарник, метаданные, скриншоты. Скриншоты можно держать в репозитории через fastlane snapshot (автоматическая генерация через XCUITest).

  • supply — аналог deliver для Google Play, поддерживает all tracks (internal, alpha, beta, production) с rollout параметром для поэтапного выкатывания.

Типичный Fastfile:

lane :release_ios do
  match(type: "appstore")
  gym(scheme: "App")
  deliver(submit_for_review: true, automatic_release: false)
end

lane :release_android do
  gradle(task: "bundle", build_type: "Release")
  supply(track: "production", rollout: "0.1")
end

Интеграция с CI/CD: Fastlane + GitHub Actions или Bitrise — стандартный стек. Переменные среды для API ключей App Store Connect и Google Service Account. Код подписывается автоматически при мерже в main.

Поэтапный выкат и rollback

Google Play поддерживает постепенное развёртывание: rollout: "0.05" — 5% пользователей получают обновление сначала. Мониторим Crashlytics/Firebase Crashlytics, crash-free rate, ANR rate. Если показатели ухудшились — останавливаем rollout через Play Console без отзыва релиза.

App Store не имеет поэтапного выкатывания для обычных приложений (есть Phased Release для app updates — 7-дневный постепенный выкат). Для более гибкого управления используем feature flags (Firebase Remote Config, LaunchDarkly) — новый функционал выключен по умолчанию, включаем через конфиг без нового релиза.

Что входит в работу по публикации

Мы готовим полный комплект для выхода в сторах:

  • Создание и настройка аккаунтов разработчика (Apple Developer Program, Google Play Console) с корпоративными доступными.
  • Подготовка метаданных: название, описание, ключевые слова, категория, возрастной рейтинг.
  • Настройка Privacy Policy и App Privacy Labels / Data Safety Form.
  • Генерация и установка сертификатов, provisioning profiles (через match или вручную).
  • Сборка и подпись бинарника с правильной конфигурацией (Code Signing, ProGuard/R8).
  • Загрузка бинарника и метаданных с помощью Fastlane или вручную.
  • Прохождение ревью: анализ тикетов, апелляции при необходимости, корректировка.
  • Настройка поэтапного выката и мониторинг метрик после релиза.
  • Обучение команды работе с TestFlight / Firebase App Distribution.

Что мы не делаем

Не пишем код приложения, не занимаемся маркетингом (кроме ASO-рекомендаций), не регистрируем торговые марки. Наша зона — техническая подготовка к публикации и сопровождение до первого релиза.

Сроки и стоимость

Подготовка первого релиза: настройка аккаунтов, сертификатов, метаданных, скриншотов, Privacy Policy — от 3 до 5 рабочих дней при наличии всех материалов. Настройка Fastlane + CI/CD — от 2 до 3 дней. Ревью App Store — от 1 до 3 дней. Итого от готового приложения до публикации — от 1 до 2 недель.

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

Типичные ошибки, которые мы находим на аудите

Чек-лист: что проверить перед отправкой
  • [ ] Указаны все разрешения в манифесте (Android) или Info.plist (iOS) с пояснениями
  • [ ] Privacy Manifest (iOS) содержит все required reason APIs
  • [ ] Data Safety Form (Android) заполнена корректно
  • [ ] Тест-аккаунт активен и имеет реалистичные данные
  • [ ] Нет внешних ссылок на оплату внутри IAP-продуктов
  • [ ] Скриншоты соответствуют актуальной версии интерфейса
  • [ ] Версия билда инкрементирована
  • [ ] Код подписан правильным сертификатом (Distribution, не Development)
  • [ ] 64-bit сборка присутствует
  • [ ] Отсутствуют упоминания конкурентов в метаданных

Почему стоит доверить публикацию нам?

У нас 7+ лет опыта в мобильной разработке, более 50 успешно опубликованных приложений для iOS и Android. Знаем все подводные камни App Store Review Guidelines (разделы 4.2, 5.1) и политик Google Play. Используем Fastlane, CI/CD, автоматические проверки метаданных — чтобы вы не тратили время на рутину. Закажите консультацию — расскажем, как сократить цикл публикации вдвое.