Why Protocols Change Everything

Swift is not an object-oriented language at heart. It is a protocol-oriented one. Apple said this at WWDC 2015 and then proceeded to build SwiftUI, Combine, and the entire standard library around it.

Understanding protocols is the difference between writing code that works and writing code that scales, composes, and stays testable as your app grows.

What Is a Protocol?

A protocol defines a contract. It says: “Any type that conforms to me must provide these properties and methods.” It says nothing about how they’re implemented.

protocol Greetable {
    var name: String { get }
    func greet() -> String
}

Any struct, class, or enum can conform:

struct User: Greetable {
    var name: String

    func greet() -> String {
        "Hello, I'm \(name)"
    }
}

struct Bot: Greetable {
    var name: String
    func greet() -> String {
        "BEEP. I AM \(name.uppercased()). BOOP."
    }
}

Both types are Greetable. Both implement greet() differently. Code that accepts a Greetable works with either, without knowing which one it has.

Protocol Properties

Protocols specify whether a property must be gettable, settable, or both.

protocol Vehicle {
    var speed: Double { get }        // read-only minimum requirement
    var fuelLevel: Double { get set } // must be read-write
    var description: String { get }
}

A conforming type can satisfy { get } with either a stored property or a computed one. It must satisfy { get set } with a mutable stored property.

struct Car: Vehicle {
    var speed: Double          // stored — satisfies { get }
    var fuelLevel: Double      // stored — satisfies { get set }

    var description: String {  // computed - also satisfies { get }
        "Car going \(speed) km/h"
    }
}

Default Implementations with Extensions

Protocol extensions let you provide default behavior. Conforming types get it for free and can override it if needed.

protocol Describable {
    var name: String { get }
    func describe() -> String
}

extension Describable {
    func describe() -> String {
        "I am \(name)"  // default implementation
    }
}
struct Product: Describable {
    var name: String
    // describe() is provided automatically
}
struct SpecialProduct: Describable {
    var name: String
    func describe() -> String {
        "Special: \(name)"  // overrides the default
    }
}
print(Product(name: "Laptop").describe())         // I am Laptop
print(SpecialProduct(name: "Laptop").describe())  // Special: Laptop

This is one of the most powerful patterns in Swift. Add behavior to a protocol once and every conforming type benefits. No inheritance required.

Protocol Composition

A type can conform to multiple protocols. You can also require multiple protocols at once using &.

protocol Flyable {
    func fly()
}

protocol Swimmable {
    func swim()
}
struct Duck: Flyable, Swimmable {
    func fly() { print("Flap flap") }
    func swim() { print("Splash splash") }
}
func demonstrate(_ animal: Flyable & Swimmable) {
    animal.fly()
    animal.swim()
}
demonstrate(Duck())

This is composition over inheritance. Instead of building a class hierarchy to represent a flying, swimming animal, you compose behaviors from focused protocols. Adding a Walkable protocol later doesn't require restructuring anything.

Using Protocols as Types

Protocols are first-class types. You can use them as parameter types, return types, and stored properties.

protocol Shape {
    var area: Double { get }
}

struct Circle: Shape {
    var radius: Double
    var area: Double { .pi * radius * radius }
}
struct Rectangle: Shape {
    var width: Double
    var height: Double
    var area: Double { width * height }
}
func totalArea(of shapes: [Shape]) -> Double {
    shapes.reduce(0) { $0 + $1.area }
}
let shapes: [Shape] = [Circle(radius: 5), Rectangle(width: 4, height: 6)]
print(totalArea(of: shapes))  // 102.53...

The function doesn’t know or care whether each shape is a Circle or Rectangle. It just knows they're Shape. This is polymorphism without inheritance.

Equatable, Comparable, Hashable: The Standard Protocols

Swift’s standard library is built on protocols. Three you’ll use constantly:

struct User: Equatable, Comparable, Hashable {
    let id: String
    var name: String

// Equatable - compiler synthesizes == for you if all properties are Equatable
    // Hashable - compiler synthesizes hash(into:) for you
    // Comparable - you provide this one
    static func < (lhs: User, rhs: User) -> Bool {
        lhs.name < rhs.name
    }
}
let users = [User(id: "2", name: "Riya"), User(id: "1", name: "Aryan")]
let sorted = users.sorted()  // sorted by name because of Comparable
let set = Set(users)         // works because of Hashable
let isEqual = users[0] == users[1]  // works because of Equatable

Conform to these and your type plugs into the entire Swift ecosystem: sorting, sets, dictionaries, diffing, and more.

Codable: The Protocol That Replaced Boilerplate

Codable is Encodable & Decodable. Conform to it and Swift synthesizes JSON encoding and decoding automatically.

struct Article: Codable {
    let id: Int
    let title: String
    let publishedAt: Date
    let tags: [String]
}

let json = """
{
    "id": 1,
    "title": "Swift Protocols",
    "publishedAt": "2025-08-14T10:00:00Z",
    "tags": ["swift", "ios"]
}
""".data(using: .utf8)!
let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601
let article = try decoder.decode(Article.self, from: json)
print(article.title)  // Swift Protocols

Three lines to decode a full JSON object into a typed Swift struct. No manual mapping, no stringly-typed dictionary access, no runtime surprises.

Protocol-Oriented Programming in Practice

The real power shows up in architecture. Here is a testable network layer built entirely on protocols:

protocol NetworkService {
    func fetch<T: Decodable>(endpoint: String) async throws -> T
}

// Production implementation
struct LiveNetworkService: NetworkService {
    func fetch<T: Decodable>(endpoint: String) async throws -> T {
        let url = URL(string: "https://api.myapp.com" + endpoint)!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode(T.self, from: data)
    }
}
// Test implementation - no network required
struct MockNetworkService: NetworkService {
    var mockData: Data
    func fetch<T: Decodable>(endpoint: String) async throws -> T {
        try JSONDecoder().decode(T.self, from: mockData)
    }
}
// ViewModel accepts the protocol, not the concrete type
class UserViewModel {
    private let network: NetworkService
    init(network: NetworkService = LiveNetworkService()) {
        self.network = network
    }
}

In production: inject LiveNetworkService. In tests: inject MockNetworkService. The view model never knows the difference. This is dependency injection via protocols and it is how testable iOS apps are built.

Interview Questions

Q: What is a protocol in Swift and how does it differ from inheritance?

A protocol defines a contract: a set of requirements any conforming type must satisfy. Inheritance copies behavior from a parent class to a child class. Protocols enable composition: a type can conform to many protocols simultaneously, each adding focused capabilities. Unlike inheritance, protocols work with structs and enums, not just classes. Swift favors protocols because they are more flexible, more testable, and avoid the fragile base class problems that deep inheritance hierarchies create.

Q: What is a default implementation in a protocol extension and why is it useful?

A default implementation is behavior provided in a protocol extension that conforming types automatically inherit without writing any code. It is useful because it lets you add shared behavior to all conforming types at once, allows new protocol requirements to be added without breaking existing conformances, and removes the need for a base class just to share implementation. Conforming types can override the default when they need different behavior.

Summary

• A protocol defines a contract: required properties and methods without implementation.
• Any struct, class, or enum can conform to a protocol.
• Protocol extensions provide default implementations that conforming types inherit for free.
• Protocol composition with & lets functions require multiple capabilities at once.
• Protocols as types enable polymorphism without inheritance.
• Equatable, Comparable, Hashable, and Codable are foundational standard library protocols.
• Protocol-oriented programming powers testable architecture through dependency injection.
• Swift’s standard library, SwiftUI, and Combine are all built on this pattern.

Practice

1. Beginner: Define a Printable protocol with a prettyPrint() method. Create three types that conform to it: Invoice, Receipt, and ShippingLabel. Add a default implementation that prints the type name, then override it meaningfully for each type.
2. Intermediate: Build a Cacheable protocol with var cacheKey: String { get } and var expiresAfter: TimeInterval { get }. Add a default expiresAfter of 300 seconds via a protocol extension. Conform User, Product, and Article structs to it with different cache keys.
3. Advanced: Create a Repository<T> protocol with fetch(id: String) async throws -> T, save(_ item: T) async throws, and delete(id: String) async throws. Build a InMemoryRepository<T> struct that conforms to it using a dictionary. Then create a UserService that depends on any Repository<User> and write a test using the in-memory version without touching a network or database.

What’s Next

Article 13: Swift Extensions: Adding Behavior Without Subclassing

