The Problem Actors Solve

Async/await makes asynchronous code readable. It does not make it safe.

Consider two concurrent tasks reading and writing the same property on a class:

class Counter {
    var value = 0

    func increment() {
        value += 1
    }
}

let counter = Counter()
Task { counter.increment() }
Task { counter.increment() }

Both tasks run concurrently. Both read value, both add 1, both write back. If they interleave at exactly the wrong moment, both read 0, both write 1, and the result is 1 instead of 2. The data is silently corrupted. No crash. No warning. Just a wrong number.

This is a data race. In production apps with real concurrency, they are inevitable without a protection mechanism.

Actors are that mechanism.

What Is an Actor?

An actor is a reference type, like a class, with one critical difference: only one task can access its mutable state at a time. The Swift runtime enforces this automatically.

actor Counter {
    var value = 0

    func increment() {
        value += 1  // safe - only one caller at a time
    }

    func currentValue() -> Int {
        value
    }
}

Declare it with actor instead of class. That single keyword makes all mutable state inside it serialized. No locks. No queues. No manual synchronization.

Accessing an Actor

Because actor methods can only run one at a time, calling them from outside requires await. The call suspends until the actor is available.

let counter = Counter()

Task {
    await counter.increment()
    let value = await counter.currentValue()
    print(value)  // always correct, never a data race
}

Task {
    await counter.increment()
}

The await is not waiting for a network call here. It is waiting for the actor to be free. If another task is currently executing inside the actor, this one suspends until the actor finishes and hands control over.

Actor Isolation

Properties and methods inside an actor are isolated. Accessing them from outside always requires await.

actor ImageCache {
    private var cache: [String: UIImage] = [:]

    func store(_ image: UIImage, for key: String) {
        cache[key] = image
    }
    func retrieve(for key: String) -> UIImage? {
        cache[key]
    }
}

let cache = ImageCache()
// From async context
let image = await cache.retrieve(for: "profile_pic")
await cache.store(downloadedImage, for: "profile_pic")

The cache dictionary is never touched by two tasks simultaneously. The actor guarantees it.

nonisolated: Opting Out of Isolation

Some methods do not touch mutable state and do not need isolation. Mark them nonisolated to call them without await.

actor UserSession {
    var token: String
    let userID: String  // constant — safe to access without isolation

    init(token: String, userID: String) {
        self.token = token
        self.userID = userID
    }
    nonisolated func sessionDescription() -> String {
        "Session for user \(userID)"  // only reads a constant
    }
}
let session = UserSession(token: "tok_abc", userID: "usr_001")
// No await needed
print(session.sessionDescription())

nonisolated is useful for methods that only read constants, conform to protocols with synchronous requirements, or do pure computation with no shared state.

MainActor: The Actor for UI Work

@MainActor is a global actor built into Swift. Every method marked with it runs on the main thread. It is the replacement for DispatchQueue.main.async.

@MainActor
class FeedViewModel: ObservableObject {
    @Published var posts: [Post] = []
    @Published var isLoading = false

    func loadFeed() async {
        isLoading = true
        defer { isLoading = false }
        do {
            // This await suspends off the main thread
            let fetched = try await PostService.shared.fetchPosts()
            // Resuming here is guaranteed to be on the main thread
            posts = fetched
        } catch {
            print("Load failed: \(error)")
        }
    }
}

The entire class is main-actor-isolated. Every property access and every method call is thread-safe for UI work without a single DispatchQueue call anywhere.

Sendable: Crossing Concurrency Boundaries Safely

When you pass data between actors or tasks, Swift needs to know the data is safe to share. Types that are safe to send across concurrency boundaries conform to Sendable.

// Structs with Sendable properties are automatically Sendable
struct Message: Sendable {
    let id: UUID
    let text: String
    let sentAt: Date
}

// Classes must be manually marked and are only safe if they protect their state
final class UserToken: @unchecked Sendable {
    private let lock = NSLock()
    private var _value: String
    init(_ value: String) { _value = value }
    var value: String {
        lock.withLock { _value }
    }
}

Value types like structs are Sendable by default when all their stored properties are Sendable. Classes require explicit annotation and manual safety guarantees.

The compiler warns you when you try to send non-Sendable types across concurrency boundaries, catching potential data races at build time.

Actor Reentrancy

Actors are reentrant. When an actor suspends at an await inside one of its methods, another task can enter the actor during that suspension.

actor DataStore {
    var items: [String] = []

    func addItem(_ item: String) async {
        // Another task can run here while this one is suspended
        let validated = await validate(item)
        // items might have changed while we were suspended
        items.append(validated)
    }
}

This is intentional. Non-reentrant actors would deadlock. But it means you should not assume state is unchanged across an await inside an actor. Check state again after every suspension if your logic depends on it.

Real-World Pattern: Thread-Safe Cache

actor NetworkCache {
    private var cache: [URL: Data] = [:]
    private var inFlightRequests: [URL: Task<Data, Error>] = [:]

    func data(for url: URL) async throws -> Data {
        // Return cached data immediately if available
        if let cached = cache[url] {
            return cached
        }
        // Reuse an in-flight request for the same URL
        if let existing = inFlightRequests[url] {
            return try await existing.value
        }
        // Start a new request
        let task = Task<Data, Error> {
            let (data, _) = try await URLSession.shared.data(from: url)
            return data
        }
        inFlightRequests[url] = task
        do {
            let data = try await task.value
            cache[url] = data
            inFlightRequests[url] = nil
            return data
        } catch {
            inFlightRequests[url] = nil
            throw error
        }
    }
}

This cache deduplicates concurrent requests for the same URL, stores results, and handles errors cleanly. Without actors, implementing this correctly requires explicit locking and is easy to get wrong. With an actor, the isolation guarantee does the heavy lifting.

Interview Questions

Q: What is an actor in Swift and how does it prevent data races?

An actor is a reference type that serializes access to its mutable state. Only one task can execute inside an actor at a time. The Swift compiler enforces this: accessing an actor’s properties or methods from outside requires await, which suspends the caller until the actor is free. This makes it structurally impossible for two tasks to read and write the same mutable state simultaneously, eliminating data races without manual locking.

Q: What is the difference between an actor and a class with a lock?

Both protect shared mutable state from concurrent access. A class with a manual lock puts the burden on the developer to lock correctly, unlock in all paths including errors, and avoid deadlocks. Actors move this enforcement to the compiler. You cannot accidentally access actor state without await. The compiler catches violations at build time. Actors are also reentrant by design, which avoids deadlocks that explicit locks can cause when a function tries to acquire a lock it already holds.

Summary

• Data races happen when two tasks read and write the same mutable state concurrently without synchronization.
• An actor serializes access to its mutable state. Only one task runs inside it at a time.
• Accessing actor state from outside requires await, which suspends until the actor is available.
• nonisolated methods opt out of isolation for pure computation and constant access.
• @MainActor is a global actor that ensures code runs on the main thread.
• Actor reentrancy means state can change across an await inside an actor. Check state again after suspension when it matters.
• Sendable marks types safe to pass across concurrency boundaries. Structs are Sendable by default.
• The compiler enforces concurrency safety at build time, not runtime.

Practice

1. Beginner: Convert this class to an actor and fix all the call sites to use await:

class ScoreTracker {
    var highScore = 0
    var totalGames = 0

    func recordScore(_ score: Int) {
        totalGames += 1
        if score > highScore { highScore = score }
    }
}

Show that two concurrent Tasks updating the score are now safe.

1. Intermediate: Build a thread-safe RateLimiter actor that tracks how many requests have been made in the last 60 seconds. Add a canMakeRequest() -> Bool method and a recordRequest() method. Use it to guard API calls in a view model and show how @MainActor on the view model composes correctly with the actor-isolated rate limiter.
2. Advanced: Implement a DownloadManager actor that manages up to 3 concurrent downloads. Queues additional requests beyond that limit. Provides progress: Double per download URL. Notifies a @MainActor delegate when each download completes. Handle cancellation cleanly so cancelling one download does not affect others in the queue.

What’s Next

Article 20: Swift Property Wrappers: @State, @Binding, @Published, and Building Your Own

Actors protect shared state at the runtime level. Property wrappers manage state at the declaration level. @State, @Binding, @Published, @AppStorage, @EnvironmentObject — every SwiftUI developer uses these daily. Understanding what they actually do, and how to build your own, is what separates developers who fight SwiftUI from developers who work with it.

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

If actors just replaced a mental model built on DispatchQueue and locks, tap 👏 up to 50 times. It helps this series reach developers still writing thread-unsafe code without knowing it.

Follow me so Article 20 lands in your feed automatically. Property wrappers are next and they unlock a completely different way to manage state.

See you in the next one. 🚀

The Problem Async/Await Solves

Before Swift 5.5, every asynchronous operation used completion handlers. Network call? Callback. Parse the result? Another callback. Update the UI? Dispatch back to the main thread in yet another callback.

// The old way — callback pyramid
func loadUserProfile(id: String) {
    fetchUser(id: id) { result in
        switch result {
        case .success(let user):
            fetchPosts(for: user) { result in
                switch result {
                case .success(let posts):
                    fetchComments(for: posts.first) { result in
                        switch result {
                        case .success(let comments):
                            DispatchQueue.main.async {
                                self.updateUI(user: user, posts: posts, comments: comments)
                            }
                        case .failure(let error):
                            self.showError(error)
                        }
                    }
                case .failure(let error):
                    self.showError(error)
                }
            }
        case .failure(let error):
            self.showError(error)
        }
    }
}

Three levels of nesting for three sequential operations. Error handling is duplicated at every level. Thread management is manual. This is not an extreme example. This is a typical profile screen.

Async/await collapses all of it.

The Same Code With Async/Await

func loadUserProfile(id: String) async throws {
    let user = try await fetchUser(id: id)
    let posts = try await fetchPosts(for: user)
    let comments = try await fetchComments(for: posts.first)
    updateUI(user: user, posts: posts, comments: comments)
}

