Singleton

Ensures a class has only one instance and provides a global access point to it.

The Problem

Some resources — database connections, configuration, caches — should exist only once. Without Singleton, calling `new Manager()` in multiple places creates separate instances that can get out of sync.

How It Works

›Only one instance exists for the entire application lifetime
›Lazy initialization: the instance is created on first access
›Thread safety is required in concurrent environments — use dispatch queues or synchronized blocks
›Difficult to unit-test because it carries global state across tests
›Prefer dependency injection over Singleton where testability matters

When to Use

✓Shared resources like a database connection, logger, or analytics tracker

✓Configuration managers that should read settings only once

✓In-memory cache shared across the whole app

✓Hardware interface wrappers (serial port, Bluetooth manager)

Real-World Examples

🍎

iOS

URLSession.shared, UserDefaults.standard, NotificationCenter.default

🤖

Android

Room database instance, Retrofit client, SharedPreferences

🌐

Web

Database connection pool, logger instance, event bus

Code Examples

Swift

final class AppSettings {
    static let shared = AppSettings()
    private init() {}   // prevents external instantiation

    var theme: String = "light"
    var language: String = "en"
}

// Usage — always the same instance
AppSettings.shared.theme = "dark"
print(AppSettings.shared.theme) // "dark"

// Real-world equivalents:
// URLSession.shared
// UserDefaults.standard
// NotificationCenter.default