Protocols define what a type can do. Extensions define what it already does, retroactively. You can extend any type in Swift, including ones from Apple’s frameworks, and add computed properties, methods, and protocol conformances without touching the original source. It is one of the cleanest features in the language.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If protocol-oriented programming clicked today, tap 👏 up to 50 times. It helps this series reach developers still building class hierarchies that should be protocol compositions.

Follow me so Article 13 lands in your feed automatically. Extensions are next and they make every type in the language feel like yours.

See you in the next one. 🚀

Why Optionals Exist

In most languages, any variable can be null at any time. You find out at runtime, usually as a crash. Swift takes a different approach: if a value can be absent, you must say so explicitly. The compiler then refuses to let you use it as if it were definitely there.

That one rule eliminates an entire category of bugs before your app ever runs.

What Is an Optional?

An optional is a type that wraps another type and adds the possibility of absence.

var name: String = "Aryan"   // must have a value
var nickname: String? = nil  // may or may not have a value

The ? after a type is syntactic sugar for Optional<String>. Under the hood, Optional is just an enum:

enum Optional<Wrapped> {
    case some(Wrapped)
    case none
}

When you write String?, you get a type that is either .some("Aryan") or .none. That's all an optional is. Everything else follows from this.

Forced Unwrapping: The Dangerous Shortcut

The ! operator extracts the value from an optional. If the optional is nil, it crashes.

var username: String? = "aryan_dev"
print(username!)  // "aryan_dev"

var empty: String? = nil
print(empty!)     // 💥 Fatal error: unexpectedly found nil

Forced unwrapping has its place. It should never be your default. Every ! in production code is a promise that this value will never be nil here. If that promise breaks, your app crashes.

Rule: Treat ! like a comment that says "I guarantee this is never nil." If you can't honestly say that, don't use it.

Optional Binding: The Right Way

if let safely unwraps an optional. If it has a value, you get it. If not, you take the else branch.

var username: String? = "aryan_dev"

if let name = username {
    print("Hello, \(name)")  // name is String here, not String?
} else {
    print("No username set")
}

Swift 5.7 shorthand when the variable name stays the same:

if let username {
    print("Hello, \(username)")
}

For functions with multiple optional preconditions, guard let keeps the code flat:

func processOrder(userID: String?, productID: String?, quantity: Int?) {
    guard let userID else { return }
    guard let productID else { return }
    guard let quantity, quantity > 0 else { return }
 
   // All three are safely unwrapped here
    placeOrder(user: userID, product: productID, qty: quantity)
}

This pattern eliminates the pyramid of nested if let blocks that plagues code written by developers still figuring out optionals.

Nil Coalescing: Provide a Default

The ?? operator returns the unwrapped value if it exists, or a default if it doesn't.

var displayName: String? = nil
let name = displayName ?? "Guest"
print(name)  // "Guest"

Chain it for multiple fallbacks:

let name = firstName ?? lastName ?? username ?? "Anonymous"

Use this for simple fallback logic. For complex branching, if let or guard let is clearer.

Optional Chaining: Navigate Safely

The ?. operator calls a method or accesses a property on an optional. If the optional is nil, the whole expression returns nil instead of crashing.

struct Address {
    var city: String
}

struct User {
    var address: Address?
}

var user: User? = User(address: Address(city: "Mumbai"))
print(user?.address?.city)  // Optional("Mumbai")
print(user?.address?.city.uppercased())  // Optional("MUMBAI")
user = nil
print(user?.address?.city)  // nil - no crash

The result of an optional chain is always optional. If anything in the chain is nil, the whole thing short-circuits to nil.

Combine with ?? to get a non-optional result:

let city = user?.address?.city ?? "Unknown city"

map and flatMap on Optionals

Optionals have functional methods too. This surprises most developers.

let input: String? = "42"

// map transforms the wrapped value if it exists
let doubled = input.map { Int($0) }
// Returns Optional<Optional<Int>> - nested optionals
// flatMap flattens the result
let number = input.flatMap { Int($0) }
// Returns Optional<Int> - cleaner

flatMap is especially useful when a transformation itself returns an optional:

let userIDString: String? = "123"
let userID: Int? = userIDString.flatMap { Int($0) }

One line. Safe. No forced unwrapping. This is how functional Swift handles optional transformations.

Implicitly Unwrapped Optionals

Declared with ! instead of ?. Behave like regular values but crash if nil.

var label: UILabel!  // implicitly unwrapped

Use this only when a value is guaranteed to be set before first use but cannot be set in init. IBOutlets are the canonical example. UIKit sets them after init but before viewDidLoad, so the guarantee holds.

Outside of IBOutlets and a handful of UIKit patterns, avoid them. They trade safety for convenience, and the convenience rarely outweighs the risk.

Optional in Switch

Because optionals are enums, you can switch on them directly:

let score: Int? = 85

switch score {
case .some(let value) where value >= 90:
    print("A")
case .some(let value) where value >= 80:
    print("B")
case .some(let value):
    print("C or below: \(value)")
case .none:
    print("No score recorded")
}

Or use the shorthand case let value? syntax:

switch score {
case let value? where value >= 90:
    print("A: \(value)")
case let value?:
    print("Score: \(value)")
case nil:
    print("No score")
}

Real-World Pattern: Decoding Optional API Fields

struct Product: Decodable {
    let id: String
    let name: String
    let description: String?   // not always returned by API
    let discountPrice: Double? // only present during sales
    let imageURL: URL?
}

func display(_ product: Product) {
    let desc = product.description ?? "No description available"
    let price = product.discountPrice.map { "Sale: $\($0)" } ?? "Full price"
    let image = product.imageURL ?? URL(string: "https://cdn.myapp.com/placeholder.png")!
    print(desc)
    print(price)
}

Optionals here aren’t just syntax. They’re documentation. Any engineer reading this struct immediately knows which fields the API might omit.

Interview Questions

Q: What is an optional in Swift and how does it work under the hood?

An optional is a generic enum with two cases: .some(Wrapped) and .none. The ? syntax is shorthand for Optional<T>. When a variable is declared as String?, the compiler wraps it in this enum. Using the value directly without unwrapping is a compile-time error. This design means nil-related bugs are caught before the app runs, not during user sessions.

Q: What is the difference between if let, guard let, and ?? for handling optionals?

if let unwraps an optional inside a block. The unwrapped value is only available inside that block. guard let unwraps at the top of a scope and exits if nil. The unwrapped value is available for the rest of the function. ?? provides an inline default value when the optional is nil. Use if let for optional branches, guard let for preconditions, and ?? for simple fallback values.

Summary

• An optional is Optional<T>: either .some(value) or .none.
• Forced unwrapping with ! crashes at runtime if the value is nil. Use it only when you can guarantee the value exists.
• if let safely unwraps inside a block. guard let unwraps and exits early if nil.
• ?? provides a default value inline when an optional is nil.
• Optional chaining with ?. short-circuits to nil instead of crashing.
• map transforms an optional's value. flatMap handles transformations that return optionals.
• Implicitly unwrapped optionals (!) are for IBOutlets and UIKit patterns only.
• Optionals are enums, so you can use switch pattern matching on them directly.

Practice

Beginner: Write a function greet(name: String?) -> String that returns "Hello, [name]!" if name exists and "Hello, stranger!" if it doesn't. Implement it three ways: forced unwrap, if let, and ??. Explain which you'd use in production and why.

Intermediate: Given this struct:

struct Order {
    var user: User?
    var shippingAddress: Address?
    var promoCode: String?
}

Write a function summarize(_ order: Order) -> String using optional chaining and ?? to produce a readable summary without any forced unwraps or crashes, regardless of which fields are nil.

Advanced: Implement a safeSubscript extension on Array that returns an optional instead of crashing on out-of-bounds access:

extension Array {
    subscript(safe index: Int) -> Element? { ... }
}

Then use flatMap to safely extract and transform values from an array of optionals without any force unwraps.

What’s Next

Article 12: Swift Protocols: Contracts, Conformance, and the Power of Protocol-Oriented Programming

Optionals showed you how Swift uses the type system to enforce safety. Protocols take that further. They define contracts that any type can fulfill, enabling one of Swift’s most powerful architectural patterns: protocol-oriented programming. It’s the reason Swift code composes so cleanly.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If optionals finally make sense as a safety system rather than just syntax, tap 👏 up to 50 times and do 🔁. It helps this series reach developers still scattering ! across their codebase.

Follow me so Article 12 lands in your feed automatically. Protocols are next and they will change how you architect everything.

See you in the next one. 🚀

Why Enums Are Bigger Than You Think

Every tutorial introduces enums as a fancy list of named values. That framing undersells them completely.

