Openai/691a5ca1-2b1c-8010-8cbd-8797f95aa8d9

This conversation was exported from ChatGPT

gpt-5-1-thinking

User: How can this be approached ?

How can this be approached ? I was thinking a mix of core motion and gps speed for redundancy i believe it could a better approach with a small observable engine that can agrégate the data to decide when notifications should scheduled along bacgound task ? Background App updates on iOS – Looking for solutions

I'm working on an iOS app built in Swift + SwiftUI, that tracks driving time for specific drivers and need to schedule local notifications based on accumulated driving time, all while the app runs in the background...

I'm using CoreMotion to detect when a user is driving (via .automotive state). When driving starts, I capture the activity.startDate(The time at which the change in motion occurred.) from CMMotionActivity and store it in my data model. ( SwiftData ).

The app accumulates driving time as the user transitions between "Driving" and "Stopped" states. Once they hit 4 hours of driving, I need to fire a local notification reminding them to take a mandatory break.

The Problem: The app needs to update this accumulated time and check thresholds while in the background (screen locked). However, iOS heavily restricts background execution:

• Timers don't run in the background
• SwiftData updates don't trigger automatically
• Live Activities don't update reliably without push notifications
• Standard background modes don't fit this use case

What I've tried...

• CoreMotion does detect activity changes in the background and provides accurate timestamps
• But my app code doesn't execute to process these updates until the user reopens the app from the background
• Push notifications would work but feel like overkill for a small, offline first app

My current workaround... I've pivoted to a manual approach, users tap "Start Driving" and "Stop Driving" buttons. This lets me schedule local notifications from a known start time, which works reliably when the phone is in the background.

My question... Has anyone found a way to update app state and check conditions in the background based on CoreMotion activity changes, without relying on push notifications? Or is manual user input the only practical solution for this type of offline tracking app?

CoreMotion:

https://developer.apple.com/documentation/coremotion/cmmotionactivity

Assistant: Short version: there’s no “secret” API that lets Core Motion wake your app and run arbitrary logic while you’re fully i…

Short version: there’s no “secret” API that lets Core Motion wake your app and run arbitrary logic while you’re fully in the background or terminated — at least not in a way that’s precise enough for a regulatory 4-hour driving limit, fully offline, and App-Review-safe.

But you can get closer than “pure manual start/stop” with a hybrid design.

I’ll break it into:

1. What iOS actually allows here
2. A realistic architecture for your use case
3. How I’d model the “observable engine”
4. What I’d ship given App Review + UX constraints

Key truths:

• CMMotionActivityManager.startActivityUpdates does not wake a suspended/terminated app. It only delivers events while your process is actually running (foreground or kept alive by some background mode).Apple Developer
• Core Motion history (via queryActivityStarting(from:to:to:withHandler:)) can be queried when your app is brought back, giving you up to 7 days of activity segments (including .automotive).devfright.com
• BGTaskScheduler (BGAppRefreshTask, BGProcessingTask) gives you opportunistic wake-ups, not “wake me right at hour 4 of driving” precision. iOS decides when to run your task based on usage, power, etc.Apple Developer
• Background modes (Location, Audio, VoIP, etc.) are heavily scoped. Apple expects you to actually be doing that foregroundly-reasonable use case (navigation, fitness tracking, turn-by-turn, etc.). Misusing them just to keep the app alive is very likely to get flagged.Apple Developer
• Even with the newer “continued processing” style APIs in iOS 26, Apple is focused on user-initiated, bounded tasks (exports, uploads, etc.), not open-ended sensing like “watch for 4 hours of future driving”.Apple Developer

So:

Your current manual Start/Stop approach is actually very in line with what Apple wants: user-initiated, explicit, and bounded.

Given your offline-first + no push requirements, I’d treat this as a hybrid of:

• Manual “Start/Stop Driving” (primary source of truth)
• Motion + Location (used for validation and correction, not as the sole trigger)
• Periodic BGTasks to reconcile history and send “late” notifications if needed

1. User taps Start Driving - Start an in-app “session”: - drivingSession.startDate = Date() - enable background location with allowsBackgroundLocationUpdates = true and activityType = .automotiveNavigation (or .otherNavigation if review is picky) - start CMMotionActivityManager.startActivityUpdates on a background queue

