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

==== Your idea of a small aggregated engine is good — the trick is to design it so it’s pure and reusable, and you just plug it into whatever background runtime you can get. ====

Conceptually:

<syntaxhighlight lang="swift">actor DrivingEngine {
    struct Event {
        let date: Date
        let isDriving: Bool
        let speed: CLLocationSpeed?
    }

    private var currentSession: DrivingSession?
    private var accumulatedSeconds: TimeInterval = 0

    func handle(event: Event) -> DrivingUpdate {
        // Update state machine based on transitions
        // e.g. stationary -> driving, driving -> stopped, etc.
        // Use timestamps to accumulate driving time
    }

    func resume(from storedSession: DrivingSession?) {
        // Rehydrate from SwiftData / persisted state
    }
}

</syntaxhighlight>

Then you have different “front-ends” that feed events into it:
* Foreground: CMMotion + GPS didUpdateLocations.
* Background (while location is alive): same, but no UI.
* BGTask / app relaunch: synthetic events built from Core Motion history (queryActivityStarting) and maybe historical location, if you’re storing that.

Your SwiftUI view just observes some published view model that’s driven by this actor; in the background scenario you skip the UI part and just call the engine then schedule notifications.

Important: this engine doesn’t rely on timers; it operates only off timestamps from events, which works fine whether events are real-time or “I fetched a batch an hour later”.