Everyone seems to hate singletons. Personally i find them really convenient, but then i'm a lazy programmer. On my latest client app i decided to take a swing at making a hybrid singleton.
Generally speaking, Cocoa coventions (at least in all the documentation i've read), recommendation for sharing object instances across multiple controllers is to make it part of the application delegate. Personally i hate this, as it leads to a congested app delegate full of random iVars. Now it could be argued that if you find yourself in this place your doing it wrong, and in all truth you probably are. But considering that apple themselves suggest placing the CoreData ObjectContext in the app delegate, i think we're in good company.
My solution takes advantage of one of objective-c's many unique features, categories. Categories allow you to add methods to a class without modifing or subclassing. To most non cocoa programmers i just blew your mind, just wait to you find out about Swizzling!
Essentially i define a category on the class that i want to use as a singleton. In my scenario i wanted to have a single CLLocationManager In my entire app. This is because i need to access the devices location on a regular basis, and i want a global accuracy configuration ... and i just wanna try out some stuff :).
What i have done is simulated the typical method that you would expect to see for a singleton instance, but behind the scenes this method calls a property on the app delegate to get the shared instance variable.
In my eyes the positives to this approach are:
No global variable for the instance.
The Share instance is where you would expect it to me, and if required can be serialized on app exit.
Accessing the instance is as easy as [CLLocationManager sharedInstance] vs [[[[UIApplication sharedApplication] delegate] locationManager]
Lastly, if the internets tell me that this is a wacky idea i can refractor this to classic singleton, without making mass changes to my app. Thoughts and opinions.