Не можна просто підключити iPhone до віддаленого Mac для Xcode
Віддалений робочий стіл показує вам Xcode, а не iPhone на вашому столі. З'єднайте пристрій із Mac, який збирає проєкт, а виявлення розглядайте окремо від транспорту.
Звичайне припущення полягає в тому, що сеанс віддаленого робочого стола переносить усе середовище розробки на ваш ноутбук. Він переносить екран, клавіатуру та мишу, і більше нічого. 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, виберіть це, бо найпростіший підтримуваний шлях має найменше шарів для налагодження.