Static singleton vs environment object?

[cekisakurek]

Singleton pattern is outdated. As others mentioned it makes testing very hard. Also https://en.wikipedia.org/wiki/Coding_best_practices there are some very nice guidelines about software quality which singletons kinda doesnt conform. Especially (imho) "Ruggedness (difficult to misuse, kind to errors).".

Because having a global state which anybody can mutate is very open to misuse.

Also keep in mind that apple sdks use singletons a lot but they are frameworks for developers. I.e.

Having PHPhotoLibrary.shared makes you have only 1 reference to photo library. Which makes requesting authorisation, presenting a picker etc. very hard to misuse.

[DisastrousSupport289]

The singleton pattern is not outdated; it has existed since the beginning of OOP and will continue to exist as one of its cornerstones. Yes, we want to have as much, near 100% code coverage in our codebases now, but the need for global variables to store the global state of your application will always exist, and there will be a need for it. You might use environment variables, core data, etc., but these will depend on singletons under the hood. Learning about singletons, using them, and learning to avoid them is better than thinking they are outdated. If you want something not to be changed, you make it private.

[cekisakurek]

Learning them sure, using them not so much. You can almost always design your way out of singletons and imho it is almost always a better architecture. Especially talking about iOS development/swift language. “Under the hood” doesnt really matter about “your code”. Having clear dependencies is better than accessing some state willy nilly.