Adding a data point on a related variant of this failure. The signature and forum-documented workarounds map cleanly, but this pairing behaves differently in one respect that may be useful for the team working on FB22807635. Environment iPhone 15 Pro on iOS 26.5 (build 23F77) Apple Watch Series 5 on watchOS 10.6.1 (this hardware cannot go past watchOS 10.x) Paid Apple Developer Program membership, 1-year auto-managed provisioning Xcode 26.5 with iPhoneOS26.5 / WatchOS26.5 SDKs Dev-signed watch companion app that installed cleanly on 2026-07-08, stopped installing on 2026-07-15 with no local project change in between Error signature (identical to the thread) Live syslog capture from the moment the "This app could not be installed at this time" alert appeared on the iPhone: appconduitd -[ACXServerInstallOperation _onQueue_prepForTransferAndInstall]: Acquiring socket for com.example.myapp.watchkitapp (p = Y, ui = Y) appconduitd ACXIDSSocketManager: Starting socket setup for stream ID appconduitd Got delivery acknowledgement for socket setup message ID ; starting bringup for stream ID appconduitd IDSDeviceConnection Init connection socket -1 with options ... [~60 seconds elapse with no return-channel response from the watch] appconduitd _IDSDeviceConnection has timed out waiting for a socket. appconduitd Failed to create IDSDeviceConnection (error: Error Domain=com.apple.identityservices.error Code=20 "Socket open timed out") appconduitd -[ACXServerInstallOperation _onQueue_prepForTransferAndInstall]_block_invoke: 370: Failed to create socket appconduitd Failed to install app com.example.myapp.watchkitapp ACXErrorDomain Code=8 "Failed to create socket" (underlying: identityservices Code=20 Socket open timed out) The identityservicesd side shows the outbound setup completing normally on the control channel before the timeout. Setup message on com.apple.private.alloy.appconduit.v2, IPsecLink setup encrypted channel control message (type=6) dispatched with ports [61314:::1064], remoteGUID present, message written to NW connection with 237 bytes. Ack received from the watch on the setup message itself. Return socket bringup never occurs. Deterministic across every attempt Ten install attempts in the last two days. Every single one times out at the same ~60-second mark with the same signature. No intermittent behavior, no partial success, no variance based on network path (home Wi-Fi, work Wi-Fi, cellular tested and identical). Ruled out via direct test Bundle content: a blank Xcode 26.5 watchOS project (no HealthKit, no permissions, 3-key entitlements only, brand-new App IDs never seen by Apple) fails with the identical signature. Any specific App ID: renamed watch bundle to a fresh App ID that never existed on our team before, Apple auto-generated new App ID and profile, still fails identically. HealthKit / restricted entitlements: signed watch bundle with the HealthKit entitlement key removed entirely and re-installed. Still fails. Signing certificate identity: revoked our Apple Development cert on the portal, removed private key from Keychain, generated a fresh cert via Xcode. Still fails. Watch-side persistent state: full unpair, watch factory-reset to language selector, re-pair with backup restore. Fresh NRD pairing entry. Still fails. Phone-side state: multiple reboots, Reset Location & Privacy, Mac reboot, fresh CoreDevice lockdown pair. Still fails. Forum workarounds tested on this variant Workaround #1 (Bluetooth toggle on both devices): executed with sysdiagnose confirmation that the toggle forced a fresh identityservicesd TLS 1.3 handshake between devices (Client handshake started sequence visible). Install still fails identically after the fresh handshake. Rules out the specific IDS peer-transport state that reportedly clears this on the watchOS 26.5 pairing. Workaround #2 (direct xcrun devicectl device install app --device <WATCH_UUID>): returns CoreDeviceError 4000 with underlying NSPOSIXErrorDomain error 60 (operation timed out). CoreDevice's tunnel to the watch never establishes for devicectl operations in this environment, even though the watch is reachable via IDS and Bluetooth for every other purpose. Neither workaround unblocks watchOS 10.6.1 companion installs. Questions Does FB22807635 cover the iOS 26.5 → watchOS 10.6.1 pairing, or is our variant distinct enough to warrant a separate report referencing it? The forum thread body focuses on watchOS 26.5, and our failure mode differs in that both documented workarounds are ineffective for us. Any ETA on 26.5.1 or an interim mitigation? This blocks all dev-signed watch iteration for developers whose users are on Series 4/5/6 hardware that cannot update past watchOS 10.x. If additional diagnostic captures would help the team working on this, happy to provide. Sysdiagnose from the failing install window is preserved locally.