Unity 6.3 LTS iOS-сборка: как упаковать в Windows в 2026 году?

Проект в Windows уже экспортирован в Xcode, но IPA для TestFlight получить не удаётся.

Быстрое решение: Windows оставьте для разработки и экспорта Xcode-проекта, а Archive, кодовую подпись и загрузку в App Store Connect выполняйте на macOS. При редких релизах передавайте готовый проект на временный удалённый Mac; при частых публикациях синхронизируйте исходники с постоянным удалённым Mac и автоматизируйте экспорт Unity и сборку Xcode.

Последняя проверка: 29 августа 2026 года. Данные сверены с документацией Unity по выпуску Unity 6, процессу iOS-сборки и системным требованиям, а также с руководствами Apple по распространению приложений и загрузке сборок.

Эта статья предназначена:

• независимым разработчикам, которые ведут основную работу в Windows и впервые готовят Unity-игру или приложение для iOS;
• небольшим командам, которым нужно регулярно получать сборки для TestFlight без покупки и обслуживания отдельного Mac;
• владельцам Unity-проектов, переводящим ручной экспорт в повторяемый удалённый процесс.

Главная ошибка в таком проекте — считать экспорт Xcode-проекта готовой iOS-сборкой. Unity описывает процесс как последовательность из генерации проекта и последующей сборки приложения средствами Xcode. Официальная схема Unity для iOS-сборки прямо разделяет эти этапы.

Windows может использоваться для разработки, импорта ассетов, запуска тестов Unity и генерации Xcode-проекта. Однако финальный этап требует macOS, поскольку именно Xcode компилирует нативную часть, применяет подпись и формирует архив для распространения. Описание Unity о способе построения iOS-приложений следует воспринимать как ограничение архитектуры процесса, а не как недостаток конкретного проекта.

До передачи проекта на удалённую машину подготовьте:

• действующую учётную запись Apple Developer с правами, достаточными для создания или использования идентификатора приложения, сертификатов и профилей;
• точный Bundle ID, Team ID и название записи приложения в App Store Connect;
• версионирование исходников, включая Packages/manifest.json, Packages/packages-lock.json, настройки проекта и нативные плагины;
• безопасный способ передачи сертификата с закрытым ключом и профиля подписи;
• список переменных, которые не должны попадать в репозиторий: пароли, токены, API Key и содержимое закрытых ключей.

Регистрация учётной записи здесь не рассматривается: задача этого руководства — не оформление доступа, а контроль границ между Windows, Unity, Xcode и App Store Connect.

Unity 6.3 LTS — обозначение долгосрочно поддерживаемой ветки, а выпуск редактора 6000.3.0f1 опубликован на официальной странице релиза Unity. Это не означает, что любая комбинация редактора, модулей и Xcode будет взаимозаменяемой: требования к поддерживаемой версии Xcode, SDK и плагинам могут меняться вместе с обновлениями Apple и Unity.

Сначала зафиксируйте рабочую пару, а не обновляйте всё до последней доступной версии:

• версию Unity 6.3 LTS и точный номер редактора;
• наличие модуля iOS Build Support в редакторе Windows;
• архитектуру удалённого Mac и установленную версию Xcode;
• путь, который используется командами xcodebuild и xcrun;
• целевую конфигурацию Release, имя схемы и папку для архива;
• состояние пакетов Unity и версии CocoaPods, если проект использует pods;
• версии нативных SDK, плагинов и скриптов PostProcessBuild.

Примечания к выпуску Unity 6000.3.0f1 помогают проверить саму ветку Unity 6.3, а системные требования Unity 6 — не перепутать требования редактора Windows с требованиями финального macOS-этапа.

Затем создайте минимальный пустой проект и проверьте цепочку отдельно от коммерческой игры. В Windows экспортируйте простой Xcode-проект. На удалённом Mac откройте его, выберите схему, выполните команду проверки Xcode и только затем переходите к исходному проекту. Такой тест не доказывает работоспособность всех плагинов, но быстро отделяет проблему доступа к Xcode от проблемы конкретной игры.