Swift enums can carry data. They can have methods. They can conform to protocols. They work as the backbone of error handling, network state, navigation routing, and API response modeling. Once you see what they can actually do, you’ll find yourself reaching for them constantly.

The Basics

An enum defines a type with a fixed set of cases.

enum Direction {
    case north
    case south
    case east
    case west
}

var heading = Direction.north
heading = .west  // Swift infers the type after first assignment

The dot syntax after first assignment is a small thing that makes call sites read cleanly.

Raw Values

Attach a primitive value to each case.

enum Planet: Int {
    case mercury = 1
    case venus
    case earth
    case mars
}

print(Planet.earth.rawValue)  // 3 - auto-increments from 1
// Initialize from a raw value - returns Optional because it can fail
let planet = Planet(rawValue: 2)  // Optional<Planet> - venus
let unknown = Planet(rawValue: 99)  // nil

String raw values are common for API mapping:

enum UserRole: String {
    case admin = "ADMIN"
    case editor = "EDITOR"
    case viewer = "VIEWER"
}

// Decode directly from an API response string
let role = UserRole(rawValue: "EDITOR")  // .editor

This pattern eliminates strongly-typed comparisons like if role == "ADMIN" scattered across your codebase.

Associated Values: The Game Changer

Each case can carry its own data. Different cases can carry different types.

enum PaymentMethod {
    case creditCard(number: String, expiry: String)
    case bankTransfer(accountID: String, routingNumber: String)
    case applePay
    case cash
}

let method = PaymentMethod.creditCard(number: "4111111111111111", expiry: "12/26")

No struct needed. The data lives inside the case itself.

Extract the values with pattern matching in a switch:

switch method {
case .creditCard(let number, let expiry):
    print("Card ending \(number.suffix(4)), expires \(expiry)")
case .bankTransfer(let account, _):
    print("Bank transfer from account \(account)")
case .applePay:
    print("Apple Pay")
case .cash:
    print("Cash payment")
}

The compiler forces you to handle every case. Miss one and it won’t build. That exhaustiveness is a feature, not a constraint.

Modeling State with Enums

This is where enums go from useful to indispensable. Consider a network request that can be in one of several states:

enum LoadingState<T> {
    case idle
    case loading
    case loaded(data: T)
    case failed(error: Error)
}

Now your view model holds exactly one value of this type instead of three separate booleans and an optional:

// Before — fragile, easy to get into impossible states
var isLoading = false
var data: [User]?
var error: Error?

// After - only valid states are representable
var state: LoadingState<[User]> = .idle

A state where isLoading is true AND error is set? Not possible with the enum. This is called making invalid states unrepresentable and it's one of the most valuable design principles in Swift.

Enums with Methods and Computed Properties

Enums aren’t just data containers. They can have behavior too.

enum Suit: String, CaseIterable {
    case hearts = "♥"
    case diamonds = "♦"
    case clubs = "♣"
    case spades = "♠"

    var isRed: Bool {
        self == .hearts || self == .diamonds
    }

    func label() -> String {
        "\(rawValue) (\(isRed ? "red" : "black"))"
    }
}

print(Suit.hearts.label())     // ♥ (red)
print(Suit.allCases.count)     // 4 - CaseIterable gives you this for free

CaseIterable synthesizes an allCases array automatically. Useful for populating pickers, iterating every case in tests, or building menus.

Indirect Enums: Recursive Structures

For tree structures and recursive data, mark the enum indirect:

indirect enum TreeNode {
    case leaf(value: Int)
    case branch(left: TreeNode, right: TreeNode)
}

let tree = TreeNode.branch(
    left: .leaf(value: 3),
    right: .branch(
        left: .leaf(value: 7),
        right: .leaf(value: 12)
    )
)

Without indirect, the compiler can't determine the size of the type at compile time. The keyword tells it to store associated values on the heap instead.

Real-World Pattern: API Error Modeling

enum APIError: Error {
    case unauthorized
    case notFound(resource: String)
    case rateLimited(retryAfter: TimeInterval)
    case serverError(code: Int, message: String)
    case networkUnavailable
}

func handle(_ error: APIError) {
    switch error {
    case .unauthorized:
        redirectToLogin()
    case .notFound(let resource):
        showAlert("Could not find \(resource)")
    case .rateLimited(let seconds):
        scheduleRetry(after: seconds)
    case .serverError(let code, let message):
        logError(code: code, message: message)
    case .networkUnavailable:
        showOfflineBanner()
    }
}

Each error case carries exactly the data it needs. The switch handles all of them. No strongly-typed error messages, no integer error codes compared with magic numbers, no optional unwrapping chains.

Interview Questions

Q: What is the difference between raw values and associated values in Swift enums?

Raw values are fixed primitive values attached to each case at definition time. Every case of the same enum has the same type. Associated values are dynamic data attached when you create a case. Different cases can carry different types and different amounts of data. Raw values are set in the enum definition; associated values are set at the call site.

Q: What does “making invalid states unrepresentable” mean?

It means structuring your types so the compiler physically cannot represent a state that shouldn’t exist in your app. A classic example: replacing isLoading: Bool, data: T?, and error: Error? with a single LoadingState<T> enum. With three separate booleans, you can accidentally set isLoading = true and error = someError simultaneously. With the enum, only one state exists at a time. The compiler enforces it.

Summary

• Enums define a type with a fixed, exhaustive set of cases.
• Raw values attach a primitive to each case at definition time, useful for API mapping.
• Associated values let each case carry its own data, with different types per case.
• Swift’s switch is exhaustive on enums: every case must be handled or it won’t compile.
• Enums can have methods, computed properties, and protocol conformances.
• CaseIterable gives you an allCases array for free.
• indirect enables recursive enum structures like trees.
• Modeling state with enums makes invalid states unrepresentable at the type level.

Practice

1. Beginner: Create a Season enum with four cases. Add a computed property isWarm: Bool and a description: String that returns a short sentence about each season. Iterate all cases using CaseIterable and print the descriptions.
2. Intermediate: Model a Notification enum with cases for message(from: String, text: String), friendRequest(from: String), paymentReceived(amount: Double, currency: String), and systemAlert(title: String). Write a function that takes a Notification and returns the string to display in a push notification banner.
3. Advanced: Build a Result<Success, Failure: Error> type from scratch as a custom enum (don't use Swift's built-in). Add a map method that transforms the success value, a mapError method that transforms the failure, and a get() throwing method that returns the success value or throws the error. Then explain why Swift's standard library already provides this and when you'd use your own instead.

What’s Next

Article 11: Swift Optionals: nil, Unwrapping, and the Safety System Behind the ?

Enums taught you how Swift models “this case or that case.” Optionals are built on exactly the same mechanism: a value is either .some(wrapped) or .none. Understanding optionals at that level changes how you read and write Swift forever.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If associated values just opened up new ways to model your data, tap 👏 up to 50 times and repost 🔁. It helps this series reach developers who are still using strongly state.

Follow me so Article 11 lands in your feed automatically. Optionals are next, and there is a lot more to them than the ? symbol suggests.

See you in the next one. 🚀

Why Classes Still Matter

Structs are Swift’s default. But open any UIKit file and you’re in class territory immediately. UIViewController, UIView, URLSession, NotificationCenter all classes. Understanding why these aren't structs is what makes you a better architect, not just a better syntax writer.

What Is a Class in Swift?

A class is a reference type a blueprint that lives on the heap. When you create an instance, Swift allocates memory for it and hands you a reference (a pointer) to that memory. Every variable that “holds” the class instance actually holds a pointer to the same object.

class Vehicle {
    var make: String
    var speed: Double

    init(make: String, speed: Double) {
        self.make = make
        self.speed = speed
    }

    func describe() -> String {
        "\(make) going \(speed) km/h"
    }
}

let car = Vehicle(make: "Tesla", speed: 120)
print(car.describe())  // Tesla going 120 km/h

Unlike structs, classes don’t get a free member wise initializer. You write init yourself.

Reference Semantics in Practice

This is the single most important thing to understand about classes.

var car1 = Vehicle(make: "Tesla", speed: 100)
var car2 = car1       // car2 is NOT a copy — it's the same object

car2.speed = 200
print(car1.speed)  // 200 - car1 changed too
print(car2.speed)  // 200

Both car1 and car2 point to the same Vehicle in memory. Changing one changes both. This isn't a bug it's the feature. Sometimes you want shared mutable state. A music player's AudioSession, a user's AuthManager, a network layer's URLSessionthese should exist once and be shared everywhere.

That’s exactly when a class earns its place.

Inheritance Extending Behavior Without Rewriting It

