We have an iPhone app with a companion watchOS app for factory alert monitoring.
What we want to achieve is:
each server event is an independent event, not just a latest-state update events should not be dropped in some scenarios, new events may arrive as frequently as once per minute the watch app state/UI should reflect the event almost in real time our target is roughly within 5 seconds the watch app is expected to be opened by the user when they want to confirm details, but we want the data to already be there even if the watch app was previously in the background notification mirroring is already sufficient for immediate user awareness; the question is about reliable background data/state delivery to the watch app
Our current architecture is:
The server sends APNs pushes to the iPhone app. We use both: alert pushes for user-visible notifications background pushes (content-available: 1, apns-push-type: background, apns-priority: 5) for background data delivery When the iPhone app receives the push, it relays data to the watch using WatchConnectivity. On the iPhone/watch side: we use sendMessage when reachable / foreground-like communication is possible we use transferUserInfo as the background / unreachable fallback The devices are paired and connected, and the apps are not force-quit.
In practice, the behavior is not stable enough for this requirement:
some background deliveries are delayed some relays to the watch are not timely the end-to-end behavior is not reliable enough for independent event delivery with near-real-time expectations
My understanding is that:
APNs background pushes are not guaranteed and may be throttled WatchConnectivity background delivery is opportunistic immediate WC messaging depends on reachability / active state
So the main question is not how to debug a single implementation issue, but whether our expectation is valid at all on Apple platforms.
Questions:
Is this architecture fundamentally unsuitable if the requirement is lossless, near-real-time event delivery from server -> iPhone -> watch, with a target of roughly within 5 seconds? Even if the implementation is correct, should we expect iPhone background push + WatchConnectivity relay to remain inherently non-deterministic for this kind of requirement, especially in scenarios where events may occur approximately once per minute? If notification mirroring is used only for user awareness, but the watch app still needs reliable background state/data delivery before the user opens it, is there any Apple-supported architecture for that? Would direct delivery to the watch app be the only realistic direction, or is this level of reliability/latency simply not a supported expectation for general-purpose apps?
We understand that background execution and delivery are managed opportunistically by the system. What I want to confirm is whether this requirement itself is outside the practical/supported envelope of APNs background push + WatchConnectivity relay.