Публикация приложения в App Store: актуальный checklist до ревью

Коротко: четыре ворот до Submit

Готовность удобно проверять четырьмя воротами. Организация владеет аккаунтом, договорами, банковскими и налоговыми данными. Артефакт собран правильным идентификатором, сертификатами, entitlement и поддерживаемым SDK. Соответствие покрывает данные, аккаунты, платежи, контент, возраст и региональные ограничения. Проверяемость означает, что незнакомый человек может пройти главный путь по ясным инструкциям и увидеть заявленные функции.

1. Владение, роли и соглашения

Аккаунт Apple Developer должен принадлежать бизнесу, который управляет продуктом и имеет права на бренд, код, контент и распространение. Не стройте актив на личном Apple Account подрядчика. Проверьте юридическое имя продавца, D‑U‑N‑S и данные организации, доступ Account Holder, резервный контакт и многофакторную аутентификацию. Разработчику выдавайте минимально достаточную роль в App Store Connect; пароли и личные коды не должны путешествовать по чатам.

Account Holder проверяет членство, принимает актуальные соглашения. Для платного приложения или In‑App Purchase нужны действующие paid applications agreements, налоговые формы и банковские реквизиты. Отдельно фиксируют, кто вправе подписывать документы, кто отвечает на сообщения App Review и кто принимает решение о выпуске. До загрузки сборки подтвердите права на торговые марки, пользовательский контент, музыку, карты, медицинские сведения и иные лицензируемые материалы. Если продукт сделан для клиента, публикация в аккаунте разработчика допустима не по умолчанию, а только когда это соответствует правилам и согласованной модели владения.

2. Bundle ID, signing и релизная сборка

Bundle ID в Xcode, Identifiers и карточке App Store Connect должен совпадать. Проверьте SKU, version и build number, display name, minimum OS, семейство устройств и список регионов. Signing включает distribution certificate или managed signing, provisioning profile и только нужные capabilities: push, Sign in with Apple, associated domains, app groups, keychain sharing, health, location. Лишний entitlement — такой же риск, как отсутствующий.

С 28 апреля 2026 года загрузки в App Store Connect должны быть собраны с Xcode 26 и SDK 26. Это требование действует с указанной даты; проверяйте текущую страницу Apple Upcoming Requirements перед каждой отправкой, потому что следующий порог может измениться. Собирайте Release-конфигурацию из зафиксированного commit, без debug-меню, тестовых URL и секретов. Archive должен проходить validation, а экспортированные символы dSYM — попадать в систему crash reporting. Privacy manifests и signatures сторонних SDK проверяют по фактическим зависимостям, а не по старому списку из документации проекта.

Перед кандидатом заморозьте версии API и конфигурацию remote flags. Проверьте production backend, universal links, push-среду production, сертификаты сервера, миграции базы, rate limits и поведение при отключённом сервисе. TestFlight полезен как канал доставки, но успешная beta-проверка не означает автоматического соответствия App Review.

3. Privacy: данные, permissions и сторонние SDK

App Privacy в App Store Connect — декларация о данных приложения и подключённых партнёров. Начните с инвентаризации: какие данные собираются на устройстве и сервере, связаны ли они с личностью, применяются ли для tracking, для какой цели, сколько хранятся и кому передаются. Сопоставьте таблицу с сетевыми запросами релизной сборки, privacy policy, consent-экранами и настройками SDK. Аналитика, атрибуция, crash reporting, support chat и карты входят в аудит, даже если их внедрил поставщик.

Запрос камеры, фото, микрофона, геолокации, Bluetooth или контактов должен появляться в контексте понятного действия. Purpose strings описывают реальную пользу человеческим языком. Приложение обязано корректно переживать отказ и вести в Settings только когда это действительно помогает. Для tracking действует ATT; нельзя заменять отказ fingerprinting или скрытым идентификатором. Если функция работает без персональных данных, не делайте согласие условием входа.

Privacy policy должна открываться по публичному HTTPS URL, соответствовать продукту и содержать контакты, категории данных, цели, получателей, хранение и способы реализации прав. Это не юридическая консультация: требования закона зависят от юрисдикции и аудитории. Apple задаёт магазинные правила, а применимое право — отдельный слой.

4. Удаление аккаунта, login и demo-доступ

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

Если есть сторонний социальный вход, проверьте применимость требования Sign in with Apple и равенство ключевого опыта. Не заставляйте регистрироваться там, где аккаунт не нужен главной функции. Для ревью подготовьте отдельный стабильный аккаунт с нужной ролью, наполненными данными и отключённым истечением пароля. Если используется MFA, дайте воспроизводимый механизм, не зависящий от телефона сотрудника. Для геозависимых, аппаратных, корпоративных или управляемых функций приложите видео и объяснение, но не считайте видео заменой доступной сборки.