Same operations. Same error handling. Reads like synchronous code. The compiler and Swift runtime handle all the thread management.

How Async Functions Work

Mark a function with async to indicate it can suspend execution without blocking a thread.

func fetchUser(id: String) async throws -> User {
    let url = URL(string: "https://api.myapp.com/users/\(id)")!
    let (data, response) = try await URLSession.shared.data(from: url)

    guard let httpResponse = response as? HTTPURLResponse,
          httpResponse.statusCode == 200 else {
        throw NetworkError.serverError
    }

    return try JSONDecoder().decode(User.self, from: data)
}

async in the signature tells callers this function suspends. await at the call site marks where suspension can happen. When the function hits await, Swift suspends it, frees the thread for other work, and resumes when the awaited operation completes.

The thread is not blocked. It is not sleeping. It is doing other work.

Calling Async Functions

You can only call async functions from an async context. In a SwiftUI view or UIViewController, start a Task:

// SwiftUI
.onAppear {
    Task {
        do {
            user = try await fetchUser(id: "usr_001")
        } catch {
            errorMessage = error.localizedDescription
        }
    }
}

// UIKit
override func viewDidLoad() {
    super.viewDidLoad()
    Task {
        do {
            let user = try await fetchUser(id: "usr_001")
            updateUI(with: user)
        } catch {
            showError(error)
        }
    }
}

Task creates a new asynchronous unit of work. It bridges the synchronous UIKit/SwiftUI world into the async world.

async let: Parallel Execution

Sequential await calls run one after another. When operations are independent, run them in parallel with async let.

// Sequential — total time = A + B + C
func loadDashboard() async throws -> Dashboard {
    let user = try await fetchUser(id: currentUserID)
    let feed = try await fetchFeed()
    let notifications = try await fetchNotifications()

    return Dashboard(user: user, feed: feed, notifications: notifications)
}

// Parallel - total time = max(A, B, C)
func loadDashboard() async throws -> Dashboard {
    async let user = fetchUser(id: currentUserID)
    async let feed = fetchFeed()
    async let notifications = fetchNotifications()

    return try await Dashboard(
        user: user,
        feed: feed,
        notifications: notifications
    )
}

async let launches all three requests simultaneously. The await at the end waits for all of them. If your dashboard loaded in 1.5 seconds before, this version might load it in 0.5 seconds with no extra code.

Async Sequences

for await iterates over values that arrive asynchronously over time.

func streamLiveScores() async throws {
    let url = URL(string: "https://api.sports.com/live")!

    for try await score in URLSession.shared.bytes(from: url).lines {
        updateScoreBoard(with: score)
    }
}

Each iteration suspends until the next value arrives, without blocking any thread. This replaces long-polling patterns and WebSocket callback chains cleanly.

Structured Concurrency with TaskGroup

When the number of parallel operations is dynamic, use TaskGroup.

func fetchAllProfiles(ids: [String]) async throws -> [User] {
    try await withThrowingTaskGroup(of: User.self) { group in
        for id in ids {
            group.addTask {
                try await fetchUser(id: id)
            }
        }
        
        var users: [User] = []
        for try await user in group {
            users.append(user)
        }
        return users
    }
}

Each ID gets its own task. All tasks run in parallel. Results are collected as they complete. The group handles cancellation and error propagation automatically.

Cancellation

Tasks can be cancelled. Check Task.isCancelled to exit early from long operations.

func processImages(_ urls: [URL]) async throws -> [UIImage] {
    var images: [UIImage] = []

    for url in urls {
        try Task.checkCancellation()  // throws CancellationError if cancelled
        let image = try await downloadImage(from: url)
        images.append(image)
    }
    return images
}

When the calling task is cancelled (user navigates away, for example), checkCancellation throws and the function exits cleanly. No lingering work, no wasted network calls.

MainActor: Thread Safety for UI Updates

UI updates must happen on the main thread. @MainActor enforces this at compile time.

@MainActor
class UserViewModel: ObservableObject {
    @Published var user: User?
    @Published var isLoading = false

func loadUser(id: String) async {
        isLoading = true
        defer { isLoading = false }
        do {
            user = try await fetchUser(id: id)  // suspends off main thread
            // automatically resumes on main thread - @MainActor guarantees it
        } catch {
            print("Error: \(error)")
        }
    }
}

The await suspends off the main thread while the network request runs. When it resumes, @MainActor guarantees it is back on the main thread before touching user or isLoading. No DispatchQueue.main.async { } needed.

Real-World Pattern: Repository With Async/Await

protocol UserRepository {
    func fetchUser(id: String) async throws -> User
    func updateUser(_ user: User) async throws -> User
    func deleteUser(id: String) async throws
}

struct LiveUserRepository: UserRepository {
    private let client: APIClient
    func fetchUser(id: String) async throws -> User {
        try await client.get("/users/\(id)")
    }
    func updateUser(_ user: User) async throws -> User {
        try await client.put("/users/\(user.id)", body: user)
    }
    func deleteUser(id: String) async throws {
        try await client.delete("/users/\(id)")
    }
}

@MainActor
class UserViewModel: ObservableObject {
    @Published var user: User?
    private let repository: UserRepository
    init(repository: UserRepository = LiveUserRepository(client: .shared)) {
        self.repository = repository
    }
    func load(id: String) async {
        do {
            user = try await repository.fetchUser(id: id)
        } catch {
            print(error)
        }
    }
}

Protocol-based repository, async throughout, @MainActor for safe UI updates, dependency-injectable for testing. This is the pattern that scales.

Interview Questions

Q: How does async/await differ from completion handlers in Swift?

Completion handlers use closures called back when work finishes. They lead to nested callbacks, duplicated error handling, and manual thread management. Async/await lets asynchronous code look and read like synchronous code. The compiler and Swift runtime manage suspension and resumption. Error handling uses the same try/catch as synchronous code. Thread management is handled by actors and @MainActor. The result is code that is dramatically easier to read, write, and debug.

Q: What is the difference between sequential await and async let?

Sequential await calls execute one after another. Each call waits for the previous one to finish before starting. async let starts multiple async operations simultaneously. The final await waits for all of them to complete. Use sequential await when each result depends on the previous one. Use async let when operations are independent and can run in parallel, reducing total execution time to the duration of the longest operation rather than the sum of all.

Summary

• async marks a function that can suspend without blocking a thread.
• await marks where suspension happens and the runtime may do other work.
• Task bridges synchronous code into an async context from UIKit and SwiftUI.
• Sequential await runs operations one after another.
• async let runs independent operations in parallel.
• for await iterates over async sequences that deliver values over time.
• TaskGroup coordinates a dynamic number of parallel tasks.
• Task.checkCancellation() exits cleanly when a task is cancelled.
• @MainActor guarantees UI updates happen on the main thread without manual dispatching.

Practice

1. Beginner: Convert this completion-handler function to async/await:

func fetchQuote(completion: @escaping (Result<String, Error>) -> Void) {
    URLSession.shared.dataTask(with: URL(string: "https://api.quotable.io/random")!) { data, _, error in
        if let error = error { completion(.failure(error)); return }
        let quote = String(data: data!, encoding: .utf8) ?? ""
        completion(.success(quote))
    }.resume()
}

1. Intermediate: Build a ImageLoader class that fetches three images in parallel using async let, falls back to a placeholder if any individual image fails (without failing the whole operation), and publishes the results on the main thread via @MainActor.
2. Advanced: Implement a RateLimitedTaskGroup that runs a dynamic list of async tasks but limits concurrency to a maximum of N simultaneous tasks at any time. Use TaskGroup and a semaphore-equivalent mechanism in Swift Concurrency. Show it processing 20 API calls with a concurrency limit of 5.

What’s Next

Article 19: Swift Actors: Safe Shared State in Concurrent Code

Async/await handles the flow of asynchronous work. Actors handle the safety of shared mutable state across that work. Without actors, two concurrent tasks reading and writing the same property is a data race. With actors, it is impossible. This is one of the most important concurrency concepts for building stable iOS apps.

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

If async/await just made your network code feel like a breath of fresh air, tap 👏 up to 50 times and do 🔁. It helps this series reach developers still buried in completion handler pyramids.

Follow me so Article 19 lands in your feed automatically. Actors are next and they complete the Swift Concurrency picture.

See you in the next one. 🚀

For years, RxSwift was the answer to a simple question: how do I react to things that change over time? Network responses, user input, notifications, timers and UI state all became streams.

Swift has since grown its own answers. async/await and AsyncSequence handle asynchronous work and event streams. The @Observable macro handles UI state. Structured concurrency handles cancellation and lifetime.

So can you replace RxSwift with them? For most apps, mostly yes. But it’s not a one-to-one swap, and knowing where it isn’t saves a lot of pain. This guide walks through it as “this replaces that”, with code.

The big picture

RxSwift did three jobs at once, and each now has a native replacement:

Three things don’t map cleanly: sharing one source between many subscribers (share()), a few niche operators like withLatestFrom, and RxCocoa's UIKit bindings. I'll cover those near the end.

Requirements

@Observable comes from the Observation framework, introduced in iOS 17 with Swift 5.9. If you still support iOS 16, you can't use it. Stay on ObservableObject and @Published for state, but you can still adopt async/await for the async parts.

Swift Async Algorithms is a separate Swift package maintained by Apple. You add it as a dependency; it isn’t part of the standard library.

Cheat sheet: types

Cheat sheet: operators

Built into AsyncSequence:

From the Swift Async Algorithms package:

From the language itself:

Part 1: State. From BehaviorRelay and Driver to @Observable

Here’s a typical RxSwift view model:

final class ProfileViewModel {
    private let disposeBag = DisposeBag()

