Post

Replies

Boosts

Views

Activity

Reply to Enterprise WatchOS App Won't Install on WatchOS 26.5
I'm seeing the same, as well as watch connectivity problems in general. Xcode has a hard time staying connected, and it seems like applicationContexts may have some issues transferring well. I'm really hoping this is sorted out in 26.5.1 soon. Claude's summary of us chasing this problem all day: The failure originates in appconduitd (Application Conduit Daemon), not the install pipeline itself. Specific cascade: 1. appconduitd calls ACXServerInstallOperation _onQueue_prepForTransferAndInstall 2. ACXIDSSocketManager tries handleIDSRelayConnectionResponseWithContext 3. Underlying call to identityservicesd reports legacy control channel connect ready ... socket error: 60 (Operation timed out) on peer at fe80::*%utun3 (link-local IPv6 over a Continuity utun interface) 4. Bubbles up as com.apple.identityservices.error Code=20 "Socket open timed out" 5. Returns to appconduitd as ACXErrorDomain Code=8 "Failed to create socket" 6. User sees: "The app could not be installed at this time." So the broken layer is IDS (Identity Services) peer transport over the Bluetooth-discovered link, not the install pipeline. That's a useful narrow target for Apple to focus on, vs. the broader "install is broken." Workarounds we empirically validated: 1. Toggle Bluetooth off then on on BOTH iPhone AND Apple Watch. Handoff toggle on iPhone alone is not sufficient. Watch restart alone is not sufficient. Both ends, both subsystems, forces a fresh IDS peer handshake. 2. Direct install via xcrun devicectl device install app --device <WATCH_UUID> path/to/watch.app — completely bypasses the broken Watch.app propagation, treating the watch as a paired companion device. Works for dev installs; doesn't help non-developer enterprise users who can't run devicectl. Related secondary symptom worth mentioning: even after the install eventually succeeds, updateApplicationContext from iPhone to Watch can silently fail to deliver for watch apps that ARE installed. Apple's framework dedupes by byte-equality against an iPhone-side "last set" cache that doesn't get invalidated when the broken IDS transport drops a delivery. The cache and the watch's real slot drift permanently out of sync; subsequent calls return no change and skip delivery. Workaround: stamp each dict with _sentAt = Date().timeIntervalSince1970 to defeat dedup. Same underlying broken transport, expressing in a different layer.
Topic: Business & Education SubTopic: General Tags:
Jun ’26
Reply to Enterprise WatchOS App Won't Install on WatchOS 26.5
I'm seeing the same, as well as watch connectivity problems in general. Xcode has a hard time staying connected, and it seems like applicationContexts may have some issues transferring well. I'm really hoping this is sorted out in 26.5.1 soon. Claude's summary of us chasing this problem all day: The failure originates in appconduitd (Application Conduit Daemon), not the install pipeline itself. Specific cascade: 1. appconduitd calls ACXServerInstallOperation _onQueue_prepForTransferAndInstall 2. ACXIDSSocketManager tries handleIDSRelayConnectionResponseWithContext 3. Underlying call to identityservicesd reports legacy control channel connect ready ... socket error: 60 (Operation timed out) on peer at fe80::*%utun3 (link-local IPv6 over a Continuity utun interface) 4. Bubbles up as com.apple.identityservices.error Code=20 "Socket open timed out" 5. Returns to appconduitd as ACXErrorDomain Code=8 "Failed to create socket" 6. User sees: "The app could not be installed at this time." So the broken layer is IDS (Identity Services) peer transport over the Bluetooth-discovered link, not the install pipeline. That's a useful narrow target for Apple to focus on, vs. the broader "install is broken." Workarounds we empirically validated: 1. Toggle Bluetooth off then on on BOTH iPhone AND Apple Watch. Handoff toggle on iPhone alone is not sufficient. Watch restart alone is not sufficient. Both ends, both subsystems, forces a fresh IDS peer handshake. 2. Direct install via xcrun devicectl device install app --device <WATCH_UUID> path/to/watch.app — completely bypasses the broken Watch.app propagation, treating the watch as a paired companion device. Works for dev installs; doesn't help non-developer enterprise users who can't run devicectl. Related secondary symptom worth mentioning: even after the install eventually succeeds, updateApplicationContext from iPhone to Watch can silently fail to deliver for watch apps that ARE installed. Apple's framework dedupes by byte-equality against an iPhone-side "last set" cache that doesn't get invalidated when the broken IDS transport drops a delivery. The cache and the watch's real slot drift permanently out of sync; subsequent calls return no change and skip delivery. Workaround: stamp each dict with _sentAt = Date().timeIntervalSince1970 to defeat dedup. Same underlying broken transport, expressing in a different layer.
Topic: Business & Education SubTopic: General Tags:
Replies
Boosts
Views
Activity
Jun ’26