Building iOS Live Activities for a motorcycle ride app and keep hitting the same wall: expo-widgets@56.0.15 doesn't let me pass staleDate to ActivityKit. Native side hardcodes staleDate: nil when it builds ActivityContent, no way to set it from JS.

The lock screen shows current speed + distance + elapsed time, fed by a background location task running every ~10s. Rider goes into a tunnel, GPS dies, OS may suspend the bg task entirely. The activity just freezes on whatever the last reading was. Phone shows "47 mph" for 30 minutes while the rider's at lunch. Apple's whole answer to this is ActivityContent.staleDate. Once the wall clock passes it, iOS dims the UI and pauses native timers automatically.

What I'd want exposed: an optional staleDate?: Date | null parameter on both LiveActivityFactory.start(props, url?, staleDate?) and LiveActivity.update(props, staleDate?). Nil keeps current behavior. We've been carrying a ~50-line pnpm patch since May doing exactly this. PR with the implementation: https://github.com/expo/expo/pull/46343

Implementation note for anyone reviewing: the JS Date is passed over the JSI bridge as a millisecond timestamp and converted to Date at the expo-widgets module boundary (Double? → Date(timeIntervalSince1970:)), so the PR is self-contained — it works without any change to expo-modules-core. (Earlier versions of this patch relied on a Date: Convertible fix in core, because that extension throws an ArgumentCastException on the Double timestamps getTime() produces over the bridge. Converting at the boundary sidesteps that entirely for staleDate.)

That core bug is still real and worth fixing on its own — the existing LiveActivity.end() path passes JS timestamps straight into Date? params and hits the same cast exception — so there's a separate, independent PR for it: https://github.com/expo/expo/pull/46340. It's no longer a prerequisite for staleDate, just a related cleanup.