Creational Design Patterns

The Singleton is one of the most well-known—and heavily debated—creational design patterns in software engineering. Apple uses it extensively throughout the iOS SDK (UserDefaults.standard, URLSession.shared, NotificationCenter.default), which often leads developers to believe it should be used everywhere. However, while Singletons are incredibly easy to create in Swift, they are equally easy to abuse. In this post, we will explore what the Singleton pattern is, why and how to implement it, where it makes sense, and most importantly, where you should avoid it. ...

As your application grows, the way you create and manage objects becomes just as important as how those objects behave. If your code is littered with complex initialization logic or massive switch statements deciding which object to create, you are likely creating tightly coupled, fragile code. Enter the Factory Method pattern. This creational design pattern provides an interface for creating objects, but delegates the exact type of object being created to a dedicated “factory.” In modern Swift, this pattern is often implemented using protocols and static methods, keeping our business logic incredibly clean. ...

The Builder Pattern is a creational design pattern designed to separate the construction of a complex object from its representation. In classic Gang of Four (GoF) object-oriented languages like Java, the Builder is essential for avoiding the “telescoping constructor” anti-pattern (where you have a dozen different initializers for every combination of parameters). However, in modern Swift, the classic Builder pattern is often redundant. Swift’s native features—like named parameters, default values, and structs—solve the telescoping constructor problem out of the box. Therefore, when we use the Builder pattern in Swift today, it usually takes on one of three highly optimized, modern forms. ...