    let name = BehaviorRelay<String>(value: "")
    let isLoading = BehaviorRelay<Bool>(value: false)
    let errorMessage = PublishRelay<String>()
    init(api: API) {
        isLoading.accept(true)
        api.fetchProfile()                       // Single<Profile>
            .observe(on: MainScheduler.instance)
            .subscribe(
                onSuccess: { [weak self] profile in
                    self?.name.accept(profile.name)
                    self?.isLoading.accept(false)
                },
                onFailure: { [weak self] error in
                    self?.errorMessage.accept(error.localizedDescription)
                    self?.isLoading.accept(false)
                }
            )
            .disposed(by: disposeBag)
    }
}

And the modern version:

import Observation

@MainActor
@Observable
final class ProfileViewModel {
    var name = ""
    var isLoading = false
    var errorMessage: String?

    @ObservationIgnored private let api: API

    init(api: API) {
        self.api = api
    }

    func load() async {
        isLoading = true
        defer { isLoading = false }
        do {
            let profile = try await api.fetchProfile()
            name = profile.name
        } catch {
            errorMessage = error.localizedDescription
        }
    }
}

What changed:

• There’s no DisposeBag, no [weak self], no .accept() and no observe(on:). @MainActor takes care of threading.
• BehaviorRelay<T> is now a plain var. @Observable tracks which properties a view actually reads, so only views that read a changed property are invalidated.
• A one-off event like an error toast becomes optional state (as above), or an AsyncStream if you really need event semantics.
• @ObservationIgnored opts a property out of tracking. It's useful for dependencies that never change.
• @Observable works on classes only.

The SwiftUI side

struct ProfileView: View {
    @State private var viewModel = ProfileViewModel(api: .live)

    var body: some View {
        VStack {
            if viewModel.isLoading { ProgressView() }
            Text(viewModel.name)
        }
        .task { await viewModel.load() }
    }
}

The property wrappers change too:

For controls that need bindings, like a TextField, use @Bindable:

struct SearchView: View {
    @State private var viewModel = SearchViewModel(api: .live)

    var body: some View {
        @Bindable var viewModel = viewModel
        TextField("Search", text: $viewModel.query)
    }
}

Part 2: The classic search box. flatMapLatest and debounce

Nothing shows the shift in thinking better than search-as-you-type. In RxSwift:

query
    .debounce(.milliseconds(300), scheduler: MainScheduler.instance)
    .distinctUntilChanged()
    .flatMapLatest { api.search($0).catchAndReturn([]) }
    .asDriver(onErrorJustReturn: [])
    .drive(results)
    .disposed(by: disposeBag)

With @Observable and .task(id:):

@MainActor
@Observable
final class SearchViewModel {
    var query = ""
    private(set) var results: [Item] = []

    @ObservationIgnored private let api: API

    init(api: API) { self.api = api }

    func search() async {
        let q = query.trimmingCharacters(in: .whitespaces)
        guard !q.isEmpty else { results = []; return }
        do {
            let items = try await api.search(q)
            if !Task.isCancelled { results = items }
        } catch {
            if !Task.isCancelled { results = [] }
        }
    }
}

struct SearchView: View {
    @State private var viewModel = SearchViewModel(api: .live)

    var body: some View {
        @Bindable var viewModel = viewModel

        List(viewModel.results) { item in Text(item.title) }
            .searchable(text: $viewModel.query)
            .task(id: viewModel.query) {
                do {
                    try await Task.sleep(for: .milliseconds(300))
                    await viewModel.search()
                } catch { /* cancelled while debouncing */ }
            }
    }
}

Why this works:

• .task(id:) cancels the running task and starts a new one whenever the id changes. That's exactly what flatMapLatest does.
• Sleeping first and working second gives you debounce. If the user types again, the sleep throws a cancellation error and the search never fires.
• distinctUntilChanged comes for free, because the task only restarts when the id value actually changes.

Outside SwiftUI, hold the task yourself:

private var searchTask: Task<Void, Never>?

func queryChanged(_ text: String) {
    searchTask?.cancel()
    searchTask = Task { [weak self] in
        try? await Task.sleep(for: .milliseconds(300))
        guard !Task.isCancelled else { return }
        await self?.search(text)
    }
}

Part 3: Streams. From Observable to AsyncSequence

Consuming a stream replaces subscribe with a for await loop:

Task {
    for await note in NotificationCenter.default.notifications(named: UIApplication.didBecomeActiveNotification) {
        print(note)
    }
}

The loop ends when the sequence finishes or the surrounding task is cancelled. There’s no DisposeBag, because the task's lifetime is the subscription.

Creating a stream replaces Observable.create:

func locationUpdates() -> AsyncStream<CLLocation> {
    AsyncStream { continuation in
        let manager = LocationManagerWrapper { location in
            continuation.yield(location)
        }
        manager.start()

        continuation.onTermination = { _ in
            manager.stop()
        }
    }
}

LocationManagerWrapper stands in for your own wrapper around the delegate API. onTermination plays the role of the cleanup block in Disposables.create. Use AsyncThrowingStream if the source can fail.

Subjects become a stream paired with its continuation:

let (stream, continuation) = AsyncStream.makeStream(of: Int.self)

continuation.yield(1)
continuation.yield(2)
continuation.finish()

for await value in stream { print(value) }

Combining streams uses Swift Async Algorithms:

import AsyncAlgorithms

for await (user, settings) in combineLatest(userStream, settingsStream) {
    render(user, settings)
}

for await value in merge(streamA, streamB) {
    handle(value)
}

Parallel one-shot calls, the old Observable.zip of two Singles, are just async let:

async let profile = api.fetchProfile()
async let posts = api.fetchPosts()
let (p, ps) = try await (profile, posts)

Part 4: Watching an @Observable property as a stream

A common Rx habit is subscribing to a single property. With @Observable, properties aren't streams by default.

Inside SwiftUI you don’t need to do anything. Reading a property in body is the subscription.

Outside SwiftUI, you have two options:

• withObservationTracking works back to iOS 17, but it only fires once per registration. You have to re-register after every change.
• Observations arrived with Swift 6.2 (proposal SE-0475) and is available from iOS 26. It turns an expression over observable state into an AsyncSequence:

let names = Observations { viewModel.name }

Task {
    for await name in names {
        print("Name is now \(name)")
    }
}

Observations is designed around transactions, meaning it groups changes that happen together. Don't rely on seeing every intermediate value if a property changes several times in quick succession. If you need to support versions before iOS 26, you'll need a fallback built on withObservationTracking.

Part 5: What doesn’t migrate cleanly

Sharing one source with many subscribers

RxSwift’s share() and replay operators have no built-in equivalent. An AsyncStream is meant for a single consumer, so two tasks iterating the same stream compete for elements instead of each receiving all of them. Your options:

• Create a new stream per subscriber from a factory function.
• Keep a list of continuations in an actor and fan each value out to all of them.

If your codebase leans heavily on share(), budget extra time here.

Backpressure and buffering

By default an AsyncStream buffers without limit. If a fast producer feeds a slow consumer, choose a buffering policy such as .bufferingNewest(n) when you create the stream.

Operators with no direct equivalent

withLatestFrom, window, buffer and retry(when:) aren't in Async Algorithms' list of algorithms. In practice each becomes a small for await loop with a bit of local state, for example a variable holding the latest value from the other source.

Error handling

AsyncStream can't fail. Use AsyncThrowingStream when an error should end the stream, and wrap the loop in do/catch. Rx's catch, which switches to a fallback stream, has to be written by hand.

RxCocoa and UIKit

rx.text, rx.tap, rx.items and similar bindings have no direct counterpart. Typical replacements are:

• UIAction closures or target-action for taps
• Text field actions or delegates for text
• A diffable data source for table and collection views
• A Combine publisher’s .values to bridge into async/await

Swift 6 strict concurrency

Values crossing actor boundaries must be Sendable, so expect compiler diagnostics as you move Rx closures into Task closures. Long-lived tasks that capture self should use [weak self] if they can outlive the object.

Testing

RxTest and TestScheduler don't carry over. You'll write async test methods, and for time-based logic you'll want an injectable clock rather than a test scheduler.

A safe migration plan

You don’t need a big-bang rewrite. A sequence that works well:

1. Start with one screen or feature, not the whole app.
2. Convert the leaves first. Turn Single-returning network and storage calls into async throws functions. Most call sites get simpler right away.
3. Bridge at the boundary. RxSwift 6.5 added await support, so you can iterate observable.values as an async sequence. Single, Completable, Driver, Signal and Infallible support it as well. That lets new async code consume old Rx code while you migrate.
4. Migrate view models screen by screen. BehaviorRelay and Driver become @Observable properties, and DisposeBag subscriptions become .task or stored Tasks.
5. Leave the hard operators for last. Anything built on share(), withLatestFrom or complex scheduling can stay in Rx until everything around it is gone.
6. Remove RxSwift and RxCocoa once no imports remain.

Quick reference: Who replaces Whom

Should you migrate?

If you’re starting a new SwiftUI app targeting iOS 17 or later, you can skip RxSwift entirely. If you have a large UIKit codebase with complex reactive pipelines, a gradual, feature-by-feature migration is usually wiser than a rewrite, and some Rx-heavy corners may be fine staying where they are.

Either way, the direction is clear. State belongs in @Observable, work belongs in async/await, and lifetime belongs to tasks.

Code samples are starting points. Compile them against your own toolchain, since Swift and OS releases keep evolving these APIs.

Wrapping up

RxSwift taught a whole generation of iOS developers to think in streams, and that way of thinking is still worth keeping. What’s changed is the tooling. Swift now gives you first-class ways to describe state, asynchronous work and cancellation, and for most apps those tools are simpler to read, easier to debug and don’t need a third-party dependency.

You don’t have to migrate everything at once. Convert one Single into an async function. Replace one BehaviorRelay with an @Observable property. Swap one DisposeBag for a .task. Each small step makes the code a little lighter, and the Rx-heavy corners can wait until you’re ready for them.

