Introduction

In Swift, doing something every few minutes usually means scheduling repeating work with a timer. The right tool depends on where the code runs. For UI-driven app code, Timer is often the simplest choice. For more control over queues and precision, DispatchSourceTimer is a strong alternative. The one big caveat is that repeating timers do not turn an iOS app into a background scheduler automatically.

Use Timer on the Main Run Loop

For many app-level tasks, Timer.scheduledTimer is the easiest option.

1import Foundation
2
3final class Poller {
4    private var timer: Timer?
5
6    func start() {
7        timer = Timer.scheduledTimer(withTimeInterval: 5 * 60, repeats: true) { _ in
8            print("Run task")
9        }
10    }
11
12    func stop() {
13        timer?.invalidate()
14        timer = nil
15    }
16}

Here the task runs every 5 minutes. Because the timer is scheduled on the current run loop, this pattern is convenient in UI apps where the main run loop is already active.

Avoid Losing the Timer

If you create a timer and do not keep a strong reference to it, it may stop being useful or become difficult to cancel cleanly. That is why the example stores it in a property.

You should also invalidate the timer when the work is no longer needed:

timer?.invalidate()
timer = nil

This is important in controllers or services whose lifecycle should not leak repeating work.

Use DispatchSourceTimer for More Control

If you want a GCD-based timer on a specific queue, use DispatchSourceTimer.

1import Foundation
2
3final class BackgroundPoller {
4    private var timer: DispatchSourceTimer?
5
6    func start() {
7        let queue = DispatchQueue(label: "poller.queue")
8        let timer = DispatchSource.makeTimerSource(queue: queue)
9        timer.schedule(deadline: .now(), repeating: .minutes(5))
10        timer.setEventHandler {
11            print("Run background task")
12        }
13        timer.resume()
14        self.timer = timer
15    }
16
17    func stop() {
18        timer?.cancel()
19        timer = nil
20    }
21}

This is useful when the work should not live on the main thread.

Swift Concurrency Alternative

If you are already using Swift concurrency, a task loop can express repeating behavior clearly.

1import Foundation
2
3func startRepeatingTask() -> Task<Void, Never> {
4    Task {
5        while !Task.isCancelled {
6            print("Run task")
7            try? await Task.sleep(for: .minutes(5))
8        }
9    }
10}

This approach is pleasant in async-heavy code, though it is still a repeating loop and still needs cancellation management.

iOS Background Limits

A repeating timer is not a guarantee that code will run every X minutes while an iPhone app sits in the background. iOS suspends background apps aggressively unless you are using a specific background mode or system-supported scheduling mechanism.

So:

• timers work normally while the app is active
• background execution is limited by platform rules
• "every five minutes forever" is not a realistic mobile app assumption

That is a platform constraint, not a timer bug.

Common Pitfalls

The most common mistake is assuming Timer will keep firing indefinitely while the app is backgrounded. On iOS, that is usually false.

Another issue is forgetting to invalidate the timer, which can keep work running longer than intended.

Some developers also schedule timers on threads without a run loop and then wonder why nothing happens. Timer depends on a run loop, while DispatchSourceTimer depends on a dispatch queue.

Finally, choose the interval carefully. A very frequent repeating task can hurt battery life and app responsiveness.

Summary

• Use Timer.scheduledTimer for simple repeating work in app code.
• Use DispatchSourceTimer when you need more queue control.
• A Swift concurrency loop with Task.sleep is another valid option in async-heavy code.
• Keep a reference to the timer and stop it explicitly when needed.
• On iOS, timers do not guarantee unlimited background execution every X minutes.