xcode-select --print-path
xcodebuild -version
xcodebuild -list -project "/ПУТЬ/К/EXPORTED_PROJECT/Unity-iPhone.xcodeproj"

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

Выбор способа зависит не от удобства, а от частоты сборок и состава проекта.

Вариант A: экспорт в Windows и передача Xcode-проекта

Этот путь подходит, когда релиз выполняется время от времени и проект не меняется между экспортом и подписью. В Unity выберите платформу iOS, дождитесь завершения импорта и создайте новый каталог Xcode-проекта. Передавайте не отдельный файл .xcodeproj, а весь каталог результата.

Проверьте, что в архив попали:

• каталог проекта Unity и связанные библиотеки;
• сгенерированные исходники и данные IL2CPP;
• фреймворки, статические библиотеки и встроенные пакеты;
• файлы конфигурации, созданные скриптами постобработки;
• ресурсы нативных плагинов;
• символы и настройки, необходимые для диагностики сбоя.

После копирования на удалённый Mac не редактируйте одну и ту же сгенерированную настройку параллельно в Windows и Xcode. При следующем экспорте Unity может перезаписать ручное изменение. Если исправление действительно нужно, закрепите его в настройках Unity или в PostProcessBuild, а не только в открытом проекте Xcode.

Вариант B: исходники на удалённом Mac

При частых публикациях лучше передавать исходники через систему контроля версий, а не пересылать каждый сгенерированный каталог. На удалённом Mac устанавливаются совместимые Unity Editor и iOS Build Support, после чего экспорт запускается в командной строке или через заранее проверенный скрипт.

Пример вызова должен содержать явные заполнители:

"/ПУТЬ/К/UNITY" \
  -batchmode \
  -quit \
  -projectPath "/ПУТЬ/К/UNITY_PROJECT" \
  -executeMethod <ИМЯ_КЛАССА>.<ИМЯ_МЕТОДА> \
  -buildTarget iOS \
  -logFile "/ПУТЬ/К/LOGS/unity-export.log"

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

Полный Unity Editor на удалённом Mac нужен, если именно эта машина должна заново экспортировать проект из исходников. Для пути с уже созданным Xcode-проектом полный редактор обычно не является обязательным этапом: Mac должен иметь совместимый Xcode, проектные зависимости и средства подписи. Но это не отменяет необходимости проверить нативные плагины и скрипты, которые могли выполняться только во время экспорта.

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

1. Откройте проект или workspace на удалённом Mac.
2. Убедитесь, что выбрана нужная схема и конфигурация.
3. Проверьте Team, Bundle ID и минимальную версию iOS.
4. Выполните сборку без распространения и сохраните полный лог.
5. Исправьте ошибки CocoaPods, нативных библиотек и PostProcessBuild.
6. Только после успешной компиляции настройте подпись и создайте Archive.

Apple в руководстве по подготовке приложения к распространению рассматривает идентификатор приложения, команду разработчика, подпись и настройки распространения как отдельные элементы подготовки. Поэтому ошибка в Bundle ID не должна маскироваться заменой сертификата, а конфликт entitlement — повторным экспортом Unity.

Проверьте следующие поля:

• PRODUCT_BUNDLE_IDENTIFIER совпадает с зарегистрированным идентификатором;
• выбран правильный Team;
• entitlements соответствуют реально включённым возможностям;
• provisioning profile предназначен для этого приложения и типа распространения;
• сертификат содержит закрытый ключ и доступен процессу Xcode;
• нативные плагины не подключают несовместимые фреймворки;
• CocoaPods устанавливаются из зафиксированного состояния зависимостей.

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

Сохраните название схемы, параметры экспорта, commit исходников и лог. Это не бюрократия: без этих данных повторная сборка после изменения плагина превращается в ручное угадывание.