Classes support inheritance. A subclass gets all the properties and methods of its parent and can override or extend them.

class Animal {
    var name: String

    init(name: String) {
        self.name = name
    }

    func sound() -> String {
        "..."
    }
}

class Dog: Animal {
    override func sound() -> String {
        "Woof"
    }

    func fetch() {
        print("\(name) fetches the ball!")
    }
}

let dog = Dog(name: "Bruno")
print(dog.sound())   // Woof
dog.fetch()          // Bruno fetches the ball!

The override keyword is required the compiler enforces it. You can't accidentally override a method. You have to mean it.

final Preventing Further Subclassing

final class PaymentProcessor {
    // No one can subclass this
}

Mark a class final when subclassing would break its invariants or when you want the compiler to enable direct method dispatch (faster than dynamic dispatch). Apple marks many of their classes final for exactly this reason.

deinit Cleanup When an Object Dies

Classes have a deinitializer that runs automatically when the last reference is released.

class DatabaseConnection {
    let connectionID: String

    init(id: String) {
        self.connectionID = id
        print("Connection \(id) opened")
    }

    deinit {
        print("Connection \(connectionID) closed")
        // Close socket, release file handles, cancel timers
    }
}

var conn: DatabaseConnection? = DatabaseConnection(id: "db_001")
// prints: Connection db_001 opened
conn = nil
// prints: Connection db_001 closed - deinit fired automatically

Structs don’t have deinit. If you need guaranteed cleanup file handles, network sockets, observers, timers you need a class.

How ARC Manages Class Memory

Swift uses Automatic Reference Counting to track how many references point to each class instance. When the count hits zero, deinit runs and the memory is freed.

var a: Vehicle? = Vehicle(make: "BMW",
                         speed: 80)  // ref count: 1
var b = a                            // ref count: 2
a = nil                              // ref count: 1
b = nil                              // ref count: 0 → deinit fires

This is automatic you don’t call free() or delete. But ARC isn't free of footguns. Retain cycles (covered in Article 7 on closures) can keep the count above zero permanently, leaking the object forever. Classes require more discipline than structs precisely because of this.

Class Properties: static vs class

Both belong to the type, not an instance. The difference is overridability.

class Shape {
    static var defaultColor = "black"   // cannot be overridden
    class var description: String {     // can be overridden by subclasses
        "A generic shape"
    }
}

class Circle: Shape {
    override class var description: String {
        "A circle"
    }
}

print(Shape.description)   // A generic shape
print(Circle.description)  // A circle

Use static when the value should never change per subclass. Use class when subclasses should be able to customize it.

Real-World Pattern: Singleton Service

The most common class-specific pattern in iOS:

final class AnalyticsService {
    static let shared = AnalyticsService()

    private init() {}  // Prevents external instantiation

    func track(event: String, properties: [String: Any] = [:]) {
        // Send to analytics backend
        print("Event: \(event), props: \(properties)")
    }
}

// Usage anywhere in the app
AnalyticsService.shared.track(event: "user_login")

One instance, shared across the entire app. This only makes sense as a class a struct would give every call site its own copy, which defeats the purpose entirely.

Classes vs Structs: The Real Decision Framework

Question Answer → Does this model data? Struct Does multiple code share the same instance? Class Do you need inheritance? Class Do you need deinit for cleanup? Class Should copies be independent? Struct Is this a UIKit component? Class (UIKit requires it) Is this a SwiftUI view? Struct (SwiftUI requires it)

When in doubt, start with a struct. The compiler will tell you when you actually need a class.

Interview Questions

Q: What is a class in Swift and how does it differ from a struct?

A class is a reference type instances live on the heap and multiple variables can share the same object. Structs are value types each assignment creates an independent copy. Classes support inheritance and deinit; structs don't. Classes are managed by ARC and can form retain cycles; structs are stack-allocated (generally) and don't have this risk.

Q: When would you choose a class over a struct?

Choose a class when you need shared mutable state across multiple parts of the app, when you need deinit for resource cleanup, when you're subclassing (UIKit, for example), or when identity matters two references must point to the exact same instance. Everything else defaults to a struct.

Summary

• Classes are reference types assignment shares the object, not a copy.
• Unlike structs, classes require you to write init manually.
• Subclasses inherit all properties and methods; override is required and enforced.
• final prevents subclassing and enables faster method dispatch.
• deinit runs when ARC drops the reference count to zero use it for resource cleanup.
• static properties can't be overridden; class properties can.
• Singletons are the canonical class pattern one shared instance for services.
• Default to structs. Reach for classes when you have a specific reason.

Practice

1. Beginner: Create a BankAccount class with owner: String, balance: Double, and init. Add deposit() and withdraw() methods. Create two variables pointing to the same account and show that a deposit on one is reflected in the other.
2. Intermediate: Build a Logger singleton that stores an in-memory array of log entries (strings). Add log(_ message: String) and clearLogs() methods. Use deinit to print a message showing when the logger would be released then explain why in practice it never fires for a singleton.
3. Advanced: Create a MediaPlayer class with a delegate protocol for playback events. Use a weak delegate reference to avoid a retain cycle. Implement play(), pause(), and stop() and have them notify the delegate. Explain in a comment why the delegate must be weak and what would happen if it weren't.

What’s Next

Article 10: Swift Enums — Associated Values, Raw Values, and Pattern Matching

Enums in Swift are nothing like enums in other languages. They carry data, conform to protocols, have methods, and work as the backbone of Swift’s error handling and state modeling. One of the most powerful features in the entire language and most developers use only 10% of what they can do.

If the struct vs class decision finally clicked, tap 👏 up to 50 times and do re-post 🔁, it directly helps this series reach developers still confused by reference types.

Follow me so Article 10 lands in your feed the moment it’s live. Enums are coming and they’re going to surprise you.

See you in the next one. 🚀

What looks like a simple data container is actually Swift’s most powerful tool for writing safe, predictable, performant code.

Why This Is One of the Most Important Topics in Swift

Apple’s own frameworks are built predominantly with structs. SwiftUI.View is a struct. CGRect is a struct. URL is a struct. Array, Dictionary, String all structs.

This isn’t an accident. It’s a deliberate architectural choice. Understanding why changes how you design every model, every data layer, and every piece of state in your app.

What Is a Struct?

A struct is a value type that groups related data and behavior together.

struct User {
    let id: String
    var name: String
    var age: Int
}

let user = User(id: "usr_001", name: "Aryan", age: 28)
print(user.name)  // Aryan

Swift automatically generates a member-wise initializer you get init(id:name:age:) for free, no code needed.

The Core Idea: Value Semantics

This is what makes structs fundamentally different from classes.

var original = User(id: "usr_001", name: "Aryan", age: 28)
var copy = original   // copy gets its own independent copy

copy.name = "Riya"
print(original.name)  // "Aryan" - completely unaffected
print(copy.name)      // "Riya"

When you assign a struct, you get a real copy. Changing one never affects the other. This is called value semantics and it eliminates an entire class of bugs.

Compare this to a class:

class UserClass {
    var name: String
    init(name: String) { self.name = name }
}

var original = UserClass(name: "Aryan")
var copy = original   // both point to the SAME object

copy.name = "Riya"
print(original.name)  // "Riya" - original was changed too

With a class, copy is not a copy. It's another reference to the same object. Shared mutable state is the source of some of the hardest bugs in iOS development.

Mutating Methods

Struct methods cannot modify properties by default. You must mark them mutating:

struct Counter {
    var count = 0
    mutating func increment() {
        count += 1
    }
    mutating func reset() {
        count = 0
    }
}

var counter = Counter()
counter.increment()
counter.increment()
print(counter.count)  // 2

The mutating keyword is a contract it signals to every reader: "this method changes state." It also enforces that you cannot call it on a let constant:

let fixedCounter = Counter()
fixedCounter.increment()  // ❌ Cannot use mutating member on immutable value

The compiler catches this at build time. No crash. No runtime surprise.

Computed Properties

Structs can have properties that compute their value on demand:

struct Rectangle {
    var width: Double
    var height: Double
    // Computed - no stored value, calculated each time
    var area: Double {
        width * height
    }
    var isSquare: Bool {
        width == height
    }
}

let rect = Rectangle(width: 10, height: 5)
print(rect.area)      // 50.0
print(rect.isSquare)  // false

Computed properties look like stored properties at the call site clean, no method call syntax needed.

Property Observers

React to property changes with willSet and didSet:

struct StepTracker {
    var steps: Int = 0 {
        didSet {
            if steps > 10_000 {
                print("Goal reached! 🎉")
            }
        }
    }
}

