Обичайното допускане е, че сесията на отдалечен работен плот премества цялата среда за разработка на вашия лаптоп. Тя премества екрана, клавиатурата и мишката и нищо друго. 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 може да достигне адреса, който телефонът публикува, и помнете, че IPv6 адресите, локални за връзката, са ограничени до една връзка и не се маршрутизират през тунел. Ето защо само VPN рядко прави отдалечен телефон видим: адресът, който устройството обявява, има смисъл само в собствения му сегмент.

Техническата бележка на Apple TN3158 посочва, че от версия 15 нататък Xcode говори с кабелно устройство през мрежов интерфейс, изграден върху локален за връзката IPv6, така че локалната филтрация може да пречи дори на телефон, който е физически включен. Ескалирайте този случай към собственика на политиката за филтриране, вместо да я изключвате сами.

Докажете го с компилация, а не с икона на устройство

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

Изпълнете цялата последователност от Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app инсталира без IDE, което отделя проблем с интерфейса на Xcode от проблем с пътя до устройството. След това стартирайте приложението и прикачете конзола към него. Ако инсталирането от командния ред работи, а IDE не, останалата неизправност е в схемата или в конфигурацията за подписване, а не в мрежата.

Дръжте подредбата тясна: един упълномощен разработчик, един регистриран Mac, едно устройство и достъп, който приключва с края на сесията. Отнемайте идентификационните данни, когато подредбата спре. Ако телефонът може просто да остане до Mac, изберете това, защото най-простият поддържан път е този с най-малко останали слоеве за отстраняване на грешки.

Подобни статии