Have you noticed a bit of seemingly inconsistent naming of class singletons in the Swift lexicon? I've been pondering this and have done a bit of real research.

I've found some good examples:

WidgetCenter.shared - "The shared widget center."

UserDefaults.standard - "The shared defaults object."

Calendar.current - "The user’s current calendar."

And when I'm looking at many author's and instructor's examples it is very common to see them use an API manager of some nature with a singleton pattern naming the static instance "shared" - I keep wondering... heck - I'm writing an App here, that API is not going to be shared with anyone. As far as my App goes... it's a single instance ... only *shared* via the global namespace - but I'm enclosing it inside this one manager class. Stupid name - shared!

I found a good article arguing for NOT using a singleton pattern: Swift Singletons: A Design Pattern to Avoid (With Examples) (2019) by Matteo Manferdini

But I don't think it will have any impact on Apple's favorite pattern.

Do you find any rhyme or reason for the Apple naming convention?

I thought why not be consistent and name it "singleton" - how quaint.

I also found this text in the Apple Docs:

Create a Singleton

You create simple singletons using a static type property, which is guaranteed to be lazily initialized only once, even when accessed across multiple threads simultaneously:

class Singleton {

static let shared = Singleton()

}

Note: they do NOT specify the typical private init() yet state: guaranteed to be lazily initialized only once. Where does that magic happen?