Answer.

The singleton pattern is a popular technique for creating an object that exists as a single instance in an application. In Swift, the implementation of the pattern has been simplified by the support for static properties and thread safety.

Background:

In Objective-C, implementing the Singleton required long and non-trivial code related to thread safety. In Swift, this issue has been resolved through the lazy initialization of static properties.

Problem:

Singletons are often used for centralized access to application state (e.g., Session, configuration, services), but improper usage leads to implicit dependencies and reduced testability of the code.

Solution:

In Swift, the pattern is implemented through a static constant of type. This guarantees thread safety and unambiguity:

Code example:

final class Logger {
    static let shared = Logger()
    private init() {}

    func log(_ message: String) {
        print(message)
    }
}

Logger.shared.log("Example of Singleton working")

Key features:

Using static let ensures thread safety (created once)
private init() prevents direct instantiation
Has global visibility

Tricky Questions.

Is it always appropriate to use singleton for any application services?

No. Singleton is justified for truly global state (e.g., ApplicationSettings), but using it for business logic services is incorrect: it leads to tight coupling and unit testing issues.

Does static let provide thread-safe initialization for Singleton in Swift?

Yes, starting from Swift 1.2 (and due to runtime architecture), static let is thread-safe by nature — it is initialized only once even in the presence of thread contention.

Can a singleton be inherited?

No. It is better to declare the class as final to avoid inheritance — otherwise, it is possible to create two instances of singletons from different derived classes, which breaks the very idea of the pattern.

Common Mistakes and Anti-patterns

Using singleton for everything, leading to poor architecture
Violating data encapsulation in a singleton
Implicit initialization not via static let, creating singletons manually

Real-life Example

Negative Case

A network service implemented as a singleton, and the methods use global state. In unit tests, there is an implicit dependency, making it impossible to reuse the service.

Pros:

Easy integration, quick setup

Cons:

No testability, hard to maintain, 'magical' dependencies

Positive Case

Singleton is used only for a truly-global entity — for example, ApplicationConfig. All services receive dependencies through a clear injector.