var tracker = StepTracker()
tracker.steps = 10_500  // prints: Goal reached! 🎉

Production use: didSet is how you trigger side effects when data changes logging, validation, UI updates in UIKit models.

Static Properties and Methods

Belong to the type itself, not any instance:

struct AppConfig {
    static let version = "2.1.0"
    static let maxRetries = 3
    static let baseURL = "https://api.myapp.com"
    static func buildURL(endpoint: String) -> String {
        baseURL + endpoint
    }
}

print(AppConfig.version)                        // "2.1.0"
print(AppConfig.buildURL(endpoint: "/users"))   // "https://api.myapp.com/users"

No instance needed. Perfect for configuration, constants, and utility functions.

Structs vs Classes When to Use Which

This comes up in every iOS interview. Here’s the honest answer:

Use a struct when:

• Modeling data (User, Product, Order, APIResponse)
• The value should be independent when copied
• You don’t need inheritance
• You want thread safety by default

Use a class when:

• You need a single shared instance (managers, services)
• You need deinit for cleanup
• You’re working with UIKit (which is class-based)
• Identity matters two references must point to the same thing

Apple’s own guideline: default to structs. Only reach for a class when you have a specific reason.

Real-World Pattern: API Response Model

struct APIResponse<T: Decodable>: Decodable {
    let data: T
    let message: String
    let statusCode: Int
    var isSuccess: Bool {
        statusCode >= 200 && statusCode < 300
    }
}

struct Product: Decodable {
    let id: String
    let name: String
    let price: Double
    let inStock: Bool
}

// Usage
let response: APIResponse<Product> = try JSONDecoder().decode(...)
if response.isSuccess {
    display(response.data)
}

Structs + Decodable is the standard pattern for parsing API responses in production iOS apps. Value semantics means your parsed models are safe to pass across layers without unexpected mutation.

How Swift Optimizes Struct Memory

Swift doesn’t always copy structs immediately. It uses Copy-on-Write (CoW) for collections the copy only happens when you actually mutate the new value.

var array1 = [1, 2, 3, 4, 5]
var array2 = array1   // No copy yet — they share the same buffer
array2.append(6)      // NOW the copy happens - array1 is unaffected

You get value semantics without paying the full copy cost until it’s necessary. This is why passing large arrays around in Swift is cheaper than it looks. (We’ll cover CoW in depth in Phase 3.)

Interview Question

Q: What’s the difference between a struct and a class in Swift, and when would you choose one over the other?

Structs are value types assignment creates an independent copy. Classes are reference types assignment creates another reference to the same object. Structs live on the stack (generally), are thread-safe by default, and don’t support inheritance. Classes live on the heap, support inheritance, and share state across references.

Choose a struct for data models, API responses, and anything where independence on copy is valuable. Choose a class when you need shared state, lifecycle management via deinit, or when interfacing with UIKit. Apple's official guidance: default to structs, and only use a class when you have a concrete reason.

Summary

• Structs are value types every assignment is an independent copy.
• Classes are reference types assignment shares the same object.
• mutating methods signal and enforce state changes on structs.
• Computed properties calculate values on demand clean call site, no method syntax.
• didSet / willSet react to property changes without subclassing.
• Static properties and methods belong to the type, not any instance.
• Default to structs. Use classes when you specifically need reference semantics.
• Swift uses Copy-on-Write copies are deferred until mutation occurs.

Practice

1. Beginner: Create a Temperature struct with a stored property celsius: Double and computed properties fahrenheit and kelvin. Add a mutating func increase(by degrees: Double) method.
2. Intermediate: Model a shopping cart as a struct with an array of CartItem structs. Add mutating methods to add, remove, and clear items, and a computed property for totalPrice. Demonstrate that copying the cart gives you an independent snapshot.
3. Advanced: Create a generic Stack<T> struct with mutating push(), mutating pop(), and a peek computed property. Make it conform to CustomStringConvertible for clean print output. Then explain in a comment why Stack as a struct is safer than Stack as a class in a multi-function codebase.

What’s Next

Article 9: Swift Classes — Reference Types, Inheritance, deinit, and When They Beat Structs

You now know structs deeply. Next: classes when shared identity matters, how inheritance works in Swift, what deinit gives you, and why UIKit is entirely class-based. Understanding both sides of this divide makes you a far more intentional architect.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If structs finally make sense as a design choice not just syntax tap 👏 up to 50 times and do 🔁. It helps this series reach developers making the same struct vs class mistakes every day.

Follow me so Article 9 lands in your feed automatically. Classes build directly on everything you just learned.

See you in the next one. 🫡

Why Closures Are Non-Negotiable

You cannot write real iOS apps without understanding closures. They are the mechanism behind:

• Every completion handler (URLSession, animations, alerts)
• Every SwiftUI body, Button, onTapGesture
• map, filter, sorted, reduce
• DispatchQueue.main.async { }
• async/await under the hood
• Combine publishers and subscribers

If closures feel fuzzy, everything built on top of them feels like magic. Let’s make them obvious.

What Is a Closure?

A closure is a function without a name defined inline, where you need it.

// Named function
func double(_ n: Int) -> Int { n * 2 }

// Same thing as a closure
let double = { (n: Int) -> Int in n * 2 }

// Use them the same way
print(double(5))  // 10

The in keyword separates the parameter list and return type from the body. That's the only structural difference from a function.

Syntax Simplification Step by Step

Swift lets you strip closure syntax down progressively. Each step is valid:

let numbers = [3, 1, 4, 1, 5, 9]

// 1. Full syntax
let sorted = numbers.sorted(by: { (a: Int, b: Int) -> Bool in
    return a < b
})

// 2. Type inference - Swift knows the types from context
let sorted = numbers.sorted(by: { a, b in
    return a < b
})

// 3. Implicit return - single expression closures don't need `return`
let sorted = numbers.sorted(by: { a, b in a < b })

// 4. Shorthand argument names
let sorted = numbers.sorted(by: { $0 < $1 })

// 5. Trailing closure syntax - when the closure is the last argument
let sorted = numbers.sorted { $0 < $1 }

// 6. Operator function - when an operator matches the signature
let sorted = numbers.sorted(by: <)

All six produce identical results. Use the level of verbosity that best communicates intent don’t default to the shortest just to look clever.

Trailing Closure Syntax

When a closure is the last parameter, you can move it outside the parentheses:

// Standard
UIView.animate(withDuration: 0.3, animations: {
    view.alpha = 0
})

// Trailing closure
UIView.animate(withDuration: 0.3) {
    view.alpha = 0
}

If the closure is the only parameter, drop the parentheses entirely:

DispatchQueue.main.async {
    self.tableView.reloadData()
}

You write this pattern dozens of times a day. Now you know why it looks the way it does.

Closures Capture Values

This is the critical concept most tutorials rush past.

A closure captures the variables from its surrounding scope and holds onto them even after that scope ends.

func makeCounter() -> () -> Int {
    var count = 0
    let increment = {
        count += 1
        return count
    }
    return increment
}

let counter = makeCounter()
print(counter())  // 1
print(counter())  // 2
print(counter())  // 3

makeCounter() has returned but count is still alive because the closure captured it. The closure owns a reference to count and keeps it in memory as long as the closure itself exists.

This is powerful. It’s also where memory problems begin.

Retain Cycles: The Closure Trap

When a closure captures self and self holds the closure you have a retain cycle. Neither can be deallocated. Memory leaks.

class VideoPlayer {
    var onComplete: (() -> Void)?

    func play() {
        onComplete = {
            self.reset()  // ❌ self captures onComplete, onComplete captures self
        }
    }

    func reset() { }
}

Fix: Capture lists with [weak self]

func play() {
    onComplete = { [weak self] in
        self?.reset()  // ✅ weak reference — no cycle
    }
}

[weak self] makes the closure's reference to self weak it won't prevent deallocation. Use optional chaining (self?) to safely call methods.

[unowned self] the riskier option

onComplete = { [unowned self] in
    self.reset()  // No optional chaining needed — but crashes if self is nil
}

Use [unowned self] only when you are 100% certain self outlives the closure. If you're not certain, use [weak self]. Always.

Rule: Any closure stored as a property that also references self needs [weak self]. This covers delegates, completion handlers, Combine subscriptions, and timers.

@escaping Closures

By default, closures passed to a function are non-escaping they run during the function call and are discarded.

An escaping closure outlives the function it’s stored and called later.

class DataService {
    var completion: (() -> Void)?  // stored = will outlive the function

