App Store Connect: что делать, если PrivacyInfo.xcprivacy недействителен? (2026)

App Store Connect отклонил сборку и сообщил, что PrivacyInfo.xcprivacy недействителен.

Сначала найдите указанный в уведомлении путь и выясните, кому принадлежит файл: приложению, Swift Package или стороннему SDK. Исправьте именно этот источник, затем заново соберите Xcode Archive и запустите проверку перед отправкой. Не удаляйте и не заменяйте манифест, не установив его происхождение.

Статья пригодится разработчикам, которые получили уведомление о недействительном манифесте и хотят локализовать файл в архиве. Она также адресована небольшим командам, обновляющим SDK, и тем, кто проводит сборку и приёмку на удалённом Mac.

Что означает ошибка PrivacyInfo.xcprivacy

PrivacyInfo.xcprivacy — это файл-манифест, в котором описывается использование данных, отслеживание и применение некоторых API, требующих указания разрешённой причины. Он не заменяет сведения о конфиденциальности приложения в App Store Connect: это разные части процесса публикации. Состав и структура манифеста зависят от применяемых деклараций, поэтому сначала нужно определить, какой именно файл не прошёл проверку. Apple описывает назначение и добавление манифеста, а правила его структуры изложены в документации по файлам privacy manifest.

Уведомление App Store Connect может содержать имя файла и путь внутри архива. Этот путь — важнее предположений о том, где файл «должен» находиться в исходниках: он показывает, какой манифест попал в проверяемую сборку. В TN3181 Apple разбирает диагностику недействительных манифестов; используйте инструкцию вместе с фактическим содержимым архива.

Важно не смешивать ответственность разных компонентов. Основное приложение описывает собственное использование API и данных. Зависимость может содержать отдельный манифест, относящийся к ней. Если исправить только файл основного приложения, проверка всё равно может остановиться на манифесте внутри SDK.

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

Проверка целевого объекта приложения

Если путь из уведомления относится к основному приложению, начните с Xcode-проекта. Убедитесь, что PrivacyInfo.xcprivacy включён в фактически собираемую цель, а не просто лежит рядом с исходным кодом или в группе навигатора проекта. Отдельно проверьте, не собираете ли вы конфигурацию, отличающуюся от той, которую проверяли перед отправкой.

Затем сравните файл в проекте с манифестом внутри полученного приложения. Apple публикует требования к расположению и содержимому privacy manifest; сверяйте с ними именно собранный продукт, а не только структуру репозитория. Документация Apple о расположении файлов манифеста помогает проверить, где ожидается файл в app bundle.

Как найти конкретный файл, на который жалуется App Store Connect?
Возьмите путь из сообщения об ошибке и откройте соответствующий архив в Xcode Organizer. Сопоставьте путь с вложенной структурой приложения, framework или другого компонента. Если путь не совпадает с файлом, который вы ожидали, не начинайте редактировать исходный манифест: сначала выясните, какой target или зависимость создали найденный объект.

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

В манифесте основного приложения проверьте заявленные категории отдельно. Для сведений о сборе данных Apple документирует соответствующую структуру в разделе описания использования данных в privacy manifests. Для API с обязательным указанием причины используйте отдельный список API и разрешённых причин. Не добавляйте причину «на всякий случай»: декларация должна соответствовать действительному использованию.

Swift Package и ресурс, отсутствующий в архиве

Путь внутри архива может указывать на код или ресурс Swift Package. В таком случае проверьте не только наличие PrivacyInfo.xcprivacy в исходной папке пакета, но и описание ресурсов в целевом объекте пакета. Само размещение файла в репозитории не гарантирует, что он включится в собранный продукт.

Apple описывает упаковку ресурсов Swift Package в документации по подключению ресурсов к пакету. Сверьте декларацию ресурса в Package.swift с target, который содержит код зависимости, и с тем, куда ресурс попадает после сборки. Для манифеста, который должен сопровождать пакет, следуйте актуальным указаниям Apple по добавлению privacy manifest; не переносите файл в другую папку только потому, что так удобнее визуально.

Почему исходный манифест Swift Package есть, а в архиве его нет?
Обычно нужно проверить, объявлен ли файл как ресурс именно для нужной цели пакета и попадает ли эта цель в текущую сборку. Затем сопоставьте декларацию с содержимым архива. Проверка только дерева исходников не доказывает, что Xcode включил ресурс в продукт.

При диагностике сохраните сведения о версии зависимости и способе её подключения. Если пакет обновлялся, убедитесь, что сборка использовала ожидаемую ревизию. Чистая пересборка может помочь отделить проблему устаревшего результата сборки от ошибки конфигурации, но сама по себе не исправит неверное описание ресурса.