После создания Archive не называйте проект опубликованным автоматически. Здесь есть как минимум четыре независимых результата:

1. Unity успешно экспортировал Xcode-проект.
2. Xcode успешно собрал и подписал Archive.
3. Archive успешно прошёл проверку и был передан в App Store Connect.
4. App Store Connect завершил обработку загруженной сборки.

Для передачи используйте Organizer в Xcode или предусмотренный Apple инструмент загрузки. Инструкция Apple по распространению тестовых и релизных сборок описывает этапы проверки и загрузки, а справка по загрузке сборок в App Store Connect помогает сверить допустимый способ передачи.

До запуска загрузки проверьте:

• запись приложения уже создана в App Store Connect;
• Bundle ID связан с правильной записью;
• версия и build number увеличены по правилам проекта;
• выбран нужный тип распространения;
• команда и сертификат относятся к одной Apple Developer-команде.

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

После первого успешного TestFlight-сценария разделите pipeline на независимые стадии:

• экспорт Unity;
• установка или восстановление зависимостей;
• компиляция Xcode;
• Archive;
• подпись и экспорт распространяемого пакета;
• загрузка;
• проверка статуса обработки.

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

Проведите три имитации восстановления:

• изменение исходного скрипта или сцены;
• обновление нативного плагина;
• недоступность сертификата или API Key.

В первом случае должна повториться генерация проекта. Во втором — зависимость должна быть установлена явно и зафиксирована. В третьем — процесс должен завершиться контролируемой ошибкой без вывода секрета в лог.

Для постоянной среды документируйте, где находятся исходники, какой Unity Editor запускается, какой путь выбран через xcode-select, как очищаются Derived Data и где сохраняются архивы. Материалы Unity по iOS Build Automation следует сверять при изменении версии редактора, потому что старые предположения о поддержке Xcode нельзя считать постоянным правилом.

Чек-лист перед первым реальным релизом

• [ ] Unity 6.3 LTS и номер редактора записаны.
• [ ] iOS Build Support проверен в нужной установке Unity.
• [ ] Версия Xcode на удалённом Mac зафиксирована и проверена по актуальным требованиям.
• [ ] Экспорт пустого проекта проходит до этапа Xcode.
• [ ] Передан весь каталог Xcode-проекта, а не только файл проекта.
• [ ] Bundle ID, Team ID и запись App Store Connect совпадают.
• [ ] Сертификат импортирован вместе с закрытым ключом.
• [ ] Entitlements и provisioning profile проверены.
• [ ] CocoaPods и нативные плагины воспроизводимо устанавливаются.
• [ ] Archive создаётся без ручного исправления сгенерированных файлов.
• [ ] Логи Unity, Xcode и загрузчика сохраняются отдельно.
• [ ] Ошибка обработки в App Store Connect проверяется по статусу, а не повторной случайной сборкой.

Если публикация происходит редко, рационально арендовать удалённый Mac только на период экспорта, Archive и загрузки. Сначала завершите работу в Windows, затем передайте чистый Xcode-проект и оплатите среду на срок, достаточный для проверки всей цепочки. Такой вариант не требует держать отдельную машину включённой между релизами.

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

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

Windows остаётся удобным местом для Unity-разработки, однако он не закрывает финальную часть iOS-релиза. По сравнению с постоянным локальным Mac ручной экспорт из Windows добавляет передачу больших каталогов, риск потерять нативные библиотеки и зависимость от разовых исправлений в Xcode; отдельный купленный Mac, в свою очередь, требует первоначальных затрат, обновлений и самостоятельного обслуживания. Поэтому для редкого выпуска разумнее сначала проверить реальный проект на временном удалённом Mac, а для регулярного TestFlight выбрать постоянную среду JEXCLOUD и постепенно превратить экспорт, Archive и загрузку в восстанавливаемый процесс. Начните с одного полного цикла — от Unity-экспорта до обработанной сборки в App Store Connect — и только после этого определяйте срок аренды.