Vi ne povas simple ŝtopi iPhone en malproksiman Mac por Xcode

La kutima supozo estas, ke sesio de malproksima labortablo movas la tutan evoluigan aranĝon al via tekkomputilo. Ĝi movas la ekranon, la klavaron kaj la muson, kaj nenion alian. La iPhone devas atingi la Mac, kiu rulas Xcode, kaj tio estas aparta konekto kun propraj postuloj pri fido, transporto kaj permesoj. Ĉio sube sekvas el tiu divido, kaj ĝuste tie plej multaj malsukcesaj agordoj perdas posttagmezon.

La mito: malproksima regado movas ankaŭ la aparaton

Programaro por malproksima labortablo plusendas ekranon kaj enigan fluon, kaj ĉe bona konekto ĝi sentiĝas kvazaŭ la Mac sidus antaŭ vi. Kion ĝi ne plusendas, estas USB, kaj ĝi ankaŭ ne metas la telefonon en la reton de la Mac. La sesio finiĝas ĉe la labortablo de la Mac, kie Xcode poste devas trovi aparaton laŭ siaj propraj reguloj. Supozi, ke la telefono vojaĝas kun la rastrumeroj, estas la plej ofta eraro en tiu ĉi aranĝo.

La du konektoj estas sendependaj, kaj unu povas esti perfekta dum la alia tute ne ekzistas. Ripari la labortablan sesion diras al vi nenion pri la vojo al la aparato.

Decidu, kie la telefono fizike estas, antaŭ ol vi agordos ion ajn

Se la telefono restas apud la Mac, faru tie la kutiman lokan agordon: fidu la komputilon, ebligu la ellaboristan reĝimon sur la aparato, kaj konfirmu, ke Xcode konstruas kaj rulas al ĝi dum vi sidas antaŭ la maŝino. Tiam malproksima labortablo regas laborfluon, kiu jam funkcias. Tio estas la plej malmultekosta aranĝo kaj tiu, kiun indas preferi kiam ajn la aparataro permesas.

Se la telefono vojaĝas kun vi kaj la Mac restas en la oficejo, la Mac bezonas subtenatan vojon al tiu aparato. VPN provizas retan itineron inter la du finoj kaj provizas nenion alian: parigo, ellaborista reĝimo, subskriba identeco kaj aparata registrado restas apartaj postuloj. Traktu la tunelon kiel unu tavolon en stako, ne kiel la konekton mem.

Notu, en kiu el la du aranĝoj vi troviĝas. Ĉiu posta kontrolo dependas de tio, kaj miksado de ili produktas korektojn, kiuj ne povas funkcii.

Traktu trovon kaj transporton kiel du malsamajn problemojn

Xcode trovas parigitajn sendratajn aparatojn per Bonjour en la loka reto, kaj ĝi ankaŭ povas atingi aparaton ĉe konata adreso per Connect via IP Address. Temas pri du mekanismoj kun du malsamaj fiaskmanieroj. Aparato, kiu neniam aperas en la listo, kaj aparato, kiu aperas sed rifuzas konektiĝi, ne estas la sama simptomo, kvankam ambaŭ legeblas kiel mankanta telefono.

Esploru la anoncon antaŭ ol ŝanĝi ion ajn: dns-sd -B _apple-mobdev2._tcp listigas la servon, kiun parigita telefono publikigas sur la loka ligilo. Se nenio aperas, trovo estas la rompita tavolo kaj adresbazita konekto estas la sola restanta vojo. Se la servo aperas sed Xcode ankoraŭ ne povas konektiĝi, trovo funkcias kaj malsukcesas la transporto aŭ la fida rilato.

La helpo de Apple pri sendrataj aparatoj kovras kaj la postulon de sama reto kaj la adresan laborfluon, do legu ĝin kontraŭ viaj instalitaj versioj anstataŭ sekvi menuvojon memoratan el pli malnova eldono. Menuetikedo moviĝas inter eldonoj de Xcode eĉ kiam la mekanismo sub ili ne ŝanĝiĝas.

Kontrolu, kion la Mac povas vidi de sia loko

Rulu la enumeracion sur la Mac, ne sur via tekkomputilo, ĉar la Mac estas la maŝino, kiu bezonas la aparaton. xcrun devicectl list devices presas la aparatojn, kiujn Xcode povas atingi, kaj system_profiler SPUSBDataType montras, kio estas fizike konektita. Telefono, kiu aperas en la dua listo sed ne en la unua, estas konektita kaj ne parigita, kio estas fida problemo anstataŭ reta problemo.

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

Se la aparato troviĝas en alia subreto, konfirmu, ke la Mac povas atingi la adreson, kiun la telefono publikigas, kaj memoru, ke IPv6-adresoj lokaj por ligilo estas limigitaj al unu ligilo kaj ne estas enruteblaj tra tunelo. Tial VPN sola malofte igas malproksiman telefonon aperi: la adreso, kiun la aparato anoncas, havas sencon nur en sia propra segmento.

La teknika noto TN3158 de Apple asertas, ke ekde versio 15 Xcode parolas kun kabligita aparato tra retinterfaco konstruita sur ligilloka IPv6, do loka filtrado povas ĝeni eĉ telefonon, kiu estas fizike ŝtopita. Eskalacu tiun kazon al tiu, kiu posedas la filtradan politikon, anstataŭ mem malŝalti ĝin.

Pruvu ĝin per konstruo, ne per aparata ikono

Aparata ero en listo, verda indikilo en la ilobreto aŭ sukcesa pariga invito estas mezaj observoj. La laborfluo estas pruvita, kiam Xcode instalas permesitan konstruon kaj la sencimigilo alkroĉiĝas al proceso rulanta sur la aparato.

Rulu la plenan sekvencon el la Mac. xcrun devicectl device install app --device DEVICE_UDID build/MyApp.app instalas sen la IDE, kio apartigas problemon de la Xcode-interfaco disde problemo de la aparata vojo. Poste lanĉu la aplikaĵon kaj alkroĉu konzolon al ĝi. Se la instalado el la komandlinio funkcias kaj la IDE ne, la restanta misfunkcio estas en la skemo aŭ en la subskriba agordo, ne en la reto.

Tenu la aranĝon mallarĝa: unu rajtigita ellaboristo, unu registrita Mac, unu aparato, kaj aliro, kiu finiĝas kiam la sesio finiĝas. Revoku legitimilojn kiam la aranĝo ĉesas. Se la telefono simple povas resti apud la Mac, elektu tion, ĉar la plej simpla subtenata vojo estas tiu kun la plej malmultaj tavoloj restantaj por sencimigi.