Не копируйте манифест пакета в основной target автоматически. Это меняет место и владельца декларации, но не гарантирует, что пакетная версия начнёт корректно попадать в архив. Сначала установите, какой компонент должен поставлять файл, затем исправляйте конфигурацию этого компонента.

Третьесторонний SDK или неверное содержимое

Если путь ведёт внутрь framework или XCFramework, сначала определите имя компонента и его версию. Сопоставьте их с записью в менеджере зависимостей и с материалами поставщика SDK. Такой файл относится к поставляемой зависимости; дублирование его деклараций в манифесте приложения не исправляет содержимое SDK.

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

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

Если манифест присутствует, но остаётся недействительным, сверяйте ключи, типы значений и допустимые элементы с актуальной документацией. Раздел о сборе данных не заменяет декларации использования API, для которых требуется причина. И наоборот: запись об API не является заявлением о сборе данных. Apple перечисляет допустимые причины для required reason API в официальном справочнике; выбирайте значение только по фактическому назначению вызова.

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

Таблица помогает выбрать направление проверки, но не подменяет анализ сообщения Apple: окончательное решение зависит от файла и пути в конкретной сборке.

Xcode Archive и повторная проверка

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

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

Как проверить исправление перед повторной отправкой?
Создайте новый архив после изменения исходного компонента, найдите в нём путь из предыдущего уведомления и проверьте актуальное содержимое манифеста. После этого выполните проверку архива в Xcode и убедитесь, что отправляете именно проверенный артефакт.

Не исправляйте проблему прямым редактированием готового архива и не удаляйте файл из него как обходной путь. Содержимое подписанного приложения связано с целостностью кода. Если изменение архива действительно необходимо в рамках допустимого процесса, изучите требования Apple к подписи в документации по code signing. Обычно надёжнее внести исправление в исходный target или пакет, собрать заново и проверить новый архив.

Контрольный список приёмки

• [ ] Сохранён полный путь файла из сообщения App Store Connect.
• [ ] Определён владелец манифеста: приложение, Swift Package или SDK.
• [ ] Проверена версия зависимости, если путь ведёт внутрь стороннего компонента.
• [ ] Проверено наличие файла в архиве, а не только в исходном проекте.
• [ ] Ключи, типы значений и причины сверены с актуальными документами Apple.
• [ ] После исправления создан новый Xcode Archive.
• [ ] В Organizer проверен именно новый архив, выбранный для отправки.
• [ ] Перед отправкой повторно запущена проверка в Xcode.
• [ ] Команда сохранила путь ошибки, версию зависимости и результат повторной проверки.

Такой журнал помогает быстро отличить исправление исходного файла от ситуации, когда команда случайно проверила или отправила старый архив. Записывайте только то, что можно перепроверить: версию проекта и зависимости, путь манифеста, выбранный архив и результат валидации.

Выбор среды для повторяемой сборки

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

Если сборку выполняют разработчики на Windows или Linux, локальная разработка и финальная проверка на доступном Mac могут создать разрыв: зависимость обновлена в одном месте, архив создаётся в другом, а доказательства проверки остаются на разных машинах. В этом случае заранее определите, где будет формироваться архив, кто проверяет его содержимое и как команда сохраняет результат.

Если вы сравниваете собственное оборудование и удалённую среду, учитывайте не только время одной сборки, но и доступность Mac при выпуске, передачу секретов и сохранение архивов. Для выбора способа доступа можно изучить варианты удалённого Mac, а особенности работы с Xcode и средой — в документации OsxNode.

Удалённый Mac не исправит ошибочную декларацию и не гарантирует принятие приложения. Он решает другую задачу: даёт доступ к macOS для воспроизводимой сборки и проверки, когда у команды нет подходящего локального компьютера. В процессе зафиксируйте, какой исходный код собирался, какая версия SDK использовалась и какой архив прошёл проверку.

Практическое решение

При недействительном PrivacyInfo.xcprivacy не начинайте с массового редактирования манифестов. Путь из сообщения App Store Connect определяет первый шаг: проверьте владельца файла, затем его исходное описание и фактическое содержимое нового архива. Для Swift Package проверьте декларацию ресурса; для SDK — версию и материалы поставщика; для основного приложения — включение файла в собираемый target и соответствие данных официальным правилам.

Если у вас уже есть доступный Mac и стабильный процесс сборки, продолжайте на нём. Если же текущий вариант требует постоянно искать свободную машину, переносить проект между разными средами и перепроверять, какой архив отправляется, временная аренда Mac может быть практичнее покупки оборудования для нерегулярных релизов. Через удалённый Mac для работы с Xcode можно организовать отдельную среду для создания и проверки архивов. Выбирайте её только при реальной нехватке macOS; наличие Mac само по себе не заменяет проверку манифеста и повторную валидацию.