1. While alive (foreground or kept alive by location): - Your “engine” consumes: - Location updates (speed, GPS validity) - Motion activity (.automotive, .stationary, confidence) - It maintains an accumulatedDrivingSeconds counter for the active session.
2. When accumulated driving reaches 4 hours: - Schedule a local notification via UNUserNotificationCenter. - (Optionally also schedule earlier “pre-break” notifications at e.g. 3h30.)
3. When user taps Stop Driving: - Close that session in SwiftData, record endDate, total driving seconds. - Stop background location + stop motion updates.

This is essentially exactly what navigation / running apps do, just with different output.

You can’t force iOS to keep you alive forever. So plan for:

• Suspended but not killed: you may still get some location wakeups; process them and let your engine tick forward. But you can’t depend on high-frequency updates.
• Killed (by system or user): everything stops. Here’s where Core Motion history + BGTasks come in.

On next relaunch (or BGTask wake):

1. Use CMMotionActivityManager.queryActivityStarting(from:to:to:handler:) to fetch activity segments since the last time you reconciled.devfright.com
2. Filter segments where activity.automotive == true and confidence is .medium/.high.
3. Reconstruct driving intervals and: - Merge them with your stored sessions (manual Start/Stop windows). - Adjust any session that looks “off” (e.g. user forgot to tap Start but you see 2h of automotive → you can offer to auto-fill it next time they open the app).
4. If from that reconstruction you see: - “User crossed 4h of continuous driving X minutes ago and we didn’t notify”: - Send a late notification (“You’ve been driving for about 4 hours. Time for a break?”).

This is not perfect to the minute—but it’s honest, offline, and uses the tools Apple actually gives you.

You can register a BGAppRefreshTask:

• On sceneWillResignActive, schedule a refresh task for, say, 30–60 min in the future.
• In the task handler: - Run the same Core Motion history reconciliation. - Update SwiftData. - If you see they’re well past 4 hours (and no notification has fired yet), send one now.

You have to accept:

• BGTasks are not guaranteed to fire on schedule. They’re “when the system feels like it”.Apple Developer
• This is more “nudge the user if they forget the app exists”, not “tachograph-level compliance.”

So the real-time guarantee only exists while you’re alive under a background mode; outside of that, it’s “best effort”.

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:

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
    }
}

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”.

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:

1. Primary: the manual Start/Stop session pattern you already have.
2. 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?”).
3. 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.

User: Well I don’t think any app can do this driving thing while being killed from memory so yes I was thking the dev should …

Well I don’t think any app can do this driving thing while being killed from memory so yes I was thking the dev should allow the user to start a driving session so the app can kickstart the tracking also because we will need to request permission the inclusion of gps can offer more insights like distance traveled points of interest and potentially weather data and speed data that could be beneficial ? Also a live activity could be use for more reliable tracking and informational element?

Assistant: Yeah, your instinct is spot-on:

Yeah, your instinct is spot-on:

• User-started “driving sessions”
• Location + motion as enrichment + redundancy
• Optional Live Activity as the “UI surface” for the session

is exactly how I’d sell/architect this.

Let me structure it around your ideas.

1. “Start Driving Session” as the core

Totally agree: no realistic, App-Review-friendly app is doing precise continuous tracking when it’s been fully killed. So:

• User taps Start driving
• You: - Request / confirm Location, Motion, and Notification permissions - Start your DrivingSession in your persistence layer - Enable background location - Start Core Motion updates - Optionally start a Live Activity

This ticks all of Apple’s boxes:

• User-initiated
• Clear modal behavior: “I am driving now”
• Easy to explain in review notes (“when the user starts a driving session, we track time and occasionally notify them to rest”).

2. Why adding GPS is absolutely worth it

You’re not just doing this to keep the app alive — you get a ton of extra signal:

1. Distance & route insights - Integrate with CLLocationManager: - Accumulate total distance - Optionally store a low-frequency “breadcrumb trail” (e.g. every 1–2 minutes) for a post-drive map. - These can feed: - “You drove 240 km today” - Per-session stats (avg speed, max speed, etc.)
2. Speed validation / redundancy - Combine: - CMMotionActivity.automotive - GPS speed - Use speed thresholds to: - Ignore weird .automotive when the user is walking near a road - Detect “moving but not driving” vs “clearly driving” - You can also use speed drop + long stationary intervals to auto-pause/end sessions if the user forgets to tap Stop.
3. Weather at route segments (if you want to get fancy) - If the product ever wants weather: - Grab the start location and maybe a few intermediate points - Fetch weather when online (current or historical depending on API). - Then you can show “You drove X km in rainy conditions” etc. - This fits nicely with your offline-first stance: store location points locally, only fetch weather opportunistically when online / user views history.
4. POIs & “break suggestions” (future idea) - With GPS + distance + time, you can later add: - “Suggest nearby rest stops after 3.5h driving” - “Log where you took breaks”

All of that turns “we just need 4h timer” into a useful driving log, which makes your permission requests much easier to justify.

3. Live Activity as the “session HUD”

Yep, a Live Activity is a really natural fit here:

What it can show:

• Elapsed driving time (e.g. 3h 12m)
• Time remaining until the 4-h break (e.g. 48m to mandatory break)
• Maybe: - Distance so far - Current speed (rounded / smoothed) - Simple state: “Driving / On break”

Why it’s useful:

• Shows up on the Lock Screen + Dynamic Island while they’re driving
• Gives a persistent “this is running” indicator even if your main app UI is closed
• You can update it locally (no need for push) as long as the app has some runtime (foreground or location-kept in background)

Constraints to keep in mind:

• You don’t want to spam updates every second (battery + ActivityKit limits). - For a driving app, updating every 15–60 seconds is usually enough: - The main important values (elapsed time, time to break) don’t need second-precision.
• Live Activity doesn’t itself keep your app alive forever: - It’s a surface you update while you have background execution (e.g. via location). - It’s perfect as a display + “quick access” to the session, not as the core engine.

So the pattern is:

1. User taps Start driving
2. You: - Start the session in your own model - Start background location + motion - Start a Live Activity representing that session
3. Your engine updates: - Local state (driving time, distance, etc.) - Live Activity state (via ActivityKit)
4. When user taps Stop driving: - Finish session in storage - Stop location + motion - End the Live Activity

4. How I’d wire motion + GPS + notifications + Live Activity together

High-level flow:

A. On “Start driving”

• Persist a new DrivingSession with startDate.
• CLLocationManager: - activityType = .automotiveNavigation (or appropriate) - allowsBackgroundLocationUpdates = true - Reasonable desiredAccuracy / distanceFilter.
• CMMotionActivityManager: - Start activity updates to refine “driving vs stopped”.
• UNUserNotificationCenter: - Schedule a 4h local notification from “now” as a baseline. - Optionally schedule a 3h30 “pre-break” reminder.
• ActivityKit: - Start a Live Activity with: - elapsed at 0 - targetBreakTime = now + 4h - optional fields: distance, average speed.

B. While session is running

Your engine (actor / object) receives:

• Motion updates → determine “currently driving or not”
• Location updates → compute: - distance - speed - optionally use timestamp deltas for more accurate time accounting.

The engine:

• Maintains driving seconds (don’t rely on a timer; use timestamps).
• Whenever state changes enough (e.g. every 30s or significant change), it: - Updates Live Activity with the latest stats. - Optionally adjusts the planned notification fire time if your logic changes - But you can also keep it simple and just fire at exactly 4h from when they tapped Start.

C. On “Stop driving”

• Close the session (store endDate, total time, distance, etc.).
• Cancel any future driving-specific notifications (if desired).
• End Live Activity.

5. UX + App Review story

You now have a clean, defensible story:

• The app doesn’t try to “spy” in the background all day.
• The user explicitly starts a driving session (like starting navigation or a workout).
• During that session you: - Use location + motion to track driving time, distance, and speed. - Show a Live Activity HUD for quick glanceable info. - Trigger local notifications when they’ve been driving too long and should rest.

If your dev friend wants to go deeper, we can:

• Sketch a concrete DrivingSession model and DrivingEngine actor
• Draft the Live Activity attributes/content state
• Outline the permission flow and “why we need GPS” copy in Settings/Onboarding

…but conceptually, yes: your proposed combo (manual session + motion + GPS + optional Live Activity) is exactly the sane way to do this on iOS without servers.