If you’ve already migrated, or you’re stuck on a pattern that doesn’t map cleanly, such as share() or withLatestFrom, I’d like to hear how you handled it. Leave a comment, and if this guide saved you some time, a clap or a follow helps other iOS developers find it.

Further reading

• Swift Async Algorithms announcement: https://www.swift.org/blog/swift-async-algorithms/
• SE-0475, Transactional Observation of Values (Swift Forums review thread): https://forums.swift.org/t/se-0475-transactional-observation-of-values/79224
• RxSwift 6.5.0 release notes (Swift Concurrency support): https://github.com/ReactiveX/RxSwift/releases/tag/6.5.0

Thanks for reading! If this guide helped, give it a clap 👏, repost it, or share it with an iOS developer who’s still wrestling with RxSwift.

When developers need to understand an application without access to its
source code, the process can involve several specialized tools, manual
analysis, and a lot of context switching. REA (Reverse Engineer
Anything) explores a different workflow: connect an AI coding agent to
reverse-engineering tools, let it investigate a target, and return
findings with evidence that can guide further questions or
implementation.

Project: github.com/morluto/rea

What is REA?

REA is an open-source toolkit that exposes reverse-engineering workflows
through a command-line interface (CLI) and the Model Context Protocol
(MCP). This lets compatible AI agents request analysis, inspect results,
and use those findings as context for follow-up work.

Depending on the target and configured tools, REA can help examine
native binaries, JavaScript and Electron applications, .NET assemblies,
application packages and resources, and aspects of runtime behavior.
Native analysis can surface items such as pseudocode, assembly, strings,
symbols, function calls, and references. Other workflows can map
JavaScript modules and imports or capture observable process behavior.

The key idea is not simply to ask an AI model to guess how an
application works. REA aims to give the agent access to analysis tools
and evidence it can use to support its conclusions.

How the workflow works

At a high level, the process looks like this:

1. Choose a target. Provide an application, binary, package, or
   other supported artifact that you are authorized to inspect.
2. Investigate with tools. The agent uses REA through MCP or the
   CLI to request relevant analysis.
3. Review evidence. Results can include technical details that help
   explain how a component behaves and how different parts relate.
4. Ask follow-up questions. The agent can use those findings to
   narrow its investigation rather than starting from assumptions each
   time.
5. Implement and test. If the goal is to build a compatible
   feature, the agent can use the findings as a starting point for an
   implementation that still needs validation.

For example, a developer might ask an agent to investigate how a search
feature is structured in an application, explain the evidence behind its
findings, and then help build a similar feature in a different codebase.

Why developers may find it useful

1. A more connected investigation process

Reverse engineering often involves moving between disassemblers,
decompilers, command-line utilities, and notes. REA provides a common
agent-facing workflow for supported tools, potentially reducing some of
that manual coordination.

2. Evidence can make explanations more useful

An AI-generated explanation is only as dependable as the information
behind it. REA emphasizes returning findings and evidence, giving
developers something concrete to inspect instead of relying solely on a
confident-sounding answer.

3. It can connect investigation with implementation

Understanding unfamiliar software and writing a new implementation are
usually separate activities. An agent-assisted workflow can keep
analysis and implementation in the same session, while allowing the
developer to adapt the result to their own architecture, requirements,
and technology stack.

4. Local analysis can help with control

REA describes its analysis as local. However, developers should still
check the data-handling policy of the AI model provider they use: tool
results sent to an agent may be processed under that provider’s terms.

The trade-offs to consider

REA is not a one-click source-code recovery tool. Decompiled pseudocode
and reconstructed relationships are not the same as the original source,
comments, design intent, or complete project history. Results may be
incomplete, and the agent can still misinterpret evidence.

Setup also depends on the type of target. The project currently requires
a compatible Node.js version and npm, while some deep native-binary
workflows need an additional analysis engine such as Hopper, Ghidra, or
IDA. Platform support and prerequisites vary by workflow, so users
should check the current documentation before starting.

There is also a practical validation cost. Any code created from
reverse-engineering findings needs review, tests, and checks for
behavioral differences, security issues, performance, and
maintainability. A plausible explanation is not proof that a recreated
feature is equivalent.

Finally, reverse engineering has legal, ethical, and contractual
boundaries. Use these tools for legitimate research, education,
interoperability, preservation, security work, or software you own or
are authorized to examine. Do not treat technical capability as
permission.

Getting started

The project’s current README documents setup and supported workflows. A common starting point is:

npx rea-agents setup

Review the setup changes, configure any required analysis provider, and
restart your compatible agent as instructed. Before analyzing a
particular target, check its requirements and the relevant guide in the
official repository.

• Repository:
  github.com/morluto/rea
• Setup and documentation: See the project’s README and linked
  guides for current requirements, supported agents, providers, and
  commands.

The bigger picture

REA reflects a broader direction in AI-assisted development: agents are
becoming more useful when they can call specialized tools and inspect
evidence, rather than working only from prompts and pasted code. Reverse
engineering is a demanding test of that idea because the input may be
incomplete, the tools are specialized, and conclusions need careful
verification.

The value will depend on the target, the quality of the evidence, the
configured tools, and the developer’s ability to evaluate the result.
For some investigations, REA may shorten the path from an unfamiliar
artifact to a useful explanation. For others, setup complexity and
manual verification may remain substantial.

The question worth exploring is this: if an AI agent can investigate
an application’s behavior and show the evidence, which parts of reverse
engineering become faster and which decisions should still stay firmly
with the developer?

💬 I’d love to hear your thoughts! Have you tried using AI agents for reverse engineering or analyzing unfamiliar codebases? What benefits or challenges have you experienced?

Explore the REA GitHub repository and share your thoughts in the comments.

Would you trust an AI agent to investigate an unfamiliar application? Why or why not?

If you found this article useful, consider sharing it with other developers, leaving a comment, and following for more articles on AI-assisted development, software architecture, and modern engineering tools.

Thanks again for reading. Happy coding! 🚀

A Different Way to Think About Data

Most developers learn to transform data with loops. Iterate, check a condition, append to a result array, return it. It works. It is also verbose, stateful, and harder to test than it needs to be.

Functional programming offers a different mental model. Instead of describing how to transform data step by step, you describe what the transformation is. The result is code that is shorter, more readable, and easier to combine into pipelines.

Swift has first-class support for this style. You have been using the pieces since Article 7 (closures). Now they come together.

map: Transform Every Element

map applies a transformation to every element and returns a new collection.

let prices = [10.0, 25.0, 8.5, 42.0]

// Loop style
var discounted: [Double] = []
for price in prices {
    discounted.append(price * 0.9)
}

// Functional style
let discounted = prices.map { $0 * 0.9 }
// [9.0, 22.5, 7.65, 37.8]

Same result. The functional version says exactly what it is: a 10% discount applied to every price. No accumulator variable, no loop management, no mutation.

let usernames = ["aryan", "riya", "dev"]
let displayNames = usernames.map { $0.capitalized }
// ["Aryan", "Riya", "Dev"]

struct User { let id: Int; let name: String }
let users = [User(id: 1, name: "Aryan"), User(id: 2, name: "Riya")]
let names = users.map { $0.name }
// ["Aryan", "Riya"]

map works on any Sequence and always returns an array of the same length.

filter: Keep What Passes

filter returns only the elements that satisfy a condition.

let scores = [45, 78, 92, 61, 88, 34, 95]

let passing = scores.filter { $0 >= 60 }
// [78, 92, 61, 88, 95]
let products = [
    Product(name: "Swift Book", inStock: true),
    Product(name: "Keyboard", inStock: false),
    Product(name: "Monitor", inStock: true)
]
let available = products.filter { $0.inStock }
// [Swift Book, Monitor]

The closure returns Bool. Elements that return true are kept. Elements that return false are dropped.

reduce: Collapse to a Single Value

reduce takes a collection and produces a single result by combining elements one at a time.

let numbers = [1, 2, 3, 4, 5]
let sum = numbers.reduce(0) { result, next in result + next }

// 15
// Shorthand with operator function
let sum = numbers.reduce(0, +)

// 15
let words = ["Swift", "is", "great"]
let sentence = words.reduce("") { $0 + ($0.isEmpty ? "" : " ") + $1 }
// "Swift is great"

The first argument is the initial value. The closure takes the accumulated result and the next element, and returns the new accumulated value.

// Real-world: total cart price with discount
struct CartItem { let price: Double; let quantity: Int }

let cart = [CartItem(price: 9.99, quantity: 2), CartItem(price: 24.99, quantity: 1)]
let total = cart.reduce(0.0) { $0 + ($1.price * Double($1.quantity)) }
// 44.97

Chaining: Build Pipelines

The real power comes from chaining transformations.

let orders = [
    Order(amount: 120.0, isPaid: true),
    Order(amount: 45.0, isPaid: false),
    Order(amount: 300.0, isPaid: true),
    Order(amount: 15.0, isPaid: false),
    Order(amount: 89.0, isPaid: true)
]

let totalPaidRevenue = orders
    .filter { $0.isPaid }         // keep paid orders
    .map { $0.amount }            // extract amounts
    .reduce(0, +)                 // sum them
// 509.0

Each step is a single, focused transformation. Read it top to bottom like a sentence. No intermediate variables, no mutation, no mental overhead tracking state.

flatMap: Transform and Flatten

flatMap is map followed by flattening one level of nesting.

let sentences = ["Swift is great", "Generics are powerful"]

let words = sentences.map { $0.split(separator: " ").map(String.init) }
// [["Swift", "is", "great"], ["Generics", "are", "powerful"]]
// Nested array - probably not what you want
let words = sentences.flatMap { $0.split(separator: " ").map(String.init) }
// ["Swift", "is", "great", "Generics", "are", "powerful"]
// Flat array - much more useful

// Flattening optional results
let strings = ["1", "two", "3", "four", "5"]
let numbers = strings.flatMap { Int($0) }
// [1, 3, 5] - nils removed, results flattened

