Удалённая сборка Unreal Engine 5.8 iOS: руководство по настройке Windows 2026 // Блог NOVAKVM

Удалённая сборка Unreal Engine 5.8 для iOS из Windows возможна через SSH, но для C++-компиляции, подписи, публикации и отладки в Xcode настоящий Mac остаётся обязательным. Для большинства команд достаточно сначала настроить один Primary Mac, а Secondary Remote Mac добавлять только тогда, когда отдельный узел действительно ускоряет подготовку локальной отладки.

Материал предназначен для трёх групп:

независимых разработчиков, которые ведут Unreal Engine-проект в Windows и должны выпускать установочный пакет для iPhone;
инженеров сборки и DevOps-специалистов, подключающих iOS к общему узлу или CI;
руководителей мобильных игровых команд, выбирающих между покупкой оборудования и периодической арендой Mac.

Последняя проверка: 31 августа 2026 года. Версии Unreal Engine, Xcode, SDK и требования App Store Connect необходимо повторно сверять перед каждым релизом по официальным материалам Epic Games и актуальным требованиям Apple Developer.

[ SECTION_01 ] Что остаётся в Windows, а что переносится на Mac

Windows может оставаться основной рабочей станцией: здесь удобно редактировать уровни, материалы и Blueprint, готовить ресурсы, запускать Cook и выполнять большую часть итераций игрового процесса. Однако финальная iOS-цепочка не сводится к удалённому рабочему столу.

На Mac выполняются операции, завязанные на Apple toolchain:

компиляция C++ через Xcode и соответствующий SDK;
формирование Xcode-проекта;
работа с сертификатом подписи и закрытым ключом;
применение Provisioning Profile;
создание архива или установочного пакета;
проверка установки и запуск на зарегистрированном устройстве;
автоматизация через командную строку и CI Runner.

Epic описывает Remote Mac Builds именно как механизм, при котором Windows-редактор Unreal Engine обращается к Mac для iOS-сборки. Это не то же самое, что подключиться к графическому сеансу через VNC: удалённый рабочий стол даёт интерфейс, а Remote Mac Builds передаёт проектные данные и запускает процедуру сборки на отдельной машине. Подробная граница между этими режимами приведена в документации Epic по удалённым сборкам Unreal Engine для iOS.

Три типа проекта — три разных уровня зависимости

Blueprint-only проект. Если в проекте нет собственного C++-кода и сторонних нативных модулей, Windows закрывает больше задач. Но для iOS-пакета, подписи и публикации всё равно требуется Mac с Apple-инструментами.

C++ проект. Компилятор, Xcode-проект, нативные плагины и библиотеки должны согласованно собираться на Mac. Ошибка в версии SDK или отсутствие закрытого ключа проявится уже после передачи задачи на удалённый узел.

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

Скрытые ограничения обычно появляются не в Windows, а на стыке систем:

Разные рабочие каталоги. Путь проекта в Windows не обязан существовать на Mac. Жёстко прописанные диски, обратные слеши и локальные плагины ломают перенос.
Секреты на общей машине. Сертификат без закрытого ключа бесполезен. При этом общий ключ в профиле команды создаёт риск несанкционированной подписи.
Непредсказуемый интерактивный вход. Пароль, подтверждение доступа к связке ключей или диалог Xcode могут остановить автоматическую задачу.
Недоступный iPhone. Mac в дата-центре обычно не видит устройство, которое находится рядом с разработчиком.
Конкурирующие сборки. Два задания в одном каталоге могут перезаписать промежуточные файлы, DerivedData или временные настройки подписи.
Неверный критерий успеха. Успешное SSH-подключение ещё не доказывает, что полученный пакет подписан и устанавливается на iPhone.

[ SECTION_02 ] Схема узлов и выбор конфигурации

Primary Mac — главный узел, на котором сначала проверяется весь цикл: Unreal Engine, Xcode, SDK, SSH, сертификаты и реальная сборка проекта. Он должен считаться эталоном, а не просто сервером для запуска команд.

Secondary Remote Mac использует подготовленные данные основного узла. Его задача — ускорить подготовку Xcode-окружения, синхронизацию кэшей или отдельную отладочную работу. Он не должен автоматически становиться заменой Primary Mac без отдельной проверки проекта, подписи и состояния кэша.

