Swift 5后台Timer实现求助：复刻iOS原生计时器遇真机问题

Hey there, let’s break down how to get a working timer that behaves correctly in the background on real iOS devices—this is a super common pain point because of Apple’s strict background execution rules, so let’s cut through the confusion.

First, Let’s Clear Up the Core Rule #

iOS does not allow regular apps to run timers indefinitely in the background. No matter if you use DispatchSourceTimer, Timer, or any other timer mechanism, the system will suspend your app’s process shortly after it moves to the background. The 180-second "background task window" you mentioned is the maximum time the system gives you to wrap up critical tasks—not to run a continuous timer.

Why Did the Simulator Work But the Real Device Didn’t? #

Simulators don’t enforce background suspension rules strictly. Enabling the Audio background mode tricked the simulator into keeping your app active, but on real devices, the system only allows background audio if your app is actually playing audio. Using this permission just to keep a timer running is against App Store guidelines anyway, so it’s not a valid solution.

How Do Legitimate Timer Apps on the App Store Work? #

They don’t run timers in the background at all! The core logic is timestamp tracking and foreground calculation, paired with legitimate background permissions for notifications:

• Track timestamps, not continuous ticks:
  When the user starts the timer, save the current Date() (start time) to UserDefaults or local storage. When they pause, calculate the elapsed time (Date().timeIntervalSince(startDate)) and add it to an accumulated total. When the app comes back to the foreground, you simply calculate the total elapsed time as:

  let totalElapsed = accumulatedTime + (startDate != nil ? Date().timeIntervalSince(startDate!) : 0)
  

  This way, you don’t need a timer running 24/7—you just compute the difference when you need it.
• Use local notifications for end-of-timer alerts:
  If you need to alert the user when the timer finishes, don’t rely on a background timer. Instead, use UNUserNotificationCenter to schedule a local notification with a trigger set to the exact end time. The system will handle firing the notification even if your app is suspended or terminated.
• Leverage limited background permissions (if needed):
  For updating widgets or syncing data occasionally, use Background Fetch or the Background Tasks framework. But these are for periodic tasks, not continuous timers—they can’t guarantee real-time ticks.

Why Didn’t the Medium Tutorial’s RepeatingTimer Work? #

That DispatchSourceTimer implementation is just a more robust timer for foreground or short background tasks. Once the system suspends your app, all threads (including the dispatch queue running the timer) are paused. It can’t bypass iOS’s background suspension rules, so it won’t work for long-term background timing.

Step-by-Step Logical Implementation #

1. Start Timer:
   • Save startDate = Date() and reset accumulatedTime = 0 to persistent storage.
2. Pause Timer:
   • Calculate elapsed time since start, add to accumulatedTime, then clear startDate.
3. Resume Timer:
   • Set startDate = Date() again.
4. Get Current Elapsed Time:
   • If startDate exists, compute accumulatedTime + Date().timeIntervalSince(startDate). Otherwise, use accumulatedTime.
5. Schedule End Notification:
   • Calculate the remaining time until the timer finishes.
   • Create a UNMutableNotificationContent with your alert message.
   • Use UNTimeIntervalNotificationTrigger with the remaining time, then add the notification via UNUserNotificationCenter.

A Note on the WWDC2019 Background Framework #

The session you watched covers the Background Tasks framework, which is designed for heavy tasks like large downloads or data syncs. The system wakes your app only when it deems necessary (e.g., based on user usage patterns) and limits how long the task can run. It’s not meant for continuous timer execution.

内容的提问来源于stack exchange，提问作者Rich