When the transformation returns an array, flatMap merges all the resulting arrays into one.

compactMap: Remove Nils

compactMap maps and removes nil results in one step.

let inputs = ["42", "hello", "7", "world", "13"]
let numbers = inputs.compactMap { Int($0) }
// [42, 7, 13]

let rawIDs: [String?] = ["usr_1", nil, "usr_3", nil, "usr_5"]
let validIDs = rawIDs.compactMap { $0 }
// ["usr_1", "usr_3", "usr_5"]

This replaces a common pattern:

// Before
var result: [Int] = []
for str in inputs {
    if let n = Int(str) { result.append(n) }
}

// After
let result = inputs.compactMap { Int($0) }

Same output. Dramatically less code. No mutation.

zip: Combine Two Sequences

zip pairs elements from two sequences together.

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

let leaderboard = zip(names, scores).map { "\($0): \($1)" }
// ["Alice: 95", "Bob: 87", "Charlie: 92"]
// Sort by score descending
let ranked = zip(names, scores)
    .sorted { $0.1 > $1.1 }
    .map { "\($0.0): \($0.1)" }
// ["Alice: 95", "Charlie: 92", "Bob: 87"]

zip stops at the shorter sequence, so no index out of bounds risk.

sorted and Custom Comparators

let users = [
    User(name: "Riya", age: 25),
    User(name: "Aryan", age: 28),
    User(name: "Dev", age: 22)
]

// Sort by age ascending
let byAge = users.sorted { $0.age < $1.age }

// Sort by name
let byName = users.sorted { $0.name < $1.name }

// Sort by multiple criteria: age descending, then name ascending
let complex = users.sorted {
    if $0.age != $1.age { return $0.age > $1.age }
    return $0.name < $1.name
}

Real-World Pipeline: Processing an API Response

struct APIProduct: Decodable {
    let id: String
    let name: String
    let price: Double?
    let category: String
    let isAvailable: Bool
}

struct DisplayProduct {
    let id: String
    let title: String
    let formattedPrice: String
}
func processProducts(_ raw: [APIProduct]) -> [DisplayProduct] {
    raw
        .filter { $0.isAvailable && $0.price != nil }
        .filter { $0.category == "electronics" }
        .sorted { $0.price! < $1.price! }
        .prefix(10)
        .compactMap { product -> DisplayProduct? in
            guard let price = product.price else { return nil }
            return DisplayProduct(
                id: product.id,
                title: product.name.capitalized,
                formattedPrice: String(format: "$%.2f", price)
            )
        }
}

No mutation. No intermediate arrays. One clean pipeline from raw API data to display-ready models.

Interview Questions

Q: What is the difference between map, flatMap, and compactMap in Swift?

map transforms each element and returns an array of the same length. flatMap transforms each element where the transformation returns a sequence, then flattens all results into a single array. compactMap transforms each element, removes nil results, and returns an array of unwrapped values. Use map for one-to-one transformations, flatMap when each element produces multiple results, and compactMap when the transformation might fail and you want to silently drop failures.

Q: Why is the functional style preferred over loops for data transformation in Swift?

Functional transformations are declarative. They say what the result is rather than how to produce it step by step. This makes each step independently readable and testable. Chained transformations have no shared mutable state between steps, which eliminates a whole class of bugs. They also compose cleanly: adding a new filter or transform means adding one line to the chain rather than modifying existing loop logic.

Summary

• map transforms every element and returns an array of the same length.
• filter returns only elements that satisfy a condition.
• reduce collapses a collection to a single value.
• Chaining filter, map, and reduce creates readable, declarative data pipelines.
• flatMap maps and flattens one level of nesting in the result.
• compactMap maps and removes nil results in a single step.
• zip pairs elements from two sequences without risk of index out of bounds.
• sorted accepts a comparator closure and supports multi-criteria sorting.
• Functional transformations have no shared mutable state, making them easier to test and compose.

Practice

1. Beginner: Given let temperatures = [36.6, 37.2, 38.1, 36.9, 39.0, 37.5], use filter to find fever temperatures (above 37.5), map to format them as strings like "38.1°C", and reduce to find the average fever temperature.
2. Intermediate: You have let logs: [String] = ["ERROR: disk full", "INFO: app started", "ERROR: timeout", "DEBUG: request sent", "ERROR: auth failed"]. Use compactMap to extract only the error messages (remove the "ERROR: " prefix), sorted to alphabetize them, and produce a single summary string using reduce.
3. Advanced: Build a Pipeline<Input, Output> struct that wraps a transformation function. Add a then<NewOutput> method that chains another Pipeline, returning a new Pipeline<Input, NewOutput>. Use it to build a reusable product-processing pipeline that filters, sorts, and maps API products in a composable way. Show how individual pipeline steps can be unit tested in isolation.

What’s Next

Article 18: Swift Async/Await: Modern Concurrency Without the Callback Chaos

Functional programming gives you cleaner synchronous data transformations. Async/await gives you cleaner asynchronous ones. Before async/await, every network call, file read, and background task meant nested completion handlers and manual thread management. Swift 5.5 changed that entirely. It is one of the most impactful additions to the language in years.

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

If data pipelines just replaced a pile of loops in your head, tap 👏 up to 50 times and do 🔁. It helps this series reach developers still writing nested for-loops to transform API responses.

Follow me so Article 18 lands in your feed automatically. Async/await is next and it will change how you write every network call going forward.

See you in the next one. 🚀

Why Generics Exist

Without generics, you write the same logic multiple times for different types.

func printInt(_ value: Int) { print(value) }
func printString(_ value: String) { print(value) }
func printDouble(_ value: Double) { print(value) }

Three functions. Same body. Only the type differs. This does not scale. Generics solve it.

func printValue<T>(_ value: T) {
    print(value)
}

printValue(42)        // works
printValue("hello")   // works
printValue(3.14)      // works

One function. Any type. The compiler generates the right version for each call automatically.

Generic Functions

The <T> is a type parameter. It is a placeholder that Swift fills in at the call site.

func swap<T>(_ a: inout T, _ b: inout T) {
    let temp = a
    a = b
    b = temp
}

var x = 10
var y = 20
swap(&x, &y)

print(x, y)  // 20 10

var hello = "hello"
var world = "world"
swap(&hello, &world)

print(hello, world)  // world hello

T can be named anything. T and U are conventions for single and paired type parameters. Use descriptive names when the meaning matters: Element, Key, Value.

Generic Types

Structs, classes, and enums can all be generic.

struct Stack<Element> {
    private var storage: [Element] = []

    mutating func push(_ item: Element) {
        storage.append(item)
    }

    mutating func pop() -> Element? {
        storage.popLast()
    }

    var top: Element? {
        storage.last
    }

    var isEmpty: Bool {
        storage.isEmpty
    }
}

var intStack = Stack<Int>()
intStack.push(1)
intStack.push(2)
intStack.push(3)

print(intStack.pop())  // Optional(3)

var stringStack = Stack<String>()
stringStack.push("Swift")
stringStack.push("Generics")

print(stringStack.top)  // Optional("Generics")

One Stack implementation. Works for Int, String, User, or any type you throw at it. The type safety is fully preserved — an Stack<Int> cannot hold a String.

Type Constraints

Unconstrained generics can only use operations available on every type. To use specific capabilities, add a constraint.

// Without constraint — T could be anything, very limited
func bigger<T>(_ a: T, _ b: T) -> T {
    // Cannot use > here — not all types support it
}

// With Comparable constraint - now > is available
func bigger<T: Comparable>(_ a: T, _ b: T) -> T {
    a > b ? a : b
}

bigger(3, 7)        // 7
bigger("apple", "mango")  // "mango" - String is Comparable

Constraints can stack:

func findAndPrint<T: Comparable & CustomStringConvertible>(_ array: [T]) {
    if let max = array.max() {
        print("Max: \(max.description)")
    }
}

T must be both Comparable and CustomStringConvertible. The compiler enforces this at every call site.

Generic Constraints with where

The where clause adds constraints inline without cluttering the function signature.

func merge<T, U>(_ dict1: [T: U], _ dict2: [T: U]) -> [T: U] where T: Hashable {
    dict1.merging(dict2) { first, _ in first }
}

func allEqual<T: Collection>(_ collection: T) -> Bool where T.Element: Equatable {
    guard let first = collection.first else { return true }
    return collection.allSatisfy { $0 == first }
}

allEqual([1, 1, 1])       // true
allEqual(["a", "a", "b"]) // false

where is particularly useful when constraining associated types of protocols used as parameters.

Associated Types in Protocols

Protocols use associatedtype instead of <T> to define a generic requirement.

protocol Container {
    associatedtype Item
    mutating func add(_ item: Item)
    func contains(_ item: Item) -> Bool
    var count: Int { get }
}

struct Bag<T: Equatable>: Container {
    typealias Item = T
    private var items: [T] = []
    mutating func add(_ item: T) {
        items.append(item)
    }
    func contains(_ item: T) -> Bool {
        items.contains(item)
    }
    var count: Int { items.count }
}

var bag = Bag<String>()
bag.add("Swift")
bag.add("Generics")
print(bag.contains("Swift"))  // true
print(bag.count)              // 2

Associated types let protocols be generic without the angle bracket syntax. This is how Collection, Sequence, and IteratorProtocol in the standard library are designed.

Generic Extensions

Add behavior to a generic type conditionally.

extension Stack where Element: Equatable {
    func contains(_ item: Element) -> Bool {
        storage.contains(item)
    }
}

extension Stack: CustomStringConvertible where Element: CustomStringConvertible {
    var description: String {
        "[" + storage.map { $0.description }.joined(separator: ", ") + "]"
    }
}

contains only exists on stacks whose elements are Equatable. description only exists when elements have a string representation. The compiler adds exactly the right capabilities to each concrete type.

Real-World Pattern: Generic Network Layer

