Data point from July 2026: this appears to work now - at least on current OS versions. Setup: iPhone companion (iOS 26.5) + SwiftUI-lifecycle watchOS app (watchOS 26.5) with WidgetKit accessory complications (no ClockKit) transferCurrentComplicationUserInfo() with a small dictionary payload (~6 keys), complication active on the watch face (isComplicationEnabled == true; the transfer budget was actually consumed: remainingComplicationUserInfoTransfers went 50 → 49 → 48 → 47) Both sides instrumented with file logging; every payload carries a monotonically increasing version, and we redundantly send the same update via updateApplicationContext as a fallback - so I can attribute exactly which channel applied each change Results - 3 consecutive sends while the watch was NOT reachable (isReachable == false on the phone at send time) and the watch app was backgrounded: sent 23:10:42.5 → didReceiveUserInfo on the watch at 23:10:57.6 (15.1 s). Ambiguous: the user happened to foreground the watch app ~150 ms before delivery. sent 23:11:15.5 → received 23:11:17.8 (2.3 s). Ambiguous for the same reason. sent 23:11:27.2 → received 23:12:05.5 (38.3 s). UNAMBIGUOUS: the watch app had been in the background for 45 s and was not foregrounded until 17 s AFTER the delivery. The delivery arrived together with a WC connectivity background task, our WidgetCenter.shared.reloadTimelines(ofKind:) ran from that background wake, and the complication re-rendered without any user interaction. In all three cases the complication transfer beat my updateApplicationContext fallback by 0.4–1.5 s (the fallback then arrived as an exact duplicate, identified via the payload version). For context: I had removed this API from my app after observing the broken behavior described in this thread on earlier OS versions. Based on the measurements above I am re-adopting it. Might be worth re-testing on your side with current OS releases - the fix does not seem to be documented anywhere.