Dispatch_Once_T' Is Unavailable in Swift: Use Lazily Initialized Globals Instead

dispatch_once_t alternative in swift

In swift singleton can be written as,

class Model: NSObject {
    static let sharedInstance = Model()
}

then use Model.sharedInstance. you dont need dispatch once like in objective c.

source https://thatthinginswift.com/singletons/

Whither dispatch_once in Swift 3?

Since Swift 1.x, Swift has been using dispatch_once behind the scenes to perform thread-safe lazy initialization of global variables and static properties.

So the static var above was already using dispatch_once, which makes it sort of weird (and possibly problematic to use it again as a token for another dispatch_once. In fact there's really no safe way to use dispatch_once without this kind of recursion, so they got rid of it. Instead, just use the language features built on it:

// global constant: SomeClass initializer gets called lazily, only on first use
let foo = SomeClass()

// global var, same thing happens here
// even though the "initializer" is an immediately invoked closure
var bar: SomeClass = {
    let b = SomeClass()
    b.someProperty = "whatever"
    b.doSomeStuff()
    return b
}()

// ditto for static properties in classes/structures/enums
class MyClass {
    static let singleton = MyClass()
    init() {
        print("foo")
    }
}

So that's all great if you've been using dispatch_once for one-time initialization that results in some value -- you can just make that value the global variable or static property you're initializing.

But what if you're using dispatch_once to do work that doesn't necessarily have a result? You can still do that with a global variable or static property: just make that variable's type Void:

let justAOneTimeThing: () = {
    print("Not coming back here.")
}()

And if accessing a global variable or static property to perform one-time work just doesn't feel right to you -- say, you want your clients to call an "initialize me" function before they work with your library -- just wrap that access in a function:

func doTheOneTimeThing() {
    justAOneTimeThing
}

See the migration guide for more.

dispatch_once after the Swift 3 GCD API changes

From the doc:

Dispatch

The free function dispatch_once is no longer available in
Swift. In Swift, you can use lazily initialized globals or static
properties and get the same thread-safety and called-once guarantees
as dispatch_once provided. Example:

let myGlobal: () = { … global contains initialization in a call to a closure … }()
_ = myGlobal  // using myGlobal will invoke the initialization code only the first time it is used.

Using a dispatch_once singleton model in Swift

tl;dr: Use the class constant approach if you are using Swift 1.2 or above and the nested struct approach if you need to support earlier versions.

From my experience with Swift there are three approaches to implement the Singleton pattern that support lazy initialization and thread safety.

Class constant

class Singleton  {
   static let sharedInstance = Singleton()
}

This approach supports lazy initialization because Swift lazily initializes class constants (and variables), and is thread safe by the definition of let. This is now officially recommended way to instantiate a singleton.

Class constants were introduced in Swift 1.2. If you need to support an earlier version of Swift, use the nested struct approach below or a global constant.

Nested struct

class Singleton {
    class var sharedInstance: Singleton {
        struct Static {
            static let instance: Singleton = Singleton()
        }
        return Static.instance
    }
}

Here we are using the static constant of a nested struct as a class constant. This is a workaround for the lack of static class constants in Swift 1.1 and earlier, and still works as a workaround for the lack of static constants and variables in functions.

dispatch_once

The traditional Objective-C approach ported to Swift. I'm fairly certain there's no advantage over the nested struct approach but I'm putting it here anyway as I find the differences in syntax interesting.

class Singleton {
    class var sharedInstance: Singleton {
        struct Static {
            static var onceToken: dispatch_once_t = 0
            static var instance: Singleton? = nil
        }
        dispatch_once(&Static.onceToken) {
            Static.instance = Singleton()
        }
        return Static.instance!
    }
}

See this GitHub project for unit tests.

How to implement method swizzling swift 3.0?

First of all dispatch_once_t is unavailable in Swift 3.0.
You can choose from two alternatives:

1. Global variable

2. Static property of struct, enum or class

For more details, see that Whither dispatch_once in Swift 3

For different purposes you must use different implementation of swizzling

• Swizzling CocoaTouch class, for example UIViewController;
• Swizzling custom Swift class;

Swizzling CocoaTouch class

example swizzling viewWillAppear(_:) of UIViewController using global variable

private let swizzling: (UIViewController.Type) -> () = { viewController in

    let originalSelector = #selector(viewController.viewWillAppear(_:))
    let swizzledSelector = #selector(viewController.proj_viewWillAppear(animated:))

    let originalMethod = class_getInstanceMethod(viewController, originalSelector)
    let swizzledMethod = class_getInstanceMethod(viewController, swizzledSelector)

    method_exchangeImplementations(originalMethod, swizzledMethod) }

extension UIViewController {

    open override class func initialize() {
        // make sure this isn't a subclass
        guard self === UIViewController.self else { return }
        swizzling(self)
    }

    // MARK: - Method Swizzling

    func proj_viewWillAppear(animated: Bool) {
        self.proj_viewWillAppear(animated: animated)

        let viewControllerName = NSStringFromClass(type(of: self))
        print("viewWillAppear: \(viewControllerName)")
    } 
 }

Swizzling custom Swift class

To use method swizzling with your Swift classes there are two requirements that you must comply with (for more details):

• The class containing the methods to be swizzled must extend NSObject
• The methods you want to swizzle must have the dynamic attribute

And example swizzling method of custom Swift base class Person

class Person: NSObject {
    var name = "Person"
    dynamic func foo(_ bar: Bool) {
        print("Person.foo")
    }
}

class Programmer: Person {
    override func foo(_ bar: Bool) {
        super.foo(bar)
        print("Programmer.foo")
    }
}

private let swizzling: (Person.Type) -> () = { person in

    let originalSelector = #selector(person.foo(_:))
    let swizzledSelector = #selector(person.proj_foo(_:))

    let originalMethod = class_getInstanceMethod(person, originalSelector)
    let swizzledMethod = class_getInstanceMethod(person, swizzledSelector)

    method_exchangeImplementations(originalMethod, swizzledMethod)
}

extension Person {

    open override class func initialize() {
        // make sure this isn't a subclass
        guard self === Person.self else { return }
        swizzling(self)
    }

    // MARK: - Method Swizzling

    func proj_foo(_ bar: Bool) {
        self.proj_foo(bar)

        let className = NSStringFromClass(type(of: self))
        print("class: \(className)")
    }
}

How to not perform query on viewDidAppear once a picture has JUST been selected?

You should move your initial query in viewDidLoad(). That only gets called once, so it won't replace your image each time the view appears.

Otherwise, if, for some reason, you need to have it in view did viewDidAppear(), you could use dispatch_once to make sure your query only runs the first time the view appears.

Rough example of using dispatch_once:

var token: dispatch_once_t = 0
dispatch_once(&token) { () -> Void in
  // your query goes here
}

If you are using Swift 3, please see this other response on how to get dispatch_once like functionality.

App crashing with SIGABRT in `once.h` on definition of `dispatch_once`

In my case this issue occurred when a Storyboard and Class files were added to the project, and automatically added to the main Target, but not added to the Target Membership of the secondary Target.

The issue only occurred in the iOS Simulator, using the Target we use specifically for the simulator.

The issue was not caught by the compiler due to no real references to the class. Instead, a stringly-typed reference to the Storyboard name was used to construct the view:

[UIStoryboard storyboardWithName:@"storyboardFileThatWasNotAddedToThisTarget" bundle:nil];

Fixed by adding the new files to the secondary Target:

Found issue by adding an Exception Breakpoint to the Xcode debugger.

---

Related Topics