protocol APIEndpoint {
    associatedtype Response: Decodable
    var path: String { get }
    var method: HTTPMethod { get }
}

struct UsersEndpoint: APIEndpoint {
    typealias Response = [User]
    var path: String { "/users" }
    var method: HTTPMethod { .get }
}

struct CreateOrderEndpoint: APIEndpoint {
    typealias Response = Order
    var path: String { "/orders" }
    var method: HTTPMethod { .post }
}

class APIClient {
    func request<E: APIEndpoint>(_ endpoint: E) async throws -> E.Response {
        let url = URL(string: baseURL + endpoint.path)!
        let (data, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode(E.Response.self, from: data)
    }
}

let client = APIClient()
let users: [User] = try await client.request(UsersEndpoint())
let order: Order = try await client.request(CreateOrderEndpoint())

One request function handles every endpoint in the app. The return type is inferred automatically from the endpoint's associated type. No casting. No Any. Full type safety at every call site.

Interview Questions

Q: What are generics in Swift and why are they important?

Generics let you write functions and types that work with any type while preserving full type safety. Without generics, you either duplicate code for each type or lose type safety by using Any. Generics give you both: one implementation and compile-time guarantees. Swift's Optional, Result, Array, Dictionary, and most of the standard library are built on generics. They are the foundation of reusable, type-safe code in Swift.

Q: What is the difference between a generic type parameter and a protocol associated type?

A generic type parameter is declared at the point of use with angle brackets: func foo<T>(_ value: T). The caller decides what T is. A protocol associated type is declared inside a protocol with associatedtype. The conforming type decides what the associated type is. Generic parameters are for functions and types you write directly. Associated types are for protocols that need to express relationships between types without specifying them up front.

Summary

• Generics let you write one implementation that works with any type safely.
• Type parameters like <T> are placeholders filled in at the call site.
• Constraints like <T: Comparable> restrict which types are allowed and unlock specific capabilities.
• The where clause adds constraints without cluttering the signature.
• Structs, classes, enums, and functions can all be generic.
• Protocol associated types are the protocol-side equivalent of generic type parameters.
• Generic extensions with constraints add behavior only when the element type qualifies.
• The entire Swift standard library and most production network layers are built on generics.

Practice

1. Beginner: Write a generic pairs<T>(_ array: [T]) -> [(T, T)] function that returns consecutive pairs from an array: [1,2,3,4] becomes [(1,2), (2,3), (3,4)]. Handle arrays with fewer than two elements gracefully.
2. Intermediate: Build a generic Cache<Key: Hashable, Value> struct with set(_ value: Value, for key: Key), get(_ key: Key) -> Value?, and remove(_ key: Key) methods. Add a maxSize: Int parameter that evicts the oldest entry when the cache is full.
3. Advanced: Design a type-safe EventBus<Event> using generics and associated types. Publishers post events of a specific type. Subscribers receive only the event type they registered for. The compiler should prevent subscribing to the wrong event type entirely, with no casting at the call site. Show it working with at least two distinct event types.

What’s Next

Article 17: Functional Programming in Swift: map, filter, reduce, and Beyond

Generics make your types flexible. Functional programming makes your logic composable. map, filter, reduce, flatMap, compactMap, and zip are not just collection utilities. They are a fundamentally different way of thinking about data transformation. Once they click, you will find yourself writing cleaner, shorter, and more testable code across every layer of your app.

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

If generics finally make sense as a design tool rather than just syntax, tap 👏 up to 50 times and do 🔁. It helps this series reach developers still copying functions to handle different types.

Follow me so Article 17 lands in your feed automatically. Functional programming is next and it pairs perfectly with everything you just learned.

See you in the next one. 🚀

Why Memory Management Matters in Production

An app that leaks memory does not crash immediately. It slows down. It gets warm. It consumes more RAM with every navigation until iOS kills it in the background or the user force-quits it in frustration. Memory bugs are silent killers and they are almost always caused by the same small set of patterns.

Understanding ARC is not optional knowledge for senior iOS engineers. It is foundational.

What ARC Does

Automatic Reference Counting tracks how many references point to each class instance. When that count reaches zero, ARC deallocates the object and reclaims the memory.

class User {
    let name: String

    init(name: String) {
        self.name = name
        print("\(name) initialized")
    }
    deinit {
        print("\(name) deallocated")
    }
}

var ref1: User? = User(name: "Aryan")  // count: 1 - "Aryan initialized"
var ref2 = ref1                         // count: 2
var ref3 = ref1                         // count: 3
ref1 = nil  // count: 2
ref2 = nil  // count: 1
ref3 = nil  // count: 0 - "Aryan deallocated"

ARC runs at compile time, not runtime. It inserts retain and release calls for you. No garbage collector, no pauses, no unpredictable cleanup timing.

Strong References: The Default

Every regular reference is strong. It increments the reference count and keeps the object alive.

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

let team = Team(name: "iOS")  // strong reference - count: 1

Most of the time, strong is exactly what you want. The object lives as long as someone holds a reference to it.

Retain Cycles: When ARC Gets Stuck

A retain cycle happens when two objects hold strong references to each other. Neither count reaches zero. Neither object ever deallocates.

class Author {
    var name: String
    var article: Article?

    init(name: String) { self.name = name }
    deinit { print("\(name) deallocated") }
}

class Article {
    var title: String
    var author: Author?  // strong reference back to Author
    init(title: String) { self.title = title }
    deinit { print("\(title) deallocated") }
}

var author: Author? = Author(name: "Aryan")
var article: Article? = Article(title: "Swift ARC")
author?.article = article  // Author -> Article (strong)
article?.author = author   // Article -> Author (strong)
author = nil   // Author count: still 1 (Article holds it)
article = nil  // Article count: still 1 (Author holds it)
// deinit never called - both objects leak

Two objects, each keeping the other alive. The external references are gone but the cycle keeps both counts above zero forever.

Weak References: Breaking the Cycle

A weak reference does not increment the reference count. It does not keep the object alive. If the object deallocates, the weak reference automatically becomes nil.

class Article {
    var title: String
    weak var author: Author?  // weak — does not keep Author alive
    init(title: String) { self.title = title }
    deinit { print("\(title) deallocated") }
}

var author: Author? = Author(name: "Aryan")
var article: Article? = Article(title: "Swift ARC")
author?.article = article
article?.author = author
author = nil   // Author count: 0 - "Aryan deallocated"
article = nil  // Article count: 0 - "Swift ARC deallocated"

Cycle broken. Both objects deallocate cleanly.

Weak references must be var and optional. They can become nil at any time, so the compiler requires you to treat them as Optional.

Unowned References: The Riskier Option

An unowned reference also does not increment the reference count. The difference: it does not become nil when the object deallocates. Accessing an unowned reference after deallocation crashes the app.

class Customer {
    var name: String
    var card: CreditCard?
    init(name: String) { self.name = name }
    deinit { print("\(name) deallocated") }
}

class CreditCard {
    let number: String
    unowned let customer: Customer  // card cannot outlive the customer
    init(number: String, customer: Customer) {
        self.number = number
        self.customer = customer
    }
    deinit { print("Card \(number) deallocated") }
}

var customer: Customer? = Customer(name: "Aryan")
customer?.card = CreditCard(number: "4111", customer: customer!)
customer = nil
// "Aryan deallocated"
// "Card 4111 deallocated"

Use unowned only when you are certain the referenced object will always outlive the referencing one. If there is any doubt, use weak. A crash from an invalid unowned reference is harder to diagnose than an unexpected nil.

The Closure Retain Cycle

Closures are the most common source of retain cycles in real iOS code. A closure stored as a property captures self strongly by default. If self also holds the closure, you have a cycle.

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

    func setup() {
        onPlaybackEnd = {
            self.reset()  // strong capture of self
        }
        // VideoPlayer holds onPlaybackEnd
        // onPlaybackEnd holds VideoPlayer
        // cycle
    }

    func reset() { }
    deinit { print("VideoPlayer deallocated") }
}

Fix with a capture list:

onPlaybackEnd = { [weak self] in
    self?.reset()
}

This is the pattern from Article 7 (Closures) viewed through the lens of ARC. The capture list makes the closure’s reference to self weak. The cycle breaks. self deallocates when its external references are gone.

Finding Leaks with Instruments

Xcode’s Memory Graph Debugger is your first tool for finding retain cycles:

1. Run your app in Xcode
2. Navigate to the screen you suspect is leaking
3. Navigate away
4. Click the Memory Graph button in the Debug bar
5. Look for objects that should have deallocated but still appear in the graph

Instruments’ Leaks and Allocations templates go deeper for production profiling. Any object shown in the memory graph after it should have been released is a candidate for investigation.

Real-World Patterns That Leak (and Their Fixes)

Timer retain cycle:

// Leak — Timer holds a strong reference to self
class ClockView {
    var timer: Timer?

    func start() {
        timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { _ in
            self.updateDisplay()  // strong capture
        }
    }
}

// Fix
timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { [weak self] _ in
    self?.updateDisplay()
}

Delegate retain cycle:

// Leak — strong delegate creates a cycle
class DataLoader {
    var delegate: DataLoaderDelegate?  // strong
}

// Fix - delegates are almost always weak
class DataLoader {
    weak var delegate: DataLoaderDelegate?
}

NotificationCenter observer not removed:

// Leak in older APIs — observer not removed
class ViewController: UIViewController {
    override func viewDidLoad() {
        NotificationCenter.default.addObserver(
            self,
            selector: #selector(handleUpdate),
            name: .dataUpdated,
            object: nil
        )
    }
    // Fix: remove in deinit or use the block-based API with [weak self]
    deinit {
        NotificationCenter.default.removeObserver(self)
    }
}

Interview Questions

Q: What is a retain cycle and how do you fix one in Swift?

