Singleton in Swift

Pattern or the anti-pattern?

Part 1. The Pattern

So what this pattern is all about. Let me give you by book definition, as it is really nice and solid. 💪

Singleton pattern makes sure that there is only one instance of object and provides its access point.

It is really nothing more there. But you could ask how and why do we need one. First of all, the Singleton pattern is very common and widely used throughout CocoaTouch. Every time you see sharedInstance or simply shared either as function or static variable you encounter Singleton pattern in use. That is the way for iOS APIs to enforce proper usage of various functionalities. For example AVAudioSession does not provide initializers, instead whe have to use its sharedInstance() so that only one thing everywhere in system is playing audio at any given time. Sounds pretty useful, isn’t it? 😉

Sauron created One Ring as the Singleton

Part 2. Swift

So it is time fot the juicy Swift implementation. 🍹There were various ways to implement Singletion both in Objective-C and Swift, but I like the simplest one (credits to krakendev.io <- read to see few diffrent approaches).

That is the way I write singletons for some time (not that I write them too often). What is going on here?

• Static constant is initialized only once and then it contains created object (since it is reference type actually pointer to it).
• Private initializer ensures that object can be created only from within that scope (from Swift 3.0, earlier you could access it from within file).

Remember it is your responsiblility to ensure Singleton cannot be played diffrently.

That’s easy. 💍

Part 3. The anti-pattern

If it is so nice and simple, why don’t we use it everywhere? Well as you probably can figure out by the title of the section the Singleton is often considered as anti-pattern so rather bad practice. And there are few problems which you must have in mind.

1. Multi-threading. As there is only one instance available, exposing it’s methods publicly you can access the Singleton from all different threads. In Swift we do not have reliable way to prevent 💩 hitting the fan in that case. It is your job to make sure the code will run fine or will only be accessed from one thread but neither language nor compiler will help you in that task.
2. Unit testing. Singletons are pretty much impossible to test. Of course you can test it’s methods but you cannot test it working in your app enviroment. And if you cannot test something it is or it could be dangerous.
3. Unexpected behavior. Well, anyone can access the Singleton so you cannot prevent strange thing going on when something uses in a bad place in a bad time.

Conclusion

So that was my brief description of the Singleton pattern. Contact me if you would like to discuss it or anything. Let’s finish up with the gif:

In production applications I rarely use the Singleton. I always consider all other possibilities before. A lot of problems can be solved by using Dependency Injection. It is testable, and you are the one in control. Which is nice. 😀

Oh, and the series about Constructional Patterns is officially finished. On to the…

… Structural Patterns, starting with the Adapter!