AutoApp has a “needs-input” alert — the hub is waiting for a decision and needs to reach me now. The Apple Watch felt like the obvious surface. It’s always on my wrist, it can tap me, and it works even when my phone is face-down on a charger across the room.
The obvious first move: Live Activities. They show up in the watch Smart Stack, they update dynamically, they look great on watchOS. I started planning the whole thing — a pulsing Live Activity that shows what the hub is waiting on.
Then I actually read the fine print.
First hypothesis: Live Activities
watchOS Live Activities are sourced from the paired iPhone. The watch renders them, but the iPhone feeds them. Updates flow from phone to watch. Which means when the iPhone is in another room — or dead — the Live Activity on the watch goes dark too. That’s exactly the failure mode I’m building against.
The docs don’t flag this prominently. You have to trace through the ActivityKit architecture to find it. But it’s fundamental: the watch is downstream of the phone for Live Activity data. Live Activities are beautiful and the right tool for a lot of things. They’re just not the right tool when phone independence is the whole point.
The breakthrough: the watch has its own APNs address
The watch app can register directly with APNs and get its own device token — independent of the phone. That token maps to the watch app’s bundle ID, which follows the pattern com.yourcompany.YourApp.watchkitapp. Apple’s push infrastructure treats this as a completely separate push destination from the iOS app.
The tricky part: the watch can’t deliver its own token to the server directly. It has to relay it through the paired iPhone using WatchConnectivity. So the token travels watch → iPhone → push gateway, but the notifications then go server → APNs → watch, bypassing the iPhone entirely. The relay is one-time registration; delivery is direct.
On the server side, the fix was smaller than expected. Every APNs request carries an apns-topic header identifying the target bundle. The push gateway was already fanning out to every registered token for a given user — it just wasn’t changing the topic per token. iOS tokens kept getting the iOS bundle ID. Watch tokens were getting the same thing, which is why APNs returned DeviceTokenNotForTopic and quietly dropped them.
Fix: tag each token with its platform at registration time, then set the correct apns-topic when fanning out. iOS tokens get the iOS bundle ID. Watch tokens get the .watchkitapp bundle ID. Both share the same HTTP/2 connection to APNs — only the per-request header changes. Legacy tokens registered before the platform field existed keep working unchanged.
The anti-pattern
Assuming the watch is an iPhone accessor. It looks like one — same APNs key, same signing team, companion app on the same device. But from APNs’s perspective, the watch app is a sovereign client with its own address. If you send a watch token under the iOS topic, APNs doesn’t warn you. It just discards the notification. The error is DeviceTokenNotForTopic if you’re reading responses carefully, but most server-side push libraries don’t surface that per-recipient in a fan-out scenario.
“Make sure you use this [the
.watchkitappbundle ID] for yourapns-topicand everything will come alive — trust me. I spent a week trying to figure out what was wrong with the app, what was wrong with the server, and I almost went crazy.”
That’s from a 2019 Medium post that still describes exactly the confusion you’ll hit. The developer ecosystem rediscovers this one independently, every few years, every time someone tries to build a truly watch-independent feature. The fix is three lines of server-side code once you know where to look. Getting there costs days.
This was the backend half of the watch-independence push. The iOS-side token registration and WatchConnectivity relay are still building out, but the gateway is ready to route. When a needs-input alert fires now, the watch gets it directly — whether the phone is in my pocket, on a charger, or in another room entirely.
More on the broader architecture of AutoApp and how the hub routes decisions: Three Bugs, Zero Pixels gives a good picture of how the push system fits together.
— AutoJack