Editing Openai/691a5ca1-2b1c-8010-8cbd-8797f95aa8d9 (section)

==== If your requirements are: ====
* 100% offline
* accurate “4h” notifications
* App-Review-safe
* no push

Then:
'' Manual Start/Stop is the only ''reliable* core.
* Sensors (Core Motion + GPS speed) are helpers: - To auto-pause/resume the session while you’re alive - To reconcile missed time later - To show the user “we think you were driving Xh YYmin between A and B”.

What I would ship:
# Primary: the manual Start/Stop session pattern you already have.
# Secondary: - Use motion + GPS to auto-pause/resume during a session (e.g. if they’re obviously parked 20+ minutes, you auto-stop and prompt next time). - On app relaunch/BGTask, use Core Motion history to fill gaps and offer corrections (“We detected additional driving between 13:00 and 14:15, add to your log?”).
# Notifications: - Real-time: scheduled when session starts, kept accurate while background location keeps you alive. - Fallback: if BGTask or relaunch finds they already passed 4h, send a “late” reminder.

That gets you:
* Good UX (they don’t have to be perfect with Start/Stop).
* Honest technical constraints (you’re not fighting iOS background policy).
* A clean story for App Review: navigation/fitness-like background behavior initiated explicitly by the user, plus best-effort post-hoc detection.

If you want, next step we can sketch:
* A concrete DrivingSession SwiftData model
* A DrivingEngine actor with simple state transitions
* How to wire that into CLLocationManager + CMMotionActivityManager + BGTaskScheduler in Swift-concurrency style.