> I use a singleton on every project which is OO based but it only ever holds the service locator/container.

iOS devs love singletons; it seems like almost everything is a sharedSomething. Definitely a design smell.

Infrastructure can sometimes call for a singleton. It's very convenient to have something that is only created when it is needed. That way, users only pay for what they use, and they don't have to bear the conceptual burden of toting an extra context object around.

But it is a sledgehammer, and the people most inclined to abuse it lack the ability to tell the damage it is doing to the design.

It's mildly interesting to note that in practice essentially every GUI application on OS X is a singleton because the OS makes a strong distinction between application instances and windows (compared to e.g. MS Windows where the distinction is muddy).

Launch TextEdit.app twice and there is still only one running instance of the application. If you want a second window, you open a second window.

    # instance trivia:
    $ open -n /path/to.app

This is why it's nice to be able to parameterize "these are the actions I want done" with "here's how you combine them".

Tell me about it. To get single instance behaviour on windows you have to piss around with global mutexes.

That's not being a singleton since you can have a second instance if you ask for it.

Odd that the pair of you are nitpicking since I both said "in practice" and gave a command that could be used to produce that screenshot.

> Odd that the pair of you are nitpicking

It's not nitpicking, half of the singleton's purpose is to only ever have a single instance.

You're still not telling me anything I don't know.

If you knew it was wrong in the first place, why post it?

I now realise I was providing reading comprehension training†

† NOT, I REPEAT NOT, a literal course of training. I want to make it doubly clear that I did not certify anyone and can not be held responsible for any of their future actions vis-a-vis reading or comprehending.

For example, http://i.imgur.com/Qti6A9i.png

My favorite sight when I review iOS code for clients is seeing a method on the App delegate that 'preloads' a bunch of singletons in one go. It sets the tone for the rest of the trip.

In my experience, a large bunch of iOS developers tend to use singletons out of imitation. The "sharedWhatever" is the usual way for the framework to provide access to anything that is purposefuly single-instance[1]. Same thing with delegation, though that one is usually less cringe-worthy in practice.

[1] The "the accelerometer on your phone" kind of single-instance, which is a much more defensible use-case than what the typical iOS coder uses them for.

So, have we decided on what would be a better approach for storing global state?

Static variables and methods? Pass the instance down to all children?

It seems like there's no hard and fast rule.

I dislike singletons, but will gladly make a static method + static var from time to time.

IMHO, and to avoid abuse, singletons in iOS/MacOS should not be considered as a pattern that can replace class methods or simple C utility function. And this in all ways. I have seen piece of code doing everything with class methods while a set of plain C functions would have been more adequate (those were really utilities)