Нельзя просто подключить iPhone к удалённому Mac для Xcode

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

Миф: удалённое управление переносит и устройство

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

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

Определите, где физически находится телефон, прежде чем что-либо настраивать

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

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

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

Рассматривайте обнаружение и транспорт как две разные проблемы

Xcode находит сопряжённые беспроводные устройства через Bonjour в локальной сети, а также может достучаться до устройства по известному адресу через Connect via IP Address. Это два механизма с двумя разными режимами отказа. Устройство, которое никогда не появляется в списке, и устройство, которое появляется, но отказывается подключаться, — не один и тот же симптом, хотя оба читаются как пропавший телефон.

Прежде чем что-то менять, поищите объявление: dns-sd -B _apple-mobdev2._tcp перечисляет службу, которую сопряжённый телефон публикует в локальном канале. Если ничего не появляется, обнаружение — сломанный слой, и остаётся только подключение по адресу. Если служба появляется, но Xcode всё равно не может подключиться, обнаружение работает, а отказывает транспорт или отношение доверия.

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

Проверьте, что Mac видит со своего места

Запускайте перечисление на Mac, а не на ноутбуке, потому что именно Mac — машина, которой нужно устройство. xcrun devicectl list devices печатает устройства, до которых Xcode может добраться, а system_profiler SPUSBDataType показывает, что физически подключено. Телефон, который есть во втором списке, но отсутствует в первом, подключён и не сопряжён, и это проблема доверия, а не сети.

xcrun devicectl list devices
system_profiler SPUSBDataType | grep -i iphone
xcrun devicectl device info DEVICE_UDID

Если устройство находится в другой подсети, убедитесь, что Mac может добраться до адреса, который публикует телефон, и помните, что адреса link-local IPv6 ограничены одним каналом и не маршрутизируются через туннель. Поэтому один только VPN редко делает удалённый телефон видимым: адрес, который объявляет устройство, имеет смысл только в его собственном сегменте.

Техническая заметка Apple TN3158 утверждает, что начиная с версии 15 Xcode общается с устройством по кабелю через сетевой интерфейс, построенный на link-local IPv6, поэтому локальная фильтрация может мешать даже физически подключённому телефону. Передайте такой случай владельцу политики фильтрации, а не отключайте её самостоятельно.

Докажите сборкой, а не значком устройства

Запись устройства в списке, зелёный индикатор на панели инструментов или успешный запрос сопряжения — это промежуточные наблюдения. Рабочий процесс доказан, когда Xcode устанавливает разрешённую сборку и отладчик подключается к процессу, работающему на устройстве.

Выполните всю последовательность с Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app устанавливает без IDE, что отделяет проблему интерфейса Xcode от проблемы пути к устройству. Затем запустите приложение и подключите к нему консоль. Если установка из командной строки работает, а IDE нет, оставшаяся неисправность — в схеме или в конфигурации подписи, а не в сети.

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