You ask whether this is the "best way to create singleton".
- First, yes, this is a thread-safe solution. This - dispatch_oncepattern is the modern, thread-safe way to generate singletons in Objective-C. No worries there.
 
- You asked, though, whether this is the "best" way to do it. One should acknowledge, though, that the - instancetypeand- [[self alloc] init]is potentially misleading when used in conjunction with singletons.
 - The benefit of - instancetypeis that it's an unambiguous way of declaring that the class can be subclassed without resorting to a type of- id, like we had to do in yesteryear.
 - But the - staticin this method presents subclassing challenges. What if- ImageCacheand- BlobCachesingletons were both subclasses from a- Cachesuperclass without implementing their own- sharedCachemethod?
 - ImageCache *imageCache = [ImageCache sharedCache];  // fine
BlobCache *blobCache = [BlobCache sharedCache];     // error; this will return the aforementioned ImageCache!!!
 - For this to work, you'd have to make sure subclasses implement their own - sharedInstance(or whatever you call it for your particular class) method.
 - Bottom line, your original - sharedInstancelooks like it will support subclasses, but it won't. If you intend to support subclassing, at the very least include documentation that warns future developers that they must override this method.
 
- For best interoperability with Swift, you probably want to define this to be a property, not a class method, e.g.: - @interface Foo : NSObject
@property (class, readonly, strong) Foo *sharedFoo;
@end
 - Then you can go ahead and write a getter for this property (the implementation would use the - dispatch_oncepattern you suggested):
 - + (Foo *)sharedFoo { ... }
 - The benefit of this is that if a Swift user goes to use it, they'd do something like: - let foo = Foo.shared
 - Note, there is no - (), because we implemented it as a property. Starting Swift 3, this is how singletons are generally accessed. So defining it as a property helps facilitate that interoperability.
 - As an aside, if you look at how Apple is defining their singletons, this is the pattern that they've adopted, e.g. their - NSURLSessionsingleton is defined as follows:
 - @property (class, readonly, strong) NSURLSession *sharedSession;
 
- Another, very minor Swift interoperability consideration was the name of the singleton. It's best if you can incorporate the name of the type, rather than - sharedInstance. For example, if the class was- Foo, you might define the singleton property as- sharedFoo. Or if the class was- DatabaseManager, you might call the property- sharedManager. Then Swift users could do:
 - let foo = Foo.shared
let manager = DatabaseManager.shared
 - Clearly, if you really want to use - sharedInstance, you could always declare the Swift name should you want to:
 - @property (class, readonly, strong) Foo* sharedInstance NS_SWIFT_NAME(shared);
 - Clearly, when writing Objective-C code, we shouldn't let Swift interoperability outweigh other design considerations, but still, if we can write code that gracefully supports both languages, that's preferable. 
- I agree with others who point out that if you want this to be a true singleton where developers can’t/shouldn’t (accidentally) instantiate their own instances, the - unavailablequalifier on- initand- newis prudent.