brandonscript
brandonscript

Reputation: 72885

How do I write dispatch_after GCD in Swift 3, 4, and 5?

In Swift 2, I was able to use dispatch_after to delay an action using grand central dispatch:

var dispatchTime: dispatch_time_t = dispatch_time(DISPATCH_TIME_NOW, Int64(0.1 * Double(NSEC_PER_SEC))) 
dispatch_after(dispatchTime, dispatch_get_main_queue(), { 
    // your function here 
})

But this no longer seems to compile since Swift 3. What is the preferred way to write this in modern Swift?

Upvotes: 484

Views: 248793

Answers (9)

Rob
Rob

Reputation: 437532

The syntax is simply:

// to run something in 0.1 seconds

DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) {
    // your code here
}

Note, the above syntax of adding seconds as a Double seems to be a source of confusion (esp since we were accustomed to adding nsec). That “add seconds as Double” syntax works because deadline is a DispatchTime and, behind the scenes, there is a + operator that will take a Double and add that many seconds to the DispatchTime:

public func +(time: DispatchTime, seconds: Double) -> DispatchTime

But, if you really want to add an integer number of msec, μs, or nsec to the DispatchTime, you can also add a DispatchTimeInterval to a DispatchTime. That means you can do:

DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(500)) {
    // 500 msec, i.e. 0.5 seconds
    …
}

DispatchQueue.main.asyncAfter(deadline: .now() + .microseconds(1_000_000)) {
    // 1m microseconds, i.e. 1 second
    …
}

DispatchQueue.main.asyncAfter(deadline: .now() + .nanoseconds(1_500_000_000)) {
    // 1.5b nanoseconds, i.e. 1.5 seconds
    …
}

These all seamlessly work because of this separate overload method for the + operator in the DispatchTime class.

public func +(time: DispatchTime, interval: DispatchTimeInterval) -> DispatchTime

It was asked how one goes about canceling a dispatched task. To do this, use DispatchWorkItem. For example, this starts a task that will fire in five seconds, or if the view controller is dismissed and deallocated, its deinit will cancel the task:

class ViewController: UIViewController {

    private var item: DispatchWorkItem?
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        item = DispatchWorkItem { [weak self] in
            self?.doSomething()
            self?.item = nil
        }
        
        DispatchQueue.main.asyncAfter(deadline: .now() + 5, execute: item!)
    }

    deinit {
        item?.cancel()
    }
    
    func doSomething() { … }
}

Note the use of the [weak self] capture list in the DispatchWorkItem. This is essential to avoid a strong reference cycle. Also note that this does not do a preemptive cancelation, but rather just stops the task from starting if it hasn’t already. But if it has already started by the time it encounters the cancel() call, the block will finish its execution (unless you’re manually checking isCancelled inside the block).


Swift concurrency

While the original question was about the old GCD dispatch_after vs. the newer asyncAfter API, this raises the question of how to achieve the same behavior in the newer Swift concurrency and its async-await. As of iOS 16 and macOS 13 we would prefer Task.sleep(for:):

try await Task.sleep(for: .seconds(2))        // 2 seconds
…

Or

try await Task.sleep(for: .milliseconds(200)) // 0.2 seconds
…

Or if we need to support back to iOS 13 and macOS 10.15, we would use Task.sleep(nanoseconds:) instead.

And to support cancelation, save a Task:

class ViewController: UIViewController {

    private var task: Task<Void, Error>?

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)

        task = Task {
            try await Task.sleep(for: .seconds(5))
            await doSomething()
        }
    }

    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)

        task?.cancel()
    }

    func doSomething() async { … }
}

Or in SwiftUI, we might use the .task {…} view modifier, which “will automatically cancel the task at some point after the view disappears before the action completes.” We do not even need to save the Task to manually cancel later.

We should recognize that before we had Swift concurrency, calling any sleep function used to be an anti-pattern, one that we would studiously avoid, because it would block the current thread. That was a serious error when done from the main thread, but even was problematic when used in background threads as the GCD worker thread pool is so limited. But the new Task.sleep functions do not block the current thread, and are therefore safe to use from any actor (including the main actor).

Upvotes: 1191

rockdaswift
rockdaswift

Reputation: 9983

If you just want the delay function in

Swift 4 & 5

func delay(interval: TimeInterval, closure: @escaping () -> Void) {
     DispatchQueue.main.asyncAfter(deadline: .now() + interval) {
          closure()
     }
}

You can use it like:

delay(interval: 1) { 
    print("Hi!")
}

Upvotes: 63

Midhun
Midhun

Reputation: 2177

Swift 5 and above

DispatchQueue.main.asyncAfter(deadline: .now() + 2, execute: {
   // code to execute                 
})

Upvotes: 3

MANN
MANN

Reputation: 3520

None of the answers mentioned running on a non-main thread, so adding my 2 cents.

On main queue (main thread)

let mainQueue = DispatchQueue.main
let deadline = DispatchTime.now() + .seconds(10)
mainQueue.asyncAfter(deadline: deadline) {
    // ...
}

OR

DispatchQueue.main.asyncAfter(deadline: DispatchTime.now() + .seconds(10)) { 
    // ...
}

On global queue (non main thread, based on QOS specified) .

let backgroundQueue = DispatchQueue.global()
let deadline = DispatchTime.now() + .milliseconds(100)
backgroundQueue.asyncAfter(deadline: deadline, qos: .background) { 
    // ...
}

OR

DispatchQueue.global().asyncAfter(deadline: DispatchTime.now() + .milliseconds(100), qos: .background) {
    // ...
}

Upvotes: 1

Suhit Patil
Suhit Patil

Reputation: 12023

Swift 4

You can create a extension on DispatchQueue and add function delay which uses DispatchQueue asyncAfter function internally

extension DispatchQueue {
   static func delay(_ delay: DispatchTimeInterval, closure: @escaping () -> ()) {
      DispatchQueue.main.asyncAfter(deadline: .now() + delay, execute: closure)
   }
}

and use

DispatchQueue.delay(.milliseconds(10)) {
   print("task to be done")
}

Upvotes: 5

Md. Ibrahim Hassan
Md. Ibrahim Hassan

Reputation: 5467

A somewhat different flavour of the Accepted Answer.

Swift 4

DispatchQueue.main.asyncAfter(deadline: .now() + 0.1 + .milliseconds(500) + 
.microseconds(500) + .nanoseconds(1000)) {
                print("Delayed by 0.1 second + 500 milliseconds + 500 microseconds + 
                      1000 nanoseconds)")
 }

Upvotes: 5

Sverrisson
Sverrisson

Reputation: 18157

Swift 4:

DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(100)) {
   // Code
}

For the time .seconds(Int), .microseconds(Int) and .nanoseconds(Int) may also be used.

Upvotes: 131

Marco Pappalardo
Marco Pappalardo

Reputation: 955

after Swift 3 release, also the @escaping has to be added

func delay(_ delay: Double, closure: @escaping () -> ()) {
  DispatchQueue.main.asyncAfter(deadline: .now() + delay) {
    closure()
  }
}

Upvotes: 16

jjatie
jjatie

Reputation: 5332

call DispatchQueue.main.after(when: DispatchTime, execute: () -> Void)

I'd highly recommend using the Xcode tools to convert to Swift 3 (Edit > Convert > To Current Swift Syntax). It caught this for me

Upvotes: 3

Related Questions