Компонент	Что выполняет	Когда необходим	Критерий готовности
Windows	Редактор, Blueprint, ресурсы, Cook, запуск удалённой задачи	Всегда для описанного сценария	Проект открывается, изменения фиксируются в системе контроля версий
Primary Mac	Remote Mac Builds, C++-компиляция, Xcode, подпись, архив	Базовая конфигурация	Сборка проходит без ручного диалога и создаёт проверяемый артефакт
Secondary Remote Mac	Подготовка отладочного окружения и работа с уже созданными данными	При необходимости параллельной подготовки	Данные синхронизированы, проект можно запустить без полной пересборки
Локальный вспомогательный Mac или устройство	Доступ к iPhone и физическая отладка	Если дата-центровый Mac не имеет USB-доступа	Устройство определяется, доверие и профиль подтверждены
CI-узел	Повторяемая автоматическая сборка	При стабильной ручной базовой линии	Чистая, повторная и восстановительная сборки оставляют журнал и артефакт

Редакционная оценка для типичной команды:

Один Primary Mac — высокая пригодность. Подходит для первого проекта, редких релизов и последовательных сборок.
Primary Mac плюс Secondary Remote Mac — средняя или высокая пригодность. Имеет смысл при параллельной подготовке и частой отладке.
Отдельный CI-узел — высокая пригодность только после ручной проверки. Он оправдан, когда сборки уже воспроизводимы и журналы достаточно подробны.
Только Windows или Linux — низкая пригодность для финальной iOS-доставки. Эти системы не заменяют Mac в операциях Xcode и Apple-подписи.

Primary Mac и Secondary Remote Mac: практическая граница

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

Secondary Mac получает пользу от уже созданных результатов:

кэша и промежуточных данных;
подготовленного Xcode-проекта;
согласованных настроек Unreal Engine;
проверенной схемы подписи.

Если Primary Mac ещё не собрал проект, Secondary Mac не решит проблему отсутствующего SDK, неверного Bundle ID или неработающего сертификата. В этом случае добавление второго узла лишь усложнит диагностику.

Важно. Secondary Remote Mac — это ускоритель подготовленных процессов, а не страховка от неверной первой конфигурации. Сначала фиксируется рабочая базовая линия на Primary Mac, затем переносится только проверенная схема.

[ SECTION_03 ] Первый сценарий: подготовка версии и рабочего Mac

Перед настройкой SSH необходимо составить короткую матрицу совместимости. В ней фиксируются версия Unreal Engine 5.8, версия Xcode, целевой SDK, архитектура сборки, минимальная версия iOS и модель тестового устройства. Конкретные значения нельзя брать из старой статьи: Epic может изменить требования в документации или примечаниях к выпуску.

Ориентиром служат официальные требования Epic для iOS, iPadOS и tvOS и примечания к выпуску Unreal Engine 5.8. Xcode 26 следует рассматривать как часть проверяемой версии сборочного окружения, а не как автоматически совместимый компонент: окончательное решение принимается только после сверки текущих страниц Epic и Apple.

Пошаговая подготовка

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

UNREAL_VERSION=<UE_5.8_VERSION>;
XCODE_VERSION=<XCODE_VERSION>;
IOS_SDK=<IOS_SDK_VERSION>;
BUNDLE_ID=<BUNDLE_ID>;
SIGNING_TEAM=<TEAM_ID>;
BUILD_CONFIGURATION=<Development_OR_Test_OR_Release>.

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

Второй шаг — подготовить отдельную учётную запись Mac.
Используется <BUILD_USER>, а не личная учётная запись разработчика. Для неё задаются минимальные права, отдельный домашний каталог и доступ только к нужному рабочему каталогу. Это снижает риск смешать пользовательские настройки, связку ключей и временные файлы.

Третий шаг — включить SSH на Mac.
В системных настройках активируется удалённый вход для <BUILD_USER>. Затем на Windows создаётся отдельная пара ключей:

ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\ue58_build

Публичный ключ переносится в ~/.ssh/authorized_keys пользователя <BUILD_USER>. Имя хоста и путь не следует угадывать: применяются значения <PRIMARY_MAC_HOST> и <MAC_PROJECT_PATH>.

Четвёртый шаг — проверить неинтерактивный вход.