A retain cycle occurs when two or more objects hold strong references to each other, preventing ARC from ever reducing either object’s reference count to zero. Both objects leak. The fix is to break the cycle by making one reference weak or unowned. Use weak when the referenced object can outlive the referencing one and may become nil. Use unowned only when you can guarantee the referenced object always outlives the referencing one.

Q: What is the difference between weak and unowned in Swift?

Both are non-retaining references that do not increment ARC’s reference count. weak is always optional and automatically becomes nil when the referenced object deallocates. unowned is non-optional and does not become nil. Accessing an unowned reference after the object deallocates causes a crash. Use weak when the referenced object might deallocate before the referencing one. Use unowned when you can guarantee it will not.

Summary

• ARC automatically tracks reference counts for class instances and deallocates them at zero.
• Strong references are the default and keep objects alive.
• Retain cycles occur when objects hold strong references to each other, preventing deallocation.
• weak references do not retain, are always optional, and become nil on deallocation.
• unowned references do not retain and are non-optional. Accessing them after deallocation crashes.
• Closures capture self strongly by default. Use [weak self] capture lists to break cycles.
• Delegates should almost always be weak.
• Timers, notification observers, and stored closures are the most common real-world leak sources.
• Use Xcode’s Memory Graph Debugger and Instruments to detect leaks before they reach production.

Practice

1. Beginner: Create two classes, Parent and Child, where Parent has a strong reference to Child and Child has a strong reference back to Parent. Add deinit to both and verify they never print. Then fix the cycle using weak and verify both deinit calls fire.
2. Intermediate: Build a EventBus class that stores an array of closures as subscribers. Show how a subscriber that captures self strongly creates a leak when the subscribing object deallocates. Fix it using [weak self] and clean up nil subscribers from the array automatically.
3. Advanced: Profile a UIViewController subclass in Instruments that has a retain cycle caused by a Timer and a stored closure. Document exactly which reference is causing the cycle, fix it, and verify the deallocation in the Memory Graph Debugger. Write a brief post-mortem explaining the root cause, the fix, and the general rule it illustrates.

What’s Next

Article 16: Swift Generics: Write Once, Use Everywhere

ARC taught you how Swift manages the lifetime of objects in memory. Generics teach you how to write code that works across types without duplicating logic. They are the foundation of Swift’s collections, Result, Optional, and almost every reusable component you will ever build.

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

If ARC finally clicked and you can see where your app might be leaking, tap 👏 up to 50 times. It helps this series reach developers shipping apps with silent memory bugs.

Follow me so Article 16 lands in your feed automatically. Generics are next and they will change how you write reusable code forever.

See you in the next one. 🚀

Why Error Handling Is Not Optional

Every app fails sometimes. Networks go down. Files go missing. Users enter bad data. JSON arrives malformed. The question is never whether your app will encounter errors. It is whether your code handles them deliberately or discovers them as crashes.

Swift’s error system makes deliberate handling the only option. If a function can throw, the compiler forces you to acknowledge that before your code builds. You cannot forget. You cannot ignore it. That guarantee is worth more than it might seem.

Defining Errors

Swift errors conform to the Error protocol. Enums are the natural fit because they enumerate exactly what can go wrong.

enum NetworkError: Error {
    case invalidURL
    case noConnection
    case timeout(after: TimeInterval)
    case serverError(statusCode: Int)
    case decodingFailed(reason: String)
}

Each case is a distinct, named failure. No integer error codes. No string comparisons. The compiler knows every possible error at compile time.

Throwing Functions

Mark a function with throws to indicate it can fail.

func fetchUser(id: String) throws -> User {
    guard !id.isEmpty else {
        throw NetworkError.invalidURL
    }
    
    // Simulate fetch
    guard let user = database[id] else {
        throw NetworkError.serverError(statusCode: 404)
    }
    return user
}

The throws keyword is part of the function signature. Any caller can see at a glance that this function might fail.

Calling Throwing Functions

You must use try when calling a throwing function. Then handle the error with do/catch.

do {
    let user = try fetchUser(id: "usr_001")
    print("Found: \(user.name)")
} catch NetworkError.invalidURL {
    print("The URL was invalid")
} catch NetworkError.serverError(let code) {
    print("Server returned \(code)")
} catch NetworkError.timeout(let seconds) {
    print("Request timed out after \(seconds)s")
} catch {
    // Catches everything else
    print("Unexpected error: \(error)")
}

Swift’s catch supports full pattern matching, including associated values. The final bare catch is your safety net for anything you did not explicitly anticipate.

try? and try!

Two shorthand options when you need less ceremony.

// try? — converts the result to Optional, nil on failure
let user = try? fetchUser(id: "usr_001")
// user is User? — nil if fetchUser threw anything

// try! - force unwraps the result, crashes if it throws
let user = try! fetchUser(id: "usr_001")
// Crashes at runtime if fetchUser throws

try? is useful when failure is acceptable and you just want a nil. Loading a cached image, for example. If the cache misses, nil is fine.

try! is the same risk as force-unwrapping an optional. Use it only when you are certain the function cannot throw in this context, and document why.

Propagating Errors

Throwing functions can propagate errors up the call stack instead of handling them immediately. Mark the caller as throws too.

func loadUserProfile(id: String) throws -> UserProfile {
    let user = try fetchUser(id: id)       // propagates if this throws
    let posts = try fetchPosts(for: user)  // propagates if this throws
    return UserProfile(user: user, posts: posts)
}

The error bubbles up until something catches it. This lets you handle errors at the right layer instead of wrapping every function call in do/catch.

Result<Success, Failure>: Errors as Values

Result is Swift's enum for representing success or failure as a value rather than through throwing.

enum Result<Success, Failure: Error> {
    case success(Success)
    case failure(Failure)
}

Use it when you need to store an error, pass it to a completion handler, or work with APIs that use callbacks instead of async/await.

func fetchUser(id: String, completion: @escaping (Result<User, NetworkError>) -> Void) {
    guard !id.isEmpty else {
        completion(.failure(.invalidURL))
        return
    }

    // Simulate async fetch
    DispatchQueue.global().asyncAfter(deadline: .now() + 1) {
        if let user = self.database[id] {
            completion(.success(user))
        } else {
            completion(.failure(.serverError(statusCode: 404)))
        }
    }
}

// Call site
fetchUser(id: "usr_001") { result in
    switch result {
    case .success(let user):
        print("Loaded: \(user.name)")
    case .failure(let error):
        print("Failed: \(error)")
    }
}

Result makes the success and failure paths explicit and equal. No hidden optional, no separate error parameter.

Converting Between throws and Result

Swift makes this seamless.

// throws -> Result
let result = Result { try fetchUser(id: "usr_001") }

// Result -> throws
let user = try result.get()

Result { } captures any thrown error into .failure. .get() throws the failure back out. Use whichever style fits the surrounding code.

rethrows: Conditional Throwing

A function marked rethrows only throws if one of its closure parameters throws.

func transform<T>(_ values: [T], using block: (T) throws -> T) rethrows -> [T] {
    try values.map(block)
}

// Non-throwing closure - transform doesn't throw
let doubled = transform([1, 2, 3]) { $0 * 2 }
// Throwing closure - transform can throw
let parsed = try transform(["1", "two", "3"]) { str in
    guard let int = Int(str) else { throw ParseError.invalid(str) }
    return int
}

rethrows is how map, filter, and forEach in the standard library work. They only require try when the closure you pass them throws.

Real-World Pattern: Layered Error Handling

Production apps translate low-level errors into user-facing messages at the right layer.

enum AppError: Error, LocalizedError {
    case networkUnavailable
    case sessionExpired
    case contentNotFound
    case unknown(Error)

    var errorDescription: String? {
        switch self {
        case .networkUnavailable:  return "Check your internet connection and try again."
        case .sessionExpired:      return "Your session has expired. Please log in again."
        case .contentNotFound:     return "This content is no longer available."
        case .unknown:             return "Something went wrong. Please try again."
        }
    }
}

func mapToAppError(_ error: Error) -> AppError {
    guard let networkError = error as? NetworkError else {
        return .unknown(error)
    }
    switch networkError {
    case .noConnection:            return .networkUnavailable
    case .serverError(401):        return .sessionExpired
    case .serverError(404):        return .contentNotFound
    default:                       return .unknown(error)
    }
}

Low-level network errors stay in the networking layer. The app layer speaks in user-friendly terms. The view just reads errorDescription and displays it. Each layer handles what it knows about.

Interview Questions

Q: What is the difference between throws and Result in Swift error handling?

throws uses Swift's built-in error propagation mechanism. The compiler forces callers to use try and either handle or propagate the error. Result represents success or failure as a value in an enum. Use throws for synchronous code and async/await-based APIs where the compiler can enforce error handling directly. Use Result for completion handler-based APIs, when you need to store or pass an error as a value, or when working with older callback-based code.

Q: What does rethrows mean in Swift?

rethrows marks a function that only throws if one of the closure parameters it receives throws. If you pass a non-throwing closure, the function itself does not throw and no try is needed at the call site. If you pass a throwing closure, the function can rethrow that error. This is how standard library functions like map and filter work cleanly with both throwing and non-throwing closures.

Summary

• Swift errors conform to Error. Enums with associated values are the cleanest modeling tool.
• throws in a function signature tells every caller: this can fail.
• do/catch handles errors with full pattern matching, including associated values.
• try? converts failure to nil. try! crashes on failure. Use both sparingly.
• Errors propagate up the call stack until something catches them.
• Result<Success, Failure> represents success or failure as a value, ideal for completion handlers.
• Result { try... } captures thrown errors. .get() throws them back out.
• rethrows only propagates errors when a closure parameter itself throws.
• Translate low-level errors into user-facing messages at the appropriate architectural layer.

Practice