5. In‑App Purchase и экономика доступа

Цифровые функции, контент и подписки, потребляемые внутри приложения, обычно должны использовать In‑App Purchase. Физические товары и услуги вне приложения — например доставка еды или поездка — относятся к иной платёжной логике. Reader apps, entitlement и отдельные региональные правила имеют точные условия; нельзя брать исключение из статьи или чужого приложения и объявлять его универсальным. Сверяйте действующие App Review Guidelines и документы StoreKit для конкретной витрины.

Создайте продукты в App Store Connect, локализации, цены и review screenshot. Проверьте product ID, статусы availability и tax category. В StoreKit-тестах пройдите успешную покупку, отмену, pending, Ask to Buy, refund, billing retry, grace period, upgrade, downgrade и restore. Сервер должен проверять транзакции и обрабатывать App Store Server Notifications идемпотентно. Экран подписки ясно показывает период, цену, пробный режим, автопродление, условия и ссылку на управление. Нельзя оставлять кнопку, которая ведёт в тупик только в review-регионе.

6. Метаданные, возраст и честная карточка

Название, subtitle, description, keywords, promotional text, category, support URL, marketing URL и copyright проверяют как единый контракт. Скриншоты должны соответствовать реальной версии, локали и устройству; не показывайте будущие функции, чужие интерфейсы, ложные награды или неподтверждённые сравнения. Иконка читается в малом размере и не копирует системные обозначения. App Preview демонстрирует продукт, а не превращается в рекламный ролик, скрывающий интерфейс.

Новая система возрастных рейтингов действует с 31 января 2026 года. Ответы в анкете должны отражать доступный контент, пользовательские публикации, рекламу, web view, коммуникации, покупки и родительские механизмы. Возрастной рейтинг — не маркетинговый выбор: если контент меняется через сервер, модерация и ограничения также входят в оценку. Для Kids Category и приложений с детской аудиторией проверка privacy, рекламы, ссылок и родительских ворот особенно строга.

Экспортное соответствие, шифрование, контентные права, routing coverage, game controller и иные поля заполняют по функциям конкретной сборки. Availability по странам согласуют с лицензиями, языками, ценами и серверной готовностью. Контакт support должен отвечать, а страница поддержки — открываться без авторизации.

7. Reviewer notes и journey без догадок

Ревьюер не участвовал в продуктовых встречах. В App Review Information дайте контакт, который действительно доступен команде, рабочий demo-account и компактный маршрут. Начните с главной ценности: «войдите, откройте Заказы, выберите заказ Demo‑104, нажмите Оплатить». Затем объясните нестандартные жесты, роли, hardware, фоновые режимы, IAP, географию и функции под feature flag. Укажите, что именно изменилось в этой версии.

Если сервер ожидает allowlist, VPN, расписание магазина или ручное одобрение, устраните зависимость либо дайте надёжный путь. Ревьюеру нужны данные, на которых видны пустые, успешные и ошибочные состояния. Notes не должны спорить с правилами или перегружать историей проекта; их задача — сделать проверку воспроизводимой. Видео, документация и лицензии прикладываются как доказательства для сценария, который невозможно физически повторить в обычной среде.

8. P0 QA: что блокирует отправку

P0 — дефект, при котором отправка запрещена. Сюда относятся crash или зависание на запуске и главном пути; невозможность войти; потеря или раскрытие данных; неработающая покупка или restore; обход paywall; неверная среда backend; обязательное разрешение без fallback; неработающее удаление аккаунта; недоступная privacy/support page; функция из метаданных, которой нет; тестовые данные и секреты в production.

Пройдите clean install, update с предыдущей публичной версии и повторный запуск после выгрузки. Тестируйте поддерживаемые iPhone и iPad, минимальную и актуальную ОС, светлую и тёмную тему, крупный текст, VoiceOver, поворот, слабую сеть, offline и восстановление соединения. Проверьте deep links, push из закрытого состояния, системное время, локаль, часовой пояс, отказ во всех permissions и заполненное хранилище. Для каждой проблемы есть severity, владелец, build с исправлением и retest.

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

9. Submit, стратегия выпуска и мониторинг

Перед Submit выберите нужную сборку, заполните compliance, content rights, advertising identifier, Game Center и review information, свяжите IAP, проверьте локализации и сохраните снимок конфигурации. Назначьте ответственного за релиз. Варианты выпуска — автоматически после одобрения, вручную или phased release, если они доступны для выбранного типа релиза. Выбор зависит от готовности поддержки, backend, маркетинга и возможности остановить rollout; он не меняет решение App Review.