    func load(completion: @escaping () -> Void) {
        // Stored for later - must be marked @escaping
        self.completion = completion
        fetchData()
    }

    func fetchData() {
        // ... eventually calls self.completion()
    }
}

Any closure stored in a property, dispatched to another queue, or passed to an async operation must be @escaping. The compiler enforces this if you forget, it tells you.

Real-World Pattern: Completion Handler

func fetchUser(id: String, completion: @escaping (Result<User, Error>) -> Void) {
    URLSession.shared.dataTask(with: userURL(id: id)) { data, _, error in
        if let error = error {
            completion(.failure(error))
            return
        }

        guard let data = data,
              let user = try? JSONDecoder().decode(User.self, from: data) else {
            completion(.failure(AppError.invalidData))
            return
        }

        DispatchQueue.main.async {
            completion(.success(user))
        }
    }.resume()
}

// Call site
fetchUser(id: "usr_123") { [weak self] result in
    switch result {
    case .success(let user): self?.updateUI(with: user)
    case .failure(let error): self?.showError(error)
    }
}

This is the pattern that powered iOS apps for years before async/await. You will still encounter it in legacy codebases. Understanding it deeply matters.

Interview Question

Q: What is a retain cycle in a closure and how do you fix it?

A retain cycle occurs when a closure captures self strongly and self holds a strong reference to the closure. Neither object's reference count reaches zero, so both leak memory permanently. The fix is a capture list: [weak self] makes the closure hold a weak reference to self, breaking the cycle. Use optional chaining (self?.method()) to safely call methods. Use [unowned self] only when you can guarantee self outlives the closure otherwise [weak self] is always the safer choice.

Summary

• A closure is an anonymous function defined inline.
• Syntax can be simplified progressively use the level that communicates intent best.
• Trailing closure syntax moves the last closure argument outside the parentheses.
• Closures capture variables from their surrounding scope and keep them alive.
• Retain cycles happen when a closure captures self and self owns the closure.
• Break retain cycles with [weak self] use [unowned self] only when certain.
• @escaping marks closures that outlive the function they're passed to.
• Any closure stored as a property or dispatched asynchronously must be @escaping.

Practice

1. Beginner: Use map, filter, and sorted with trailing closure syntax on this array: [5, 3, 8, 1, 9, 2, 7]. Filter out numbers below 5, double the remaining ones, then sort descending.
2. Intermediate: Write a debounce function that takes a closure and a delay, and only executes the closure if it hasn't been called again within the delay window. Use DispatchWorkItem and [weak self] correctly.
3. Advanced: Create a Cache<Key: Hashable, Value> class with a fetch method that takes a key and an @escaping completion handler. If the value exists in the cache, call completion immediately. Otherwise, simulate an async load, store the result, and call completion without leaking memory.

What’s Next

Article 8: Swift Structs — Value Types, Mutability, and Why Swift Prefers Them Over Classes

Closures taught you how to pass behavior around. Structs teach you how to model data safely. They’re the backbone of Swift’s value semantics and understanding why Swift defaults to structs over classes is one of the most important architectural decisions you’ll ever make.

Part of Swift from Zero to Senior a complete iOS engineering curriculum on Medium.

If capture lists finally made sense today, tap 👏 up to 50 times and do Repost 🔁 it helps this series reach developers who are stuck on the same concept.

Follow me so Article 8 lands in your feed automatically. Structs build directly on what you learned here.

See you in the next one.

In Part 1, we covered what Background App Refresh actually is, why iOS gates it so tightly, and how the scheduling decision gets made. Now let’s get practical: real code, how to test something the OS deliberately makes hard to test, and the mistakes that quietly tank your app’s scheduling priority.

Step 1: Registering the task

Register every task identifier before application(_:didFinishLaunchingWithOptions:) returns (or in your App init if using SwiftUI's App protocol). Registering late even by one async tick can cause silent failures.

import BackgroundTasks

func application(_ application: UIApplication,
                  didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    BGTaskScheduler.shared.register(
        forTaskWithIdentifier: "com.yourapp.refresh",
        using: nil
    ) { task in
        self.handleAppRefresh(task: task as! BGAppRefreshTask)
    }
    return true
}

Step 2: Scheduling a request

func scheduleAppRefresh() {
    let request = BGAppRefreshTaskRequest(identifier: "com.yourapp.refresh")
    request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60) // hint only
    do {
        try BGTaskScheduler.shared.submit(request)
    } catch {
        print("Could not schedule app refresh: \(error)")
    }
}

Call this from applicationDidEnterBackground and again at the end of every successful task run each request is single-use.

Step 3: Handling the task

func handleAppRefresh(task: BGAppRefreshTask) {
    scheduleAppRefresh() // queue the next one immediately
    
    let operation = RefreshDataOperation()

    task.expirationHandler = {
        operation.cancel()
    }

    operation.completionBlock = {
        task.setTaskCompleted(success: !operation.isCancelled)
    }

    OperationQueue().addOperation(operation)
}

The expirationHandler is not optional in practice if the OS revokes your time and you don't respond, you get penalized, not just interrupted.

Debugging: forcing a run without waiting days

Apple provides a real debugger command for this most developers never discover it:

e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateLaunchForTaskWithIdentifier:@"com.yourapp.refresh"]

Set a breakpoint after your app enters the background (or right after registration), paste that into the LLDB console, and iOS fires your handler immediately as if the OS had decided to schedule it. There’s also an expiration-simulation variant using _simulateExpirationForTaskWithIdentifier: to test your cancellation logic without waiting for the real timeout.

What to avoid

• Don’t treat earliestBeginDate as a schedule. It's a floor, not a target. Requesting "15 minutes from now" does not mean it runs at minute 15.
• Don’t do heavy work in a BGAppRefreshTask. It's capped around 30 seconds. Move large downloads or processing to BGProcessingTask, which supports longer windows and can require external power/network conditions you specify (requiresNetworkConnectivity, requiresExternalPower).
• Don’t forget to reschedule. Every task request is consumed on execution. If you don’t call scheduleAppRefresh() again inside the handler, your app effectively opts itself out of future background runs.
• Don’t ignore the expiration handler. Letting the system kill your task ungracefully damages your app’s scheduling reputation with iOS’s prediction model future requests get deprioritized.
• Don’t rely on background refresh for anything time-critical. Push notifications with content-available: 1 (silent push) are a more reliable trigger for urgent background work, though they're similarly budget-limited and not guaranteed either.
• Don’t test only in the simulator. The simulator’s background execution behavior is dramatically more permissive than real hardware. Code that “just works” in Xcode’s simulator frequently never fires on a real device under real battery/usage conditions.
• Don’t assume Low Power Mode users will ever see it run. Background refresh scheduling is effectively disabled under Low Power Mode plan a graceful degraded experience (e.g., pull-to-refresh) instead of depending on it.

The mental model to keep

Background App Refresh isn’t a feature you turn on it’s a request you earn, repeatedly, based on how the OS models your app’s relevance to the user. Design for “this might not run for a while,” build a solid foreground refresh path as the real source of truth, and treat background execution as a bonus that keeps content warm never as your app’s only path to fresh data.

Get that mental model right, and every “why isn’t this working” debugging session gets a lot shorter.

If BGTaskScheduler finally clicked for you today, tap 👏 up to 50 times it directly helps this series reach more iOS developers.

Follow me so the next deep dive lands in your feed the moment it’s live. This is the pattern behind almost every “why isn’t my background task running” bug report you’ll ever get.

Repost it if you think it’ll save your audience a debugging session. 🔁

See you in the next one. 🚀

If you’ve ever asked “why isn’t my app refreshing in the background even though I enabled the capability,” you’re not alone. Background App Refresh is one of the most misunderstood mechanisms in iOS. Developers treat it like a cron job. It is not. It’s a negotiation and iOS almost always wins.

This two-part series breaks down what Background Refresh actually is, why Apple built it this way, how it works under the hood, and in Part 2 exactly how to implement it correctly, with the mistakes to avoid.

Myth 1: Enabling the capability guarantees my code runs

No. Toggling Background App Refresh in your target’s Signing & Capabilities tab, or the switch in Settings, only makes background execution possible. It does not schedule anything. It does not promise a time. It does not even promise it’ll happen today.

Think of it as asking permission to be considered, not booking a slot.

Myth 2: Background Refresh means my app runs continuously in the background

Also no. iOS is not multitasking your app the way macOS multitasks a desktop app. Your app gets a short, budgeted burst of CPU time typically 30 seconds or less to do something useful (fetch data, update a cache, prep content) before iOS suspends it again.

What Background App Refresh actually is