1. Beginner: Create a divide(_ a: Double, by b: Double) throws -> Double function that throws a MathError.divisionByZero case when b is zero. Call it with do/catch, with try?, and with try!. Explain when each is appropriate.
2. Intermediate: Build a JSONLoader struct with a load<T: Decodable>(_ filename: String) throws -> T method that reads a JSON file from the app bundle and decodes it. Define a FileError enum covering file not found, read failure, and decoding failure with associated error messages. Chain the error propagation correctly so callers see meaningful errors.
3. Advanced: Create a Validator<T> struct that takes an array of (T) throws -> Void validation rules. Add a validate(_ value: T) -> Result<T, ValidationError> method where ValidationError collects all failures, not just the first one. Use rethrows where appropriate and write a concrete example validating a RegistrationForm struct with rules for username length, email format, and password strength.

What’s Next

Article 15: ARC and Memory Management: How Swift Keeps Your App From Leaking

You now know how Swift handles errors at the language level. Next: how it handles memory. Automatic Reference Counting is what keeps your objects alive exactly as long as they need to be and no longer. Understanding ARC, strong references, weak references, and retain cycles is what separates developers who write leak-free apps from those who find memory problems in production.

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

If Swift’s error system just made your failure handling more intentional, tap 👏 up to 50 times and do 🔁. It helps this series reach developers still using optional returns where errors belong.

Follow me so Article 15 lands in your feed automatically. Memory management is next and it is one of the most important topics for shipping stable iOS apps.

See you in the next one. 🚀

Why Extensions Are One of Swift’s Best Features

Most languages let you add behavior to a type by subclassing it or modifying it directly. Swift offers a third path: extend any type, anywhere, without touching the original source.

You can add methods to String. Computed properties to Int. Protocol conformances to types from third-party libraries. Namespace your own code into focused, readable chunks. Extensions make all of this clean and compiler-safe.

The Basics

extension String {
    func trimmed() -> String {
        trimmingCharacters(in: .whitespacesAndNewlines)
    }
    
    var isBlank: Bool {
        trimmed().isEmpty
    }
}

let input = "  hello  "
print(input.trimmed())  // "hello"
print(input.isBlank)    // false
print("   ".isBlank)    // true

Every String in your entire project now has trimmed() and isBlank. No subclass, no wrapper type, no helper function hidden in a utility file.

What You Can Add in an Extension

Extensions support a wide range of additions:

extension SomeType {
    // Computed properties (stored properties are not allowed)
    var computedValue: Int { ... }

    // Methods
    func doSomething() { ... }
    // Initializers (convenience, not designated for classes)
    init(someParam: String) { ... }
    // Subscripts
    subscript(key: String) -> String? { ... }
    // Nested types
    enum State { case active, inactive }
}

One important limit: extensions cannot add stored properties. You can add computed properties that derive their value, but you cannot add new memory to an existing type from outside its definition.

Extending Your Own Types for Organization

Extensions are not just for adding new behavior to foreign types. They are one of the cleanest ways to organize your own code.

struct UserViewModel {
    let user: User
    var isLoading: Bool
    var errorMessage: String?
}

// Core data
extension UserViewModel {
    var displayName: String {
        user.name.isEmpty ? "Anonymous" : user.name
    }
    var avatarInitials: String {
        String(user.name.prefix(2)).uppercased()
    }
}
// Actions
extension UserViewModel {
    mutating func refresh() {
        isLoading = true
        errorMessage = nil
    }
    mutating func handleError(_ error: Error) {
        isLoading = false
        errorMessage = error.localizedDescription
    }
}

Split by responsibility, not by arbitrary line count. Each extension block has one clear purpose. New team members find what they need faster.

Protocol Conformance in Separate Extensions

This is the pattern you will see in every serious Swift codebase.

struct Product {
    let id: String
    let name: String
    let price: Double
}

// Core type stays clean
// Conformances are declared separately
extension Product: Equatable {
    static func == (lhs: Product, rhs: Product) -> Bool {
        lhs.id == rhs.id
    }
}

extension Product: Comparable {
    static func < (lhs: Product, rhs: Product) -> Bool {
        lhs.price < rhs.price
    }
}

extension Product: CustomStringConvertible {
    var description: String {
        "\(name) - $\(String(format: "%.2f", price))"
    }
}

Each conformance lives in its own extension block. When you search for “Equatable” in your file, you find it immediately. When you delete a conformance, you delete one focused block, not lines scattered through the original type.

Extending Apple’s Types

This is where extensions genuinely change how you write daily code.

extension Int {
    var isEven: Bool { self % 2 == 0 }
    var isOdd: Bool { !isEven }
    
    func times(_ action: () -> Void) {
        for _ in 0..<self { action() }
    }
}

5.times { print("hello") }  // prints "hello" 5 times
print(4.isEven)              // true

extension Double {
    var asPercentage: String {
        String(format: "%.1f%%", self * 100)
    }
}

print(0.856.asPercentage)  // "85.6%"

extension Array {
    func chunked(into size: Int) -> [[Element]] {
        stride(from: 0, to: count, by: size).map {
            Array(self[$0..<Swift.min($0 + size, count)])
        }
    }
}

let pages = [1,2,3,4,5,6,7].chunked(into: 3)
// [[1,2,3], [4,5,6], [7]]

extension Optional where Wrapped == String {
    var orEmpty: String {
        self ?? ""
    }
}

let name: String? = nil
print(name.orEmpty)  // ""

These are not clever tricks. They are the kind of extensions that end up in every production iOS codebase because they eliminate repetitive unwrapping and formatting code across hundreds of files.

Extensions with Constraints

You can limit an extension to only apply when generic type parameters meet a condition.

extension Array where Element: Numeric {
    var sum: Element {
        reduce(0, +)
    }
    
    var average: Double {
        guard !isEmpty else { return 0 }
        return Double(sum as! Double) / Double(count)
    }
}

[1, 2, 3, 4, 5].sum  // 15

Or for your own generic types:

extension Stack where T: Equatable {
    func contains(_ value: T) -> Bool {
        storage.contains(value)
    }
}

The contains method only exists when the stack holds Equatable elements. The compiler enforces this. You don't need runtime checks.

What Extensions Cannot Do

A few limits worth knowing upfront:

extension String {
    // ❌ Cannot add stored properties
    var someStoredValue: Int = 0

    // ❌ Cannot override existing methods (use subclassing for that)
    // override func hasPrefix(_ prefix: String) -> Bool { ... }
}

Extensions also cannot add designated initializers to classes or add deinit. These rules keep extensions predictable: they add to a type, they don't restructure it.

Real-World Pattern: UIColor Extension

extension UIColor {
    convenience init(hex: String) {
        var hexSanitized = hex.trimmingCharacters(in: .whitespacesAndNewlines)
        hexSanitized = hexSanitized.replacingOccurrences(of: "#", with: "")
      
        var rgb: UInt64 = 0
        Scanner(string: hexSanitized).scanHexInt64(&rgb)
        let r = CGFloat((rgb & 0xFF0000) >> 16) / 255
        let g = CGFloat((rgb & 0x00FF00) >> 8) / 255
        let b = CGFloat(rgb & 0x0000FF) / 255
        self.init(red: r, green: g, blue: b, alpha: 1)
    }

    static let brandPrimary = UIColor(hex: "#4A90E2")
    static let brandSecondary = UIColor(hex: "#F5A623")
}

// Usage
view.backgroundColor = .brandPrimary
label.textColor = UIColor(hex: "#333333")

This is a convenience initializer added to UIColor from Apple's UIKit. You cannot modify UIKit's source. Extensions make this possible cleanly.

Interview Questions

Q: What can and cannot be added to a type via an extension in Swift?

Extensions can add computed properties, methods, initializers (convenience initializers for classes), subscripts, nested types, and protocol conformances. They cannot add stored properties, cannot override existing implementations (that requires subclassing), and cannot add designated initializers or deinit to classes. The constraint on stored properties exists because extensions cannot change the memory layout of a type defined elsewhere.

Q: Why do senior Swift engineers put protocol conformances in separate extension blocks?

Separating conformances into distinct extensions makes each one easy to find, reason about, and delete independently. When you search for Equatable conformance, you find one focused block rather than code scattered through the main type definition. It also makes code review cleaner: a diff that adds Codable conformance via an extension is immediately understandable without reading the entire type.

Summary

• Extensions add computed properties, methods, initializers, subscripts, and protocol conformances to any type.
• Extensions cannot add stored properties or override existing methods.
• Organizing your own types into focused extension blocks by responsibility improves readability and navigation.
• Protocol conformances in separate extension blocks make each conformance easy to find and remove.
• Constrained extensions apply only when generic parameters meet specific requirements.
• Extensions on Apple’s types like String, Array, and UIColor eliminate repetitive utility code across a codebase.

Practice

1. Beginner: Write extensions on String for isValidEmail: Bool (basic format check), wordCount: Int, and capitalizingFirstLetter() -> String. Use them in a form validation function.
2. Intermediate: Extend Array with three useful methods: second: Element? (returns the second element safely), groupedBy<Key: Hashable>(_ keyPath: KeyPath<Element, Key>) -> [Key: [Element]], and removingDuplicates() -> [Element] where Element: Equatable. Write tests for each.
3. Advanced: Create a UserDefaults extension that uses a generic subscript with Codable constraints to read and write any Codable type. Use @propertyWrapper style with a custom Persisted<T: Codable> wrapper that reads from and writes to UserDefaults automatically. Show how it eliminates boilerplate compared to raw UserDefaults usage.

What’s Next

Article 14: Swift Error Handling: throw, try, catch, and Result

Extensions make your types richer. Error handling makes them honest. Swift’s error system is not just try/catch ported from other languages. It is a compile-enforced mechanism that forces you to acknowledge every failure path before your code builds. Combined with Result<T, Error>, it becomes one of the cleanest error propagation systems in any modern language.

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

If extensions changed how you think about organizing code, tap 👏 up to 50 times. It helps this series reach developers still writing utility helper files full of free functions.

Follow me so Article 14 lands in your feed the moment it goes live. Error handling is next and it is far more powerful than most developers realize.

See you in the next one. 🚀

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. 🚀