ssh -i $env:USERPROFILE\.ssh\ue58_build `
  -o BatchMode=yes `
  <BUILD_USER>@<PRIMARY_MAC_HOST> `
  "xcodebuild -version && uname -m"

Команда должна завершиться без запроса пароля. Вывод сохраняется в журнале как подтверждение, что Windows видит Mac, ключ подходит, а командная оболочка доступна.

Пятый шаг — выполнить локальную проверку на Mac.
На Primary Mac вручную открывается проект или подготовленный Installed Build, принимаются необходимые условия Xcode, проверяется команда подписи и запускается пробная iOS-сборка. Документация Epic по Installed Build полезна, если команда не хочет передавать на удалённый узел полный исходный набор движка.

Шестой шаг — настроить Remote Mac Builds в Unreal Engine.
В Windows указываются <PRIMARY_MAC_HOST>, <BUILD_USER>, путь к ключу и путь проекта на Mac. Путь должен быть Unix-совместимым. После сохранения выполняется тестовое подключение, а затем запускается задача, которая действительно создаёт удалённый промежуточный результат. Одного сообщения «SSH работает» недостаточно.

Седьмой шаг — проверить повторяемость.
Сначала собирается проект после очистки рабочего каталога. Затем запускается повторная сборка без изменения исходников. После этого Mac перезапускается, SSH-сеанс создаётся заново, и задача повторяется. Если результат меняется без изменения кода, причина обычно находится в кэше, окружении, профиле подписи или конфликтующем каталоге.

[ SECTION_04 ] C++ и подпись: где проходит граница доставки

В Blueprint-only проекте часть ошибок можно обнаружить раньше. В C++ проекте Mac становится обязательной частью компиляции: исходники, нативные плагины и настройки Xcode должны пройти один и тот же путь до создания пакета.

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

Сценарий	Что требуется на Mac	Что проверяется	Почему нельзя смешивать
Development	Сертификат разработки, закрытый ключ, профиль и зарегистрированное устройство	Установка и запуск отладочного пакета	Права тестирования не равны правам публикации
Тестовый пакет	Профиль для выбранного способа распространения и корректный Bundle ID	Установка на разрешённом устройстве или передача тестировщикам	Устройство и профиль должны соответствовать друг другу
App Store	Сертификат распространения, профиль, архив и проверка Apple	Архив, подпись, загрузка и результат проверки	Успешная локальная сборка не гарантирует приём в App Store

Сертификат и закрытый ключ должны находиться в связке ключей именно того пользователя, от имени которого запускается сборка. Provisioning Profile должен соответствовать <BUNDLE_ID>, команде <TEAM_ID> и целевому способу распространения.

Apple отдельно меняет требования к SDK для отправки приложений в App Store. В частности, требование, вступающее в силу 28 апреля 2026 года, необходимо сверять непосредственно на странице предстоящих требований App Store Connect. Это дата политики публикации, а не доказательство того, что любой проект на Unreal Engine 5.8 автоматически соответствует ей.

Что считать успешной сборкой

Приёмочный пакет должен содержать четыре вида доказательств:

журнал удалённой компиляции без ручного ввода;
вывод о совпадении идентификатора подписи и Bundle ID;
архив или установочный пакет с контрольной суммой;
результат установки на доступное устройство либо результат проверки архива Apple.

Секреты заменяются в логах на <CERTIFICATE_NAME>, <TEAM_ID>, <BUNDLE_ID> и <PROFILE_NAME>. Не следует сохранять в CI полный экспорт связки ключей без шифрования и ограничения доступа.

[ SECTION_05 ] Вопросы настройки Remote Mac Builds и отладки iPhone

Как настроить SSH-ключ для Remote Mac Builds

Ключ создаётся на Windows, публичная часть устанавливается для <BUILD_USER> на Primary Mac, а приватная часть остаётся только на Windows или в защищённом хранилище CI. Для проверки применяются BatchMode=yes, явный путь к ключу и команда, которая возвращает версию Xcode.

Если интерактивное подключение проходит, а удалённая сборка останавливается, проверяются три слоя:

Unreal Engine использует тот же ключ и пользователя;
рабочий каталог доступен этому пользователю;
Xcode и связка ключей не требуют графического подтверждения.

Пароль в командной строке не используется. При отзыве ключа удаляется конкретная строка из authorized_keys, после чего создаётся новая пара.

Как отлаживать Unreal-проект на iPhone после удалённой сборки

Дата-центровый Mac обычно не имеет прямого USB-доступа к iPhone разработчика. Поэтому возможны три рабочих режима:

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

Путь Run Without Building пригоден, когда Xcode-проект, кэш, бинарные данные и подпись совместимы с уже подготовленной сборкой. Если данные изменились или проект сгенерирован заново, такой запуск не заменяет полноценную сборку.

Опытный ориентир. Удалённая сборка решает задачу Apple-компиляции и подписи, но не превращает удалённый Mac в беспроводной USB-порт. План отладки должен заранее указывать, где находится iPhone и кто контролирует установку.

[ SECTION_06 ] Общий узел и CI: переносить только проверенную схему

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

Перед использованием общего узла проверяются:

отдельная учётная запись для каждой команды или изолированный рабочий процесс;
уникальный <WORKSPACE_ID> для каждой задачи;
отсутствие пересечения временных каталогов;
последовательный доступ к связке ключей;
блокировка или очередь при конкурирующих сборках;
сохранение полного лога и краткого лога для разработчика;
удаление временных профилей после завершения задачи.

Минимальный набор CI-проверок выглядит так:

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

Epic рекомендует учитывать особенности мобильной разработки, включая настройки проекта, упаковку и ограничения целевых платформ; для игровой команды полезно сопоставить цепочку с руководством Epic по созданию мобильных игр. Время сборки и процент успешных запусков нельзя объявлять универсальными: они зависят от проекта, кэша, диска, сети и числа нативных модулей. Такие значения допустимы только как отдельный тест конкретного узла.

[ SECTION_07 ] Решение по конфигурации: условия вместо догадок

Если проект Blueprint-only, публикация пока не планируется, а сборки выполняются вручную, выбирается один Primary Mac.
Если проект содержит C++, сразу проверяются компиляция на Mac, нативные плагины и связка ключей; при сбое хотя бы одного пункта выпуск откладывается до исправления базовой конфигурации.
Если требуется App Store, выбирается Primary Mac с отдельной процедурой подписи и архивной проверки; Development-профиль не считается заменой релизному.
Если нужен iPhone для каждого цикла отладки, добавляется локальный вспомогательный Mac или контролируемый доступ к устройству; второй удалённый Mac сам по себе проблему USB не решает.
Если параллельные задачи конфликтуют за каталог или связку ключей, сначала вводится изоляция рабочих пространств, а не покупается дополнительный узел.
Если ручная чистая, повторная и восстановительная сборки уже успешны, можно переносить процесс в CI.
Если Primary Mac ещё не прошёл полный цикл, Secondary Remote Mac не добавляется: сначала исправляется эталонная машина.
Если сборки нужны только на время миграции или проверки UE 5.8, разумнее начать с периодического доступа к реальному Mac, а долгосрочный CI-узел выбирать после измерений.

Для команды, которой нужен только временный тестовый контур, аренда Mac для удалённой разработки через NOVAKVM позволяет сначала проверить реальный проект, SSH, подпись и возврат артефакта без немедленной покупки оборудования. После этого можно сравнить результат с постоянным Mac mini и решить, нужен ли отдельный узел для CI.

[ SECTION_08 ] Что должно войти в акт приёмки

Финальная приёмка должна начинаться не с доступности SSH, а с реального коммита Unreal Engine:

Windows запускает сборку указанного коммита.
Primary Mac получает исходные данные и выполняет Unreal Engine 5.8 iOS Remote Mac Build.
Mac компилирует C++ и формирует Xcode-артефакт.
Подпись соответствует <BUNDLE_ID> и <TEAM_ID>.
Архив или установочный пакет возвращается в защищённое хранилище.
Пакет устанавливается на доступное устройство либо проходит архивную проверку.
В журнале остаются версии, идентификаторы, контрольная сумма и причина возможного отказа.

Документируются также путь восстановления, владелец сертификата, срок действия профиля, способ ротации ключа и процедура повторного подключения после перезапуска. Точные версии Xcode 26, SDK и ограничения устройств повторно сверяются перед релизом, поскольку официальные документы Epic и Apple могут обновляться независимо друг от друга.

Windows остаётся удобной основной средой для Unreal Engine, но у неё есть три реальные слабые стороны в этом сценарии: отсутствует нативный Apple toolchain, финальная подпись зависит от отдельного Mac, а физическая отладка iPhone требует дополнительного оборудования или ручной передачи пакета. Виртуализация и случайный общий CI-узел добавляют ещё больше переменных — от доступа к ключам до несовпадения SDK.

Поэтому для первого UE 5.8 проекта разумнее арендовать через NOVAKVM настоящий Mac на нужный период, провести чистую, повторную и восстановительную сборку, а затем принять решение о постоянном CI. Такой порядок оставляет команде возможность отказаться от аренды, перейти на собственный Mac или расширить схему до Primary Mac и Secondary Remote Mac только после подтверждения реальной потребности. Доступные варианты удалённого Mac для тестовой цепочки стоит оценивать уже после проверки совместимости проекта, подписи и способа отладки.

Удалённая сборка Unreal Engine 5.8 iOS: руководство по настройке Windows 2026