Background App Refresh (and its modern replacement, the BGTaskScheduler framework introduced in iOS 13) is a system-mediated scheduling API that lets your app request a short window of execution time in the background, so that when the user does open the app, content feels fresh instead of stale.

There are two flavors under the modern API:

• BGAppRefreshTask short, lightweight refreshes (think: pulling new feed items).
• BGProcessingTask longer, heavier work (think: database cleanup, ML model updates, large downloads) that can run for minutes and can require the device to be charging/on Wi-Fi.

The old application(_:performFetchWithCompletionHandler:) (Background Fetch) still technically works but is deprecated in spirit Apple wants everyone on BGTaskScheduler now.

Why Apple built it this way

Battery life and thermal budget are finite, shared resources across every app on the device. If every app got to run whenever it wanted, your battery would be gone by lunch. So Apple centralized the decision-making into the OS itself, which uses on-device machine learning to predict:

• Which apps you’re likely to open soon
• What time of day you typically use them
• Your charging habits and Wi-Fi availability
• Overall system battery and thermal state

Your app doesn’t decide when it runs. iOS decides, based on your usage patterns, and only executes the task you scheduled if conditions look favorable.

How it actually works, step by step

1. You register a task identifier at app launch, before applicationDidFinishLaunching returns, using BGTaskScheduler.shared.register(forTaskWithIdentifier:using:launchHandler:).
2. You submit a request (BGAppRefreshTaskRequest or BGProcessingTaskRequest) with an earliestBeginDate a hint, not a promise.
3. iOS logs the request and quietly evaluates it against its behavioral model. It considers your app’s engagement score, battery level, network state, and device idle time.
4. When the OS decides the moment is right, it wakes your app briefly and calls your registered launch handler.
5. You have a strict time budget. You must call task.setTaskCompleted(success:) before the system-imposed limit, or iOS kills your process and this part matters penalizes your app's future scheduling priority for not finishing on time.
6. You should always schedule the next request before you finish the current one, because these are one-shot, not recurring.

Where it lives in your project

• Info.plist: UIBackgroundModes array needs fetch (legacy) and/or processing entries, plus BGTaskSchedulerPermittedIdentifiers listing every task identifier string you'll use.
• Signing & Capabilities: “Background Modes” capability, with “Background fetch” and/or “Background processing” checked.
• AppDelegate / App struct: registration must happen synchronously and early a common source of silent failures if it’s buried inside an async closure.

When does it actually run?

This is the honest, unglamorous answer: whenever iOS wants to. There’s no fixed interval. In practice:

• Apps used frequently and recently get more generous scheduling.
• Apps rarely opened may go days without a background execution.
• Low Power Mode disables background refresh scheduling almost entirely.
• The simulator and real devices behave very differently the simulator is far more permissive, which is exactly why so many developers ship code that “worked on my machine” and fails silently in production.

That unpredictability is the root of almost every myth in this space, and it’s exactly what we’ll deal with head-on in Part 2 along with the implementation code, debugging tricks (yes, there’s a legitimate way to force-trigger it for testing), and the mistakes that get apps throttled by the OS without the developer ever finding out why.

If Background App Refresh finally makes sense today, tap 👏 up to 50 times it directly helps this series reach more iOS developers.

Follow me so Part 2: Implementation, Debugging & Pitfalls lands in your feed the moment it’s live. Everything in this article is the foundation for the code we write next.

Repost it if you think it’ll help someone on your team stop fighting the scheduler. 🔁

See you in the next one. 🚀

Why Functions Deserve a Deep Dive

Every iOS app is a collection of functions calling other functions. Get them wrong and you end up with bloated view controllers, untestable logic, and APIs that are painful to use. Get them right and your code reads like well-written prose.

Swift’s function system is one of the richest in any language. Most developers only scratch the surface.

The Basics

func greet(name: String) -> String {
    return "Hello, \(name)!"
}

let message = greet(name: "Aryan")
print(message)  // Hello, Aryan!

Three parts: name, parameters, return type. But Swift adds layers on top of each one.

Argument Labels vs Parameter Names

This is one of Swift’s most distinctive features and one of its best.

func move(from start: String, to destination: String) {
    print("Moving from \(start) to \(destination)")
}

move(from: "London", to: "Dubai")

• from and to are argument labels what the caller sees
• start and destination are parameter names what the function body uses

This lets your function calls read like English sentences. It’s why Apple’s APIs feel so natural.

Omitting the label with _

func square(_ number: Int) -> Int {
    return number * number
}

square(5)  // ✅ No label needed - reads cleanly

Use _ when the parameter's purpose is obvious from context. Overuse it and you lose clarity.

Default Parameters

func fetchUsers(page: Int = 1, limit: Int = 20) -> [User] {
    // fetch logic
}

fetchUsers()              // page: 1, limit: 20
fetchUsers(page: 2)       // page: 2, limit: 20
fetchUsers(page: 3, limit: 50)

Default parameters reduce the number of overloads you need to write. Put defaults at the end of the parameter list — it’s a Swift convention and makes call sites cleaner.

Multiple Return Values with Tuples

func minMax(of array: [Int]) -> (min: Int, max: Int) {
    return (array.min()!, array.max()!)
}

let result = minMax(of: [3, 1, 7, 2, 9])
print(result.min)  // 1
print(result.max)  // 9

Named tuple elements make the return value self-documenting. No need to create a whole struct for simple paired returns.

Variadic Parameters

Accept any number of arguments of the same type:

func average(_ numbers: Double...) -> Double {
    guard !numbers.isEmpty else { return 0 }
    return numbers.reduce(0, +) / Double(numbers.count)
}

average(80, 90, 95)        // 88.33
average(100, 75, 60, 85)   // 80.0

Inside the function, numbers is a [Double]. Variadic parameters must come last if mixed with others.

inout Parameters Mutating Outside the Function

By default, function parameters are constants. inout lets a function modify the caller's variable directly.

func double(_ value: inout Int) {
    value *= 2
}

var score = 10
double(&score)
print(score)  // 20

The & at the call site signals mutation a deliberate design choice by Swift to make side effects visible.

When to use: Low-level algorithms, swap operations, performance-critical paths where you want to avoid copying. In most app code, prefer returning a new value instead of mutating in place.

@discardableResult

By default, Swift warns you if you ignore a function’s return value. Sometimes that’s intentional:

@discardableResult
func saveToCache(_ data: Data) -> Bool {
    // save logic
    return true
}

saveToCache(data)         // ✅ No warning - return value ignored intentionally
let success = saveToCache(data)  // ✅ Also fine

Use sparingly. If the return value is always important, don’t suppress the warning.

Functions as First-Class Citizens

In Swift, functions are values. You can assign them to variables, pass them as arguments, and return them from other functions.

// Assign a function to a variable
func add(_ a: Int, _ b: Int) -> Int { a + b }
func multiply(_ a: Int, _ b: Int) -> Int { a * b }

var operation: (Int, Int) -> Int = add
print(operation(3, 4))   // 7
operation = multiply
print(operation(3, 4))   // 12

Passing functions as parameters

func applyOperation(_ a: Int, _ b: Int, using op: (Int, Int) -> Int) -> Int {
    op(a, b)
}

applyOperation(5, 3, using: add)       // 8
applyOperation(5, 3, using: multiply)  // 15

This is the foundation of functional programming in Swift and directly how map, filter, and sort work under the hood.

Nested Functions

Functions can live inside other functions scoped to where they’re needed:

func processPayment(amount: Double) -> String {
    func formatCurrency(_ value: Double) -> String {
        String(format: "$%.2f", value)
    }

    let tax = amount * 0.18
    let total = amount + tax
    return "Total: \(formatCurrency(total))"
}

The inner formatCurrency is invisible outside processPayment. Use nested functions to keep helpers private and co-located with their only user.

Real-World Pattern: Configurable Network Request

func request(
    endpoint: String,
    method: HTTPMethod = .get,
    body: Data? = nil,
    retries: Int = 3,
    completion: (Result<Data, Error>) -> Void
) {
    // network logic
}

// Clean, readable call sites
request(endpoint: "/users") { result in
    // handle result
}
request(endpoint: "/orders", method: .post, body: orderData) { result in
    // handle result
}

Default parameters + labeled arguments = an API that reads clearly at every call site and requires minimal boilerplate for common cases.

Interview Question

Q: What’s the difference between a parameter name and an argument label in Swift?

The argument label is used at the call site it’s what the caller writes. The parameter name is used inside the function body. By default they’re the same. You can specify different ones with func move(from start: String) where from is the label and start is the internal name. Use _ to omit the label entirely. This design lets Swift APIs read like natural language while keeping internal naming clean and descriptive.

