I use a singleton on every project which is OO based but it only ever holds the service locator/container.
Asp.net MVC is a fine real world example of how to fuck up Singletons (routing dictionary, global action filters etc). Totally stinks and is coupled like glue.
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.
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.appIt's not nitpicking, half of the singleton's purpose is to only ever have a single instance.
† 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.
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.
Static variables and methods? Pass the instance down to all children?
I dislike singletons, but will gladly make a static method + static var from time to time.