Чек-лист отправки в App Store (2026): от сборки в Xcode 26 до Submit for Review

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

Что нужно для отправки в App Store до нажатия Submit?

Для отправки в App Store нужны обработанная сборка, привязанная к версии, обязательные метаданные версии, скриншоты, политика конфиденциальности, контактные данные для App Review и, если в приложении есть вход, рабочие демо-учётные данные. Собственный список Apple «Before You Submit» в App Review Guidelines добавляет ещё два пункта: «Включите бэкенд-сервисы, чтобы они работали и были доступны во время проверки», а также объясните неочевидные функции в заметках для проверки.

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

Вам нужны активное членство в Apple Developer, запись приложения, bundle ID которой совпадает с подписанной сборкой, и человек в команде с ролью Account Holder, Admin или App Manager. Именно эти роли страница Apple Submit an app требует для отправки.

При создании записи выберите название, основной язык и SKU. SKU — внутренний идентификатор, покупатели его никогда не видят. Если вы продаёте платное приложение или встроенные покупки, сначала оформите соглашения о платных приложениях, налоговые и банковские данные. Неподписанное соглашение может задержать коммерческий запуск, даже если со сборкой всё в порядке.

Какие требования к сборке действуют для загрузок в App Store в 2026 году?

По состоянию на октябрь 2026 года на странице Apple upcoming requirements сказано: «Приложения, загружаемые в App Store Connect, должны быть собраны в Xcode 26 или новее с SDK для iOS 26, iPadOS 26, tvOS 26, visionOS 26 или watchOS 26» (с 28 апреля 2026 года). Там же указано, что приложения для iOS и iPadOS «должны быть рассчитаны на iOS 13 или новее» (с 9 сентября 2026 года).

• Увеличивайте номер сборки при каждой загрузке и следите, чтобы номер версии совпадал с релизом, который вы собираетесь выпустить.
• Обновите образ Xcode в CI (Codemagic, Expo EAS, GitHub Actions и т. д.), а не только на своём компьютере.
• После обработки ответьте на запрос об экспортном контроле, если он появится, и привяжите обработанную сборку к версии.
• Установите сборку из TestFlight на физическое устройство. Проверьте онбординг, вход, офлайн-состояния, покупки и восстановление покупок. Успешный запуск в симуляторе не доказывает, что распространяемая сборка работает.
• Читайте письмо, которое App Store Connect присылает после загрузки. Предупреждения ITMS о манифестах конфиденциальности или версиях SDK превращаются в блокеры, если их игнорировать.

Правило 2.1(a) прямо говорит, что будет в противном случае: «Мы отклоняем неполные пакеты приложений и бинарные файлы, которые падают или имеют очевидные технические проблемы». Уберите экраны-заглушки, отладочные меню и битые ссылки до создания архива. В нашем плане тестирования релизной сборки для правила 2.1 эти проверки разобраны подробно.

Какие скриншоты и метаданные требует App Store Connect?

По состоянию на октябрь 2026 года спецификации скриншотов Apple требуют как минимум один скриншот для «iPhone with Dynamic Island (medium display)», например 1206 × 2622 или 1179 × 2556 в портретной ориентации. Приложениям, работающим на iPad, также нужен как минимум один скриншот для iPad 13 дюймов, например 2064 × 2752 или 2048 × 2732.

Вы «можете загрузить до 10 скриншотов для каждого размера устройства в форматах .jpeg, .jpg или .png», и «изображения не должны содержать альфа-каналов или прозрачности». Если интерфейс одинаков на всех размерах, загрузите только максимальное обязательное разрешение, и App Store Connect уменьшит его. Правило 2.3.3 гласит, что скриншоты «должны показывать приложение в работе, а не только титульную графику, страницу входа или заставку».

• Напишите описание, из которого понятно, для кого приложение и что человек сможет сделать в первой же сессии.
• Название, подзаголовок и ключевые слова должны быть релевантными. Не повторяйте ключевые слова и не используйте названия конкурентов.
• Убедитесь, что URL поддержки и URL политики конфиденциальности открываются без входа в аккаунт.
• Отвечайте на анкету возрастного рейтинга исходя из того, что приложение действительно содержит и умеет.
• Показывайте на скриншотах текущую сборку, включая пейвол, на который попадёт пользователь.

Как добиться, чтобы ответы о конфиденциальности соответствовали приложению?

Чтобы ответы о конфиденциальности соответствовали приложению, составьте список всех SDK, которые вы поставляете, и данных, которые они собирают, а затем по этому списку заполните раздел App Privacy, напишите политику конфиденциальности и настройте поведение в приложении. Правило 2.3 гласит, что ваши метаданные, «включая информацию о конфиденциальности», должны точно отражать приложение.