Summary

• Argument labels make call sites read like English use them deliberately.
• _ omits the label when context makes the parameter obvious.
• Default parameters reduce overloads and simplify call sites.
• Tuples return multiple values without a full struct.
• inout mutates the caller's variable always visible with & at the call site.
• @discardableResult suppresses the unused return value warning use sparingly.
• Functions are first-class values assignable, passable, returnable.
• Nested functions scope helpers to exactly where they’re needed.

Practice

1. Beginner: Write a function bmi(weight: Double, height: Double) -> String that computes BMI and returns "Underweight", "Normal", "Overweight", or "Obese". Use labeled parameters and a default unit of kilograms/meters.
2. Intermediate: Write a retry function that takes a throwing operation as a parameter and a retry count (default 3), attempts the operation up to that many times, and returns the result or throws the last error.
3. Advanced: Implement a pipeline function that takes a value and an array of transformation functions [(T) -> T], applies them in order, and returns the final result. Make it generic so it works with any type.

What’s Next

Article 7: Swift Closures Syntax, Capture Lists, Memory, and Why They’re Everywhere

You just learned that functions are first-class values. Closures are the natural evolution of that idea anonymous functions you define inline. They power map, filter, sort, completion handlers, SwiftUI's body, and almost every async API. This one is a big deal.

Part of Swift from Zero to Senior a complete iOS engineering curriculum on Medium.

If functions finally clicked for you today, tap 👏 up to 50 times it directly helps this series reach more iOS developers.

Follow me so Article 7 lands in your feed the moment it’s live. Closures build directly on everything in this article.

See you in the next one. 🚀

Why Loops Matter More Than You Think

Loops touch nearly every layer of an iOS app rendering lists, processing data, animating frames, parsing responses. A poorly written loop in a hot path can tank your frame rate or freeze the main thread. A well-written one is invisible.

Swift gives you several looping tools. Knowing which one to reach for and why separates junior code from production-grade code.

for-in: Your Most-Used Loop

let fruits = ["apple", "banana", "cherry"]

for fruit in fruits {
    print(fruit)
}
// apple
// banana
// cherry

Works on any Sequence arrays, sets, dictionaries, ranges, strings.

// Range loop
for i in 1...5 {
    print(i)  // 1 2 3 4 5
}

// String characters
for char in "Swift" {
    print(char)  // S w i f t
}

// Dictionary - order not guaranteed
let scores = ["Alice": 95, "Bob": 87]
for (name, score) in scores {
    print("\(name): \(score)")
}

When you don’t need the index

// ❌ Unnecessary index
for i in 0..<fruits.count {
    print(fruits[i])
}

// ✅ Direct iteration
for fruit in fruits {
    print(fruit)
}

Only use index-based loops when you actually need the index.

enumerated(): Index + Value Together

let players = ["Alice", "Bob", "Charlie"]

for (index, player) in players.enumerated() {
    print("\(index + 1). \(player)")
}
// 1. Alice
// 2. Bob
// 3. Charlie

Production use: Perfect for numbered lists, position-dependent logic, and debugging output. Cleaner than managing a counter variable manually.

zip(): Loop Two Collections Together

let names = ["Alice", "Bob", "Charlie"]
let scores = [95, 87, 92]

for (name, score) in zip(names, scores) {
    print("\(name) scored \(score)")
}
// Alice scored 95
// Bob scored 87
// Charlie scored 92

zip stops at the shorter collection no index out of bounds risk. Use it whenever you're pairing two arrays.

stride: Precise Step Control

When you need a loop that doesn’t increment by 1:

// Count up by 2
for i in stride(from: 0, to: 10, by: 2) {
    print(i)  // 0 2 4 6 8
}

// Count down
for i in stride(from: 10, through: 0, by: -2) {
    print(i)  // 10 8 6 4 2 0
}

• stride(from:to:by:) excludes the end value
• stride(from:through:by:) includes the end value

Real-world use: Animation frame stepping, audio sample processing, pagination with custom step sizes.

while: Loop Until a Condition Fails

Use while when you don't know how many iterations you need upfront.

var attempts = 0
var success = false

while !success && attempts < 3 {
    success = tryNetworkRequest()
    attempts += 1
}

The condition is checked before each iteration. If it’s false from the start, the body never runs.

repeat-while: Always Runs At Least Once

var pin = ""

repeat {
    pin = promptUserForPIN()
} while pin.count != 4

The body runs first, then the condition is checked. Use this when the action must happen at least once before you can evaluate the condition like prompting for input.

break and continue: Controlling Flow

// break — exit the loop entirely
for i in 1...10 {
    if i == 5 { break }
    print(i)  // 1 2 3 4
}

// continue - skip this iteration, keep going
for i in 1...10 {
    if i % 2 == 0 { continue }
    print(i)  // 1 3 5 7 9
}

Labeled statements for nested loops

outer: for row in 0..<3 {
    for col in 0..<3 {
        if row == 1 && col == 1 {
            break outer  // exits BOTH loops
        }
        print("(\(row), \(col))")
    }
}

Without the label, break only exits the inner loop. Labels give you precise control over nested loop exits use them when the intent is clear.

Performance: What Actually Matters

Avoid repeated property access in loop conditions

let items = largeArray
// ❌ .count is evaluated every iteration
for i in 0..<items.count { ... }

// ✅ Captured once - compiler usually optimizes this, but being explicit is better
let count = items.count
for i in 0..<count { ... }

Prefer forEach for functional style but know the tradeoff

fruits.forEach { fruit in
    print(fruit)
}

forEach is clean for side effects but has one critical difference from for-in: you cannot use break or continue inside forEach. It's a closure return just exits the closure, not the loop.

// ❌ This doesn't break the loop — it just returns from the closure
fruits.forEach { fruit in
    if fruit == "banana" { return }  // skips "banana", continues to "cherry"
    print(fruit)
}

// ✅ Use for-in if you need break/continue
for fruit in fruits {
    if fruit == "banana" { break }  // actually stops the loop
    print(fruit)
}

This catches a lot of developers off guard. Know the difference.

Real-World Pattern: Pagination

func fetchAllPages(startPage: Int = 1, maxPages: Int = 10) async throws -> [Item] {
    var results: [Item] = []
    var currentPage = startPage

    while currentPage <= maxPages {
        let page = try await api.fetch(page: currentPage)
        results.append(contentsOf: page.items)
        guard page.hasNextPage else { break }
        currentPage += 1
    }
    return results
}

while with a break on condition clean, readable, safe. This is production pagination logic.

Interview Question

Q: What’s the difference between break inside forEach and break inside for-in?

In a for-in loop, break exits the loop immediately. In forEach, there is no break forEach takes a closure, and return inside it only exits the current closure call (equivalent to continue). You cannot exit a forEach loop early. If you need early exit, use for-in with break, or use first(where:) / contains(where:) depending on the goal.

Summary

• Use for-in for most loops it's clean, safe, and works on any Sequence.
• Use enumerated() when you need both index and value.
• Use zip() to loop two collections in parallel no index out of bounds risk.
• Use stride when step size isn't 1.
• Use while when iteration count is unknown upfront.
• Use repeat-while when the body must execute at least once.
• forEach doesn't support break or continue use for-in when you need flow control.
• Labeled statements give precise control over nested loop exits.

Practice

1. Beginner: Write a loop that prints the multiplication table for any number from 1 to 10 using stride.
2. Intermediate: Given two arrays let userIDs = [1, 2, 3, 4, 5] and let userNames = ["Alice", "Bob", "Charlie", "Diana", "Eve"] use zip and enumerated to print a numbered list of "1. Alice (ID: 1)".
3. Advanced: Write a function chunked<T>(_ array: [T], size: Int) -> [[T]] that splits any array into chunks of a given size using a while loop. Handle edge cases: empty array, chunk size larger than array, chunk size of 1.

What’s Next

Article 6: Swift Functions Parameters, Return Types, Overloading, and First-Class Functions

Loops move through data. Functions transform it. Next article covers everything about Swift functions default parameters, labeled arguments, variadic parameters, @discardableResult, inout parameters, and why functions are first-class citizens in Swift.

Part of Swift from Zero to Senior — a complete iOS engineering curriculum on Medium.

If the forEach vs for-in difference saved you a future bug, tap 👏 up to 50 times, It helps this series reach developers who need it.

Follow me so Article 6 lands in your feed automatically. Each article in this series builds directly on the last.

See you in the next one. 🚀