Introduction

Delaying work in Swift is usually about scheduling, not blocking. The important distinction is that a good delay lets the current thread stay responsive while the task runs later, whereas a bad delay freezes the thread and hurts the user experience.

The Classic Choice: DispatchQueue.asyncAfter

For a simple one-off delay, Grand Central Dispatch is still the most direct tool:

1import Foundation
2
3func showMessage() {
4    print("Hello after delay")
5}
6
7DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
8    showMessage()
9}

This schedules the closure to run about two seconds later on the main queue. It does not block the thread while waiting, which is why it is safe for UI-related work.

If the delayed task is not UI work, schedule it on a background queue instead:

DispatchQueue.global(qos: .userInitiated).asyncAfter(deadline: .now() + 1.5) {
    print("Background work started")
}

The queue you choose determines where the delayed code runs, so be deliberate about main-thread versus background execution.

The Modern Async Option: Task.sleep

In modern Swift concurrency, Task.sleep is often the best choice inside an async context. It fits naturally with async functions and supports structured concurrency.

1import Foundation
2
3func delayedGreeting() async {
4    try? await Task.sleep(for: .seconds(2))
5    print("Hello from async task")
6}
7
8Task {
9    await delayedGreeting()
10}

This is especially useful when the delayed action is part of a longer async workflow such as retry logic, debouncing, or staged network work.

Because it is part of Swift concurrency, it also composes cleanly with cancellation:

1let task = Task {
2    try await Task.sleep(for: .seconds(5))
3    print("This may never print")
4}
5
6task.cancel()

If the task is canceled before the sleep finishes, Task.sleep throws and the rest of the work can stop cleanly.

Use Timer for Repeating or Run-Loop-Based Delays

If you need a repeating action, Timer is a better fit than repeatedly scheduling asyncAfter.

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

Timer integrates with a run loop, which makes it useful for periodic UI and app-level tasks. Just remember to invalidate it when you no longer need it.

Choosing the Right Delay Mechanism

Use DispatchQueue.asyncAfter for simple delayed callbacks. Use Task.sleep when you are already in async code and want cancellation-aware behavior. Use Timer when the work repeats or when run-loop scheduling is the natural model.

All three approaches delay execution without blocking the current thread. That is the behavior you usually want in app code.

What Not to Use

Thread.sleep does delay execution, but it does so by blocking the current thread:

Thread.sleep(forTimeInterval: 2.0)
print("Finished sleeping")

That can freeze the main thread and make the app feel broken. It is only appropriate in narrow situations such as tests, command-line utilities, or controlled background-thread code where blocking is intentional.

Common Pitfalls

The biggest mistake is delaying UI work on a background queue and then touching UIKit or SwiftUI state from that queue. UI updates belong on the main thread.

Another common issue is capturing self strongly in a delayed closure and accidentally extending the lifetime of a view controller or other object. When needed, capture weakly inside the closure.

Timers are easy to leak conceptually. If you create a repeating timer and never invalidate it, it can keep firing long after the feature that started it should be inactive.

Summary

• Use DispatchQueue.asyncAfter for simple one-shot delays.
• Use Task.sleep inside async code when you want structured concurrency and cancellation support.
• Use Timer for repeating delays tied to a run loop.
• Avoid Thread.sleep on the main thread because it blocks instead of scheduling.
• Choose the execution queue carefully, especially for UI updates.