Правило 5.1.1(i) гласит: «Все приложения должны содержать ссылку на политику конфиденциальности в поле метаданных App Store Connect и в легкодоступном месте внутри приложения». Правило 5.1.1(v) добавляет: «Если ваше приложение поддерживает создание аккаунта, вы также должны предоставить возможность удалить аккаунт в приложении». SDK аналитики, отчётов о сбоях, рекламы и входа обычно меняют ваши ответы, поэтому проверьте их с помощью нашего аудита SDK для меток конфиденциальности. Также убедитесь, что ваше приложение и каждый встроенный SDK содержат манифест конфиденциальности PrivacyInfo.xcprivacy, охватывающий все используемые API, требующие указания причины (required-reason APIs).

Что должно быть в разделе App Review Information?

В App Review Information должны быть контакт, который действительно ответит, рабочие демо-учётные данные без срока истечения и заметки, которые сразу ведут ревьюера к ключевым функциям. Правило 2.1(a) просит «указать данные демо-аккаунта (и включить бэкенд-сервис!), если в приложении есть вход»; встроенный демо-режим вместо аккаунта требует предварительного одобрения Apple.

Вот пример заметок для проверки: «Войдите с помощью предоставленного аккаунта для проверки. Откройте Library, выберите пример проекта и нажмите Export. В аккаунте разблокированы все премиум-функции. Функции геолокации используют симулированный город, поэтому никуда ехать не нужно». Не отправляйте ревьюеров в пустой аккаунт, к одноразовому коду, который истекает, или в сценарий, который работает только пока вы онлайн и вручную его подтверждаете. В нашем руководстве по настройке демо-аккаунта показано, как сделать надёжный вход для ревьюера.

Как отправить приложение на проверку в App Store Connect?

Чтобы отправить приложение на проверку, привяжите сборку к версии, нажмите Add for Review, а затем Submit for Review. Одна только кнопка Add for Review ничего не отправляет в Apple. Последовательность ниже соответствует странице Apple «Submit an app» по состоянию на октябрь 2026 года.

1. В разделе Apps выберите приложение, затем нажмите на версию приложения в боковой панели.
2. Прокрутите до раздела Build и убедитесь, что привязана правильная сборка.
3. В разделе App Store Version Release выберите ручной выпуск, если хотите сами управлять днём запуска, затем нажмите Save.
4. Нажмите Add for Review и выберите существующий черновик отправки или создайте новый. Статус изменится на Ready for Review.
5. Нажмите Submit for Review. Когда проверка начнётся, статус изменится на In Review.
6. Сохраните копию отправленных метаданных и заметок и следите за почтой контакта для проверки на случай вопросов.

Если отправку отклонили, прочитайте номер правила и пояснение ревьюера, прежде чем что-либо менять. Некоторые исправления касаются только метаданных. Для других нужна новая сборка. В нашем руководстве по отказам в App Store разобрано, как понять, какой у вас случай.

Что пошло не так у других разработчиков при отправке?

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

Разработчик на форуме Adalo получил отказ по правилу 2.1: «нам не удалось войти с предоставленными вами учётными данными демо-аккаунта». Учётные данные были верными, но первое нажатие на кнопку входа ничего не делало, и срабатывало только второе, потому что условная навигация выполнялась на кнопке входа до регистрации пользовательской сессии. Проблему решили, направив кнопку входа на пустой переходный экран с условными действиями, после чего приложение отправили повторно.

Разработчик на форуме JUCE после загрузки получил «ITMS-91053: Missing API declaration» с сообщением, что новые загрузки «должны содержать массив NSPrivacyAccessedAPITypes в манифесте конфиденциальности приложения». Отмеченными категориями были SystemBootTime и FileTimestamp, а другой пользователь сообщил о UserDefaults. Решением стал файл PrivacyInfo.xcprivacy с утверждёнными кодами причин, добавленный как ресурс Xcode. В первой версии у одного пользователя не хватало ключа типа, из-за чего возникала ошибка ITMS-91056 о недействительном манифесте, пока он её не исправил.

Оба разработчика тестировали только на своей конфигурации. Прежде чем нажать Submit for Review, проверьте сборку, которую действительно получает Apple, со свежим входом в аккаунт и прочитайте каждое письмо после загрузки. Если хотите, чтобы пакет посмотрел кто-то ещё, ознакомьтесь с нашими услугами по отправке.