Сначала определите источник шифрования в полной сборке: если приложение использует только системные возможности Apple, обычно достаточно корректно ответить на анкету и настроить ITSAppUsesNonExemptEncryption; если внутри есть сторонняя стандартная криптография или собственный алгоритм, подготовьте дополнительные сведения и не отмечайте «без шифрования» наугад. Этот порядок подходит для сборок, которые уже загружены, но остановлены на этапе Missing Compliance.
Вы читаете этот материал, если после загрузки в TestFlight сборка не переходит к распространению, если в проекте есть HTTPS, Keychain, SDK авторизации, платежи или сквозное шифрование, а также если вы регулярно публикуете через удалённый Mac и хотите исключить повторную ручную проверку.
SECTION 01App Store Connect Missing Compliance: что именно остановилось
Missing Compliance означает, что для конкретной загруженной сборки не хватает информации об экспортном соответствии. Это не равнозначно ошибке подписи, статусу Invalid Binary или длительной обработке сборки. Apple отдельно описывает состояния сборок и экспортные сведения в документации App Store Connect; перед исправлением проверьте именно статус сборки, а не только сообщение в интерфейсе в справке Apple о статусах сборок.
В обезличенном сценарии публикации архив был успешно создан и принят сервером, но карточка сборки в TestFlight показывала Missing Compliance. Разработчик уже проверил сертификат и provisioning profile, хотя проблема находилась в другом слое: для этой версии не был завершён экспортный опрос.
Не смешивайте четыре разных объекта:
- сборка — архив и загруженный бинарный пакет;
- экспортная анкета — ответы о применяемом шифровании;
- материалы или код подтверждения — дополнительные сведения, когда их требует конкретный случай;
- подпись и разрешения — сертификаты, профили и права аккаунта.
Последовательность исправления должна быть такой:
- Проверьте статус загруженной сборки в App Store Connect.
- Составьте перечень шифрования в полном приложении.
- Отнесите проект к одному из трёх маршрутов: достаточно анкеты, требуется дополнительная проверка, нужны материалы или одобрение.
- Ответьте на вопросы для нужной сборки или свяжите уже одобренные сведения.
- Проверьте финальный
Info.plist, если хотите уменьшить повторные запросы. - Для изменения конфигурации создайте и загрузите новую сборку.
Как понять, что можно использовать TestFlight
После появления Missing Compliance приложение сразу доступно внутренним тестировщикам?
Не следует считать установку гарантированной. Пока для сборки не предоставлена требуемая экспортная информация, её дальнейшее использование в TestFlight может быть ограничено. Откройте карточку сборки и перейдите к действию Provide Export Compliance Information; Apple описывает этот процесс отдельно для бета-сборок в инструкции по экспортному соответствию для TestFlight.
Если после ответа на анкету статус меняется, но сборка всё ещё недоступна, отдельно проверьте:
- завершилась ли обработка загрузки;
- не появилась ли ошибка подписи или недействительного бинарного файла;
- назначены ли тестировщики именно этой сборке;
- не ожидаются ли дополнительные материалы;
- не загружена ли новая версия с тем же номером, но другим идентификатором сборки.
SECTION 02Сценарий первый: только системные возможности Apple
Наиболее простой случай — приложение не содержит собственной криптографии, а использует системные API macOS или iOS. К нему могут относиться сетевые запросы через HTTPS, хранение секретов в Keychain и другие функции операционной системы, если вы не добавили поверх них отдельную реализацию шифрования.
Это не означает, что любой проект с HTTPS автоматически освобождён от дальнейшей проверки. Объектом оценки является не строка в исходном коде, а загруженная сборка. В ней могут присутствовать:
- код самого приложения;
- статически подключённые библиотеки;
- динамические фреймворки;
- SDK авторизации и платежей;
- бинарные зависимости менеджера пакетов;
- встроенные модули аналитики или защищённого хранения;
- функции, активируемые только в Release-конфигурации.
Как отвечать, если приложение использует HTTPS и Keychain, но не содержит собственной криптографии?
Сначала подтвердите, что HTTPS обслуживается системным сетевым стеком, а Keychain используется как системное защищённое хранилище, без встроенного алгоритма или отдельного криптографического движка. Затем отвечайте на вопросы App Store Connect по фактической реализации проекта, а не по предположению «шифрования нет».
Apple разъясняет общий подход к экспортному соответствию и использованию шифрования в обзоре экспортных требований для приложений. Ответ анкеты не заменяет юридическое заключение для каждой страны, отрасли или бизнес-модели.
Сохраните внутреннее подтверждение:
- список зависимостей из Release-сборки;
- названия подключённых фреймворков и библиотек;
- краткое описание сетевого стека;
- сведения о включённых и выключенных функциях SDK;
- копию ответов анкеты;
- скриншот результата в App Store Connect без аккаунта, ключей и идентификаторов.
Такой пакет не обязательно отправлять Apple. Он нужен, чтобы через месяц не повторять исследование с нуля и чтобы другой участник команды мог проверить основание принятого решения.
Что означает ITSAppUsesNonExemptEncryption
ITSAppUsesNonExemptEncryption отвечает на вопрос, использует ли приложение шифрование, которое не относится к освобождённым случаям. Это не переключатель, отключающий криптографию, и не способ исправить неверную классификацию.
Когда выбирать NO, а когда YES?
NO имеет смысл только после проверки того, что приложение не использует неосвобождённое шифрование и соответствует основанию, на котором вы отвечаете в экспортной анкете. YES уместен, когда в конечной сборке действительно присутствует соответствующее шифрование и оно не подтверждено как освобождённое. Отсутствующее значение не означает автоматически «нет шифрования» — оно может привести к дополнительному вопросу при загрузке.
Актуальное назначение ключа и его тип Apple описывает в документации ITSAppUsesNonExemptEncryption. После изменения значения нельзя ограничиваться проверкой исходного файла проекта: ключ должен попасть в Info.plist финального архива.
SECTION 03Сценарий второй: сторонняя стандартная криптография
Второй случай сложнее: приложение подключает библиотеку или SDK, внутри которого реализованы стандартные криптографические алгоритмы. Например, SDK может защищать собственный канал связи, токены, локальное хранилище или обмен между клиентом и сервером. То, что в бизнес-коде нет вызова алгоритма, ещё не доказывает отсутствие криптографии в бинарном файле.
Нужны ли дополнительные материалы, если шифрование спрятано внутри SDK авторизации или оплаты?
Не делайте вывод по названию SDK. Проверьте официальную документацию поставщика, состав бинарного пакета, список активных функций и поведение Release-сборки. Отдельно установите, используется ли только системная криптография или библиотека приносит собственную реализацию.
Затем сопоставьте факты с вопросами App Store Connect:
- какой компонент выполняет шифрование;
- является ли алгоритм стандартным;
- защищает ли он только служебное соединение или является основной функцией продукта;
- в каких странах распространяется приложение;
- есть ли у поставщика SDK готовая классификация или декларация;
- требуется ли для вашей схемы отдельное подтверждение.
Для американского экспортного анализа нельзя заменять классификацию догадкой из форума: сверяйте описание с официальными материалами Bureau of Industry and Security по вопросам шифрования. Это не означает, что ответ BIS автоматически закрывает требования App Store Connect или других юрисдикций.
Французское распространение также нельзя оценивать одной общей фразой «HTTPS разрешён». Для него могут иметь значение назначение криптографической функции и местные процедуры; используйте разъяснение французского регулятора о контроле средств криптографии. Если проект продаёт защищённую связь, хранение секретов или корпоративную безопасность как основной продукт, привлеките специалиста по экспортному контролю.
Сравнение маршрутов принятия решения
| Ситуация в полной сборке | Что проверить | Типичный следующий шаг | Основной риск |
|---|---|---|---|
| Только системные HTTPS, Keychain и API Apple | Нет ли внешнего криптографического движка | Ответить на анкету и при подтверждённом основании настроить Info.plist |
Принять решение только по исходному коду |
| Сторонний SDK со стандартными алгоритмами | Документацию, бинарный состав, включённые функции и регионы распространения | Сопоставить факты с анкетой, подготовить сведения или материалы | Считать любой SDK автоматически освобождённым |
| Собственный протокол или нестандартный алгоритм | Назначение, описание алгоритма, классификацию и юрисдикции | До публикации получить профессиональную оценку и подготовить документы | Пытаться скрыть криптографию параметром Info.plist |
| Приложение — продукт безопасности | Основную функцию и фактические криптографические возможности | Отдельно проверить экспортные и региональные требования | Принять анкету Apple за универсальное юридическое разрешение |
SECTION 04Сценарий третий: собственный протокол и продукт безопасности
Если команда создала собственный протокол, использует алгоритм, не принятый признанным стандартным органом, или продаёт защищённое хранение и коммуникации как центральную возможность продукта, не начинайте с подмены значения в Info.plist.
В этой ситуации соберите техническое описание:
- какие данные шифруются;
- где выполняется операция — на устройстве, сервере или в обоих местах;
- какие алгоритмы и режимы применяются;
- какие библиотеки входят в приложение;
- можно ли отключить функцию без потери основного назначения;
- в какие страны отправляется сборка;
- какие материалы уже получены от поставщиков или регуляторов.
Не смешивайте разные документы и их назначение:
- CCATS относится к определённой процедуре классификации в американском экспортном контексте;
- французская декларация или разрешительная процедура относится к требованиям французской юрисдикции;
- экспортная анкета Apple нужна для обработки информации о конкретной сборке в App Store Connect;
- код подтверждения Apple, если он выдан для соответствующей схемы, связывает ранее обработанные сведения с загрузкой, но не превращает неизвестную реализацию в освобождённую.
Apple отдельно рассматривает соблюдение требований к экспорту шифрования в своём техническом руководстве. При неоднозначной реализации лучше заранее получить консультацию специалиста с опытом экспортного контроля, чем пытаться пройти анкету через формально удобный ответ.
Важно: не публикуйте в тикете или скриншоте исходные API-ключи, коды подтверждения, Bundle ID, внутренние названия SDK и фрагменты журнала с учётными данными. Для внутренней проверки используйте обезличенную копию.
SECTION 05Пошаговая проверка финального архива
Шаг первый: зафиксируйте состояние блокировки
Сохраните название статуса, идентификатор сборки в обезличенном виде и время загрузки. Не исправляйте одновременно подпись, зависимости и экспортные параметры: иначе вы не поймёте, какое изменение повлияло на результат.
Шаг второй: составьте карту зависимостей
Проверьте Release-конфигурацию, а не только Debug. Зафиксируйте статические библиотеки, динамические фреймворки, SDK и их активные модули. Если поставщик не объясняет криптографическую часть, запросите состав бинарного пакета и описание функций.
Шаг третий: определите маршрут анкеты
Разделите проект на «только системные возможности», «сторонняя стандартная реализация» и «собственная или нестандартная криптография». Для второго и третьего маршрута не обещайте себе освобождение до проверки документации и регионов распространения.
Шаг четвёртый: проверьте Info.plist внутри архива
Откройте экспортированный архив и найдите Info.plist именно приложения, которое будет загружено. Проверка настроек в Xcode недостаточна: значение могло быть переопределено конфигурацией, скриптом сборки или отдельным target.
Если подтверждено основание для NO, внесите изменение в источник конфигурации, затем снова создайте Archive. Если значение должно быть YES, не используйте его как замену материалам или ответам анкеты.
Шаг пятый: загрузите новую сборку
Изменение Info.plist не меняет уже загруженный бинарный пакет. Создайте новый архив с новым идентификатором сборки, проверьте его содержимое и отправьте через выбранный канал. Общие требования к процессу загрузки Apple перечисляет в руководстве по загрузке сборок.
Шаг шестой: завершите процедуру в TestFlight
В карточке новой сборки откройте Provide Export Compliance Information, ответьте на вопросы по фактическому составу и при необходимости свяжите одобренные сведения. Если для конкретной схемы вы получили ITSEncryptionExportComplianceCode, храните его как секрет и используйте только в предусмотренном Apple процессе.
Шаг седьмой: проведите повторную проверку
Убедитесь, что:
- статус сборки больше не указывает на отсутствие экспортной информации;
- TestFlight показывает сборку нужной группе;
- подпись и entitlements не изменились неожиданно;
- автоматическая загрузка и ручная загрузка приводят к одинаковой классификации;
- в журнале нет секретов;
- команда сохранила основание ответа и дату следующего пересмотра зависимостей.
SECTION 06Как встроить проверку в публикацию через удалённый Mac
Удалённый Mac удобен, когда сборка, подпись и загрузка выполняются регулярно, но сама машина не решает вопрос экспортного соответствия. Ваша задача — добавить контроль до отправки архива и после появления сборки в App Store Connect.
Перед Archive проверяйте список зависимостей и наличие нужного значения в конфигурации. После Archive проверяйте Info.plist внутри итогового пакета. После загрузки сохраняйте обезличенный статус, результат анкеты и номер сборки. При смене SDK запускайте тот же контроль заново, даже если бизнес-код не изменился.
Для команды, которая переносит публикацию на удалённую инфраструктуру, полезно отделить:
- ключи подписи и API Key от журналов сборки;
- экспортные коды от переменных, доступных всем заданиям;
- техническую диагностику от скриншотов App Store Connect;
- проверку криптографии от проверки сертификатов;
- ручное решение по материалам от автоматического шага Archive.
Если вам нужен отдельный хост для повторяемой сборки и проверки архива, параметры аренды удалённого Mac в MACNOX стоит оценивать вместе с требованиями к доступу, хранению секретов и длительности проекта. Для разовой публикации может быть достаточно временного окружения; для постоянного тяжёлого CI важнее заранее рассчитать расходы, резервирование и необходимость физического доступа к устройству.
Три допустимых результата приёмки
- Анкета решает задачу. Сборка использует только подтверждённые системные возможности, ответы сохранены, TestFlight доступен.
- Конфигурация устраняет повторный вопрос. Основание проверено, финальный
Info.plistсодержит нужное значение, новая сборка прошла тот же маршрут. - Нужны материалы и ожидание проверки. Проект содержит стороннюю, собственную или нестандартную криптографию, а команда ещё не получила достаточные документы. В этом случае не маскируйте проблему изменением ключа.
Если после правильного ответа статус не меняется, вернитесь к идентификатору конкретной сборки и проверьте, не смотрите ли вы старый архив. Если в процесс добавлен автоматический загрузчик, сравните его результат с ручной загрузкой и отдельно проверьте полномочия учётной записи.
Для публикационного процесса, который сочетает Archive, подпись и TestFlight, полезно заранее определить границы ответственности: кто отвечает за зависимости, кто подтверждает экспортную классификацию, кто хранит коды и кто принимает решение о выпуске. Аренда Mac не заменяет эти роли, но позволяет выполнить одинаковую последовательность на постоянно доступной macOS-среде; подходящий вариант можно проверить на странице заказа Mac в MACNOX.
Ваша текущая схема может быть неудобна, если локальный Mac занят разработкой, CI-сервер не имеет macOS, архив приходится вручную переносить между компьютерами, а экспортный статус проверяется только после неудачной загрузки. Для небольшой команды это создаёт разрыв между конфигурацией, финальным бинарным файлом и TestFlight. Если вам нужно временное или повторяемое окружение для Archive, проверки Info.plist и публикации, удалённый Mac в MACNOX обычно практичнее отдельной покупки машины только ради редких релизов; при этом для постоянной тяжёлой нагрузки или обязательных физических интерфейсов локальное оборудование может оставаться более подходящим выбором.