Не привязывайте публичную кампанию к обещанию одобрения в конкретный день. Apple управляет review, а статусы могут потребовать ответа или новой сборки. После выхода проверьте видимость по регионам, страницу, IAP, server notifications, deep links и установку как новый пользователь. Наблюдайте crashes, hangs, launch time, авторизацию, платежи, API errors, отзывы и обращения поддержки. Зафиксируйте пороги инцидента и владельцев: кто отключает feature flag, кто выпускает hotfix, кто отвечает пользователям.

Phased release снижает охват проблемы обновления, но не защищает новых установщиков и не заменяет серверный rollback. Если дефект опасен для данных или денег, решение принимают по риску, а не по красоте релизного календаря. Для следующей версии обновите журнал SDK, privacy и метаданных: соответствие — процесс, а не одноразовый документ.

10. Отклонение: решение и ответ

Отклонение — не повод сразу пересобирать приложение или спорить. Скопируйте сообщение, guideline, screenshots и шаги; зафиксируйте build и регион. Затем воспроизведите путь на той же конфигурации и выберите ветку. Дефект подтверждён: исправьте причину, пройдите regression и в ответе укажите, что изменилось и где проверить. Недопонимание: ответьте фактами, точными шагами, видео или документом, не меняя сборку без необходимости. Требование затрагивает модель продукта: остановите автоматическую пересдачу и привлеките владельца бизнеса, privacy/legal и разработку.

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

First-party границы: чему доверять

Источник требований — актуальные first-party материалы Apple: App Review Guidelines, App Store Connect Help, Developer Program License Agreement, Upcoming Requirements, Human Interface Guidelines и документация используемых API. Сообщение в Resolution Center относится к конкретной отправке и тоже имеет приоритет для ответа. Статьи агентств, форумы, видео и этот checklist помогают организовать работу, но не создают исключений и не заменяют договор или юридическую оценку.

Факты про Xcode 26/SDK 26 с 28 апреля 2026 года и новую возрастную систему с 31 января 2026 года датированы. Перед отправкой откройте первоисточник ещё раз. То же относится к IAP, reader apps, внешним ссылкам, privacy manifests и региональным entitlement: границы меняются, а применимость зависит от storefront и бизнес-модели. Мы не обещаем срок review, отсутствие дополнительных вопросов или одобрение.

Когда отдельная услуга публикации не нужна

Не заказывайте сопровождение только ради загрузки архива, если внутри уже есть ответственный за релиз, Account Holder, актуальные договоры, воспроизводимый pipeline, проверенные signing и backend, владелец privacy, настроенные IAP, готовая карточка, demo journey, P0 QA и дежурство после выхода. В такой команде Submit — штатная операция, а внешний исполнитель добавит доступы и коммуникационный слой без заметной пользы.

Услуга также преждевременна, если продукт ещё не готов: нет прав на контент, сервер нестабилен, платежная модель не определена или критичный сценарий не прошёл QA. Публикационный специалист не исправит архитектуру одной настройкой App Store Connect. Сначала закройте причину. Если вы только выбираете технологический маршрут, начните с материала про создание приложения для iOS, а не с подготовки карточки магазина.

Официальные источники и дата проверки

Платформенные сведения проверены 30 июля 2026 года. Для каждой новой версии повторно сверяйте первоисточники Apple.

• Apple App Review Guidelines.
• App Store Connect Help.
• Apple Upcoming Requirements.
• Apple: App Privacy Details.
• Apple In‑App Purchase и StoreKit.

FAQ

Можно ли гарантировать прохождение App Review?

Нет. Решение принимает Apple, а требования и контекст конкретной проверки могут меняться. Команда может снизить риск: проверить правила, сборку, privacy, платежи, метаданные и полный путь ревьюера, но не обещать одобрение или дату публикации.

Нужен ли тестовый аккаунт для ревью?

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

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

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

Когда нужен In-App Purchase?

Для разблокировки цифрового контента, функций или подписок внутри приложения обычно применяется In-App Purchase. Физические товары и услуги, потребляемые вне приложения, относятся к другой категории. Исключения, entitlement и региональные условия нельзя переносить между витринами без проверки актуальных правил.

Что делать после отклонения приложения?

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

Когда услуга публикации в App Store не нужна?

Отдельная услуга не нужна, если у вашей команды уже есть владелец аккаунта, актуальные соглашения, воспроизводимый release pipeline, корректные privacy и IAP-настройки, готовая карточка, P0 QA и специалист, который сопровождает review и релиз. Не передавайте внешний доступ только ради нажатия Submit.

Проверим релизный контур до Submit

Пришлите описание продукта, Bundle ID, список SDK, модель входа и оплаты, черновик карточки, страны запуска и TestFlight-сборку. 13FOX соберёт карту блокеров по владению, build, privacy, IAP, пути ревьюера и P0 QA, отделит обязательные исправления от рекомендаций и подготовит план сопровождения review. Решение и сроки остаются за Apple; наша задача — сделать отправку воспроизводимой и доказательной.

Разобрать публикацию