Patterns in Objective-C: Singleton Pattern

One of the challenges in switching to a new language is figuring out how design patterns adapt.   Sometimes the language has built-in facilities for the pattern, or features that work-around what the pattern was designed to do in the first place.

In Python, for example, it is trivial to implement a Command Dispatch Pattern and a Singleton pattern is almost wholly unnecessary–just create a module and put

“”"This module implements the singleton pattern”"”

at the top and voilà! It is a “singleton” for all intents and purposes.

Changing over to Objective-C is no different. This series will be about implementing design patterns in Objective-C as I’ve come to need them in my iPhone development experience.

One of the very first design patterns that I found I needed to use was the Singleton Pattern. I needed singular, static objects that had some variables and built-in functionality.


  • A commander that controlled the execution of the program.
  • A database manager.
  • A sound manager (Apple has kindly started to provide for this in iPhone SDK 2.2, but it isn’t present in 2.1 forcing the use of AudioQueues and/or SoundEngine).
  • A file processor
  • etc, etc, etc.

Basically a great deal of the “engine” to my game needed to share a few variables and group functionality together, but I didn’t want multiple copies running around.

After some research, this is the pattern that I settled on:

@implementation Singleton
+ (Singleton *)instance  {
static Singleton *instance;
@synchronized(self) {
if(!instance) {
instance = [[Singleton alloc] init];
return instance;

The singleton object can then be accessed with [Singleton instance].

Walking through this step at a time:

Line 4
Declares a static variable. If you come from a Java background, the placement of this is probably a little confusing: In C (and Objective-C and C++) a static local variable is retained between function calls (similar to how a Java class-level static variable is retained between multiple instances of the class).

Unlike Java, we don’t really have the same option for “static initialization,” so we are using a standard lazy-loading pattern.

Line 6
We want synchronization around the self object so that two [Singleton instance] calls don’t result in two independent copies of the object. Even if it is a single-threaded app, this sort of synchronization doesn’t have a huge speed penalty and is a good practice for future development.
Line 7
Check to see if the object is initialized already, if not we will then initialize it on Line 8
Line 14
Returns the created/preserved instance.

So long as everyone on your team recognizes that this object is a singleton, this pattern is simple and sufficient. It is possible to create more than one object (no private constructor or overloading init/alloc, so [[Singleton alloc] init] will happily create another object), but so long as everyone follows the convention there shouldn’t be any problems.

Other possible methods involve overloading alloc and/or init or using the XIB file for Dependency Injection.

Due to the + notation, people should naturally jump to the instance method and see that it is a Singleton before trying to alloc their own copy of the object. Thus, for most projects, I tend to think of this as the simplest and best approach in Objective-C.

This entry was posted in Uncategorized. Bookmark the permalink.

Error: The ad management script is not properly configured for this user

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>