Swift By Rahul
October 13, 2026 · 10 min read ·

Understanding Type Erasure in Swift

Swift's protocol-oriented programming paradigm empowers us to write flexible and modular code. Protocols allow us to define contracts that types can conform to, enabling polymorphism and abstracting away implementation details. However, as you delve deeper into Swift, you'll inevitably encounter a common challenge: protocols with associated types, often referred to as PATs. These powerful constructs, while incredibly useful for creating generic algorithms and data structures, introduce a limitation: you cannot use a PAT directly as a concrete type.

This is where Type Erasure comes into play. It's a fundamental pattern in Swift that allows us to work around this limitation, enabling us to treat disparate types that conform to the same protocol (even with associated types) in a uniform, concrete manner. If you've ever wondered why Array<AnyHashable> works, or how SwiftUI's AnyView operates, you've already seen type erasure in action.

In this article, we'll demystify type erasure. We'll explore the problem it solves, how it's implemented, and when it's a valuable tool in your Swift development arsenal.

The Problem: Protocols with Associated Types (PATs)

Let's start by understanding the "why." Consider a common scenario where you want to define a protocol for an operation that takes an input and produces an output. The types of this input and output might vary depending on the specific operation.

protocol Operation {
    associatedtype Input
    associatedtype Output

    func execute(input: Input) -> Output
}

This Operation protocol is a perfect candidate for an associated type. It allows us to define operations like:

struct UppercaseOperation: Operation {
    typealias Input = String
    typealias Output = String

    func execute(input: String) -> String {
        return input.uppercased()
    }
}

struct AddOperation: Operation {
    typealias Input = (Int, Int)
    typealias Output = Int

    func execute(input: (Int, Int)) -> Int {
        return input.0 + input.1
    }
}

These are distinct concrete types, each conforming to Operation but with different Input and Output types. Now, imagine you want to store a collection of these operations, or perhaps pass them around in a function parameter.

You might instinctively try something like this:

// This won't compile!
// var operations: [Operation] = [] // Error: Protocol 'Operation' can only be used as a generic constraint

The Swift compiler will greet you with an error message similar to: "Protocol 'Operation' can only be used as a generic constraint because it has Self or associated type requirements."

Why does this happen? The compiler needs to know the exact size and type information of an object at compile time to allocate memory and perform operations efficiently. When you use a protocol directly, especially one with an associated type, the compiler doesn't have enough information. Operation itself is not a concrete type; it's a blueprint. The Input and Output types are placeholders (associatedtype) that are only resolved when a concrete type conforms to the protocol. The compiler can't create an array of Operation because it doesn't know what Input and Output types each element in that array would hold. They could be String, Int, (Int, Int), or anything else.

The Problem with Protocols with Associated Types (PATs) Protocol Operation (associatedtype Input/Output) UppercaseOperation (Input: String, Output: String) AddOperation (Input: (Int, Int), Output: Int) Cannot use `Operation` as a concrete type (e.g., `[Operation]`)! Compiler Error: "generic constraint"

This restriction means that while protocols with associated types are incredibly powerful for defining generic behaviors, they can't be used directly in contexts that require a concrete type, such as arrays, non-generic function parameters, or stored properties.

The Solution: Type Erasure

Type erasure is a design pattern that wraps an instance of a type conforming to a protocol with associated types inside another concrete, non-generic type. This wrapper type then "erases" the specific associated types by providing a uniform interface that doesn't expose the underlying generic details.

The core idea is to create a new type (often a struct or class) that: 1. Is generic over the associated types it wishes to "fix" or "erase." 2. Stores a reference to the underlying concrete instance conforming to the PAT. 3. Implements the original protocol by forwarding all method calls to the underlying instance. 4. Provides an initializer that takes any type conforming to the PAT, as long as its associated types match the wrapper's generic parameters.

Let's build a type-erased wrapper for our Operation protocol, which we'll call AnyOperation.

struct AnyOperation<Input, Output>: Operation {
    // 1. Private closures to store the underlying operation's logic.
    // These closures capture the specific 'execute' implementation
    // from the concrete type.
    private let _execute: (Input) -> Output

    // 2. The initializer takes any ConcreteOperation that conforms
    // to our 'Operation' protocol, provided its Input and Output
    // types match the generic parameters of 'AnyOperation'.
    init<ConcreteOperation: Operation>(_ operation: ConcreteOperation)
    where ConcreteOperation.Input == Input, ConcreteOperation.Output == Output {
        _execute = operation.execute // Capture the execute method
    }

    // 3. The wrapper itself conforms to 'Operation' with concrete Input/Output.
    // Its 'execute' method simply calls the stored closure.
    func execute(input: Input) -> Output {
        return _execute(input)
    }
}

With AnyOperation, we've created a type that itself conforms to Operation, but with specific, concrete Input and Output types (e.g., AnyOperation<String, String>). This allows us to use it in contexts where the raw Operation protocol could not be used.

Now, we can create a collection of operations that all work with String input and String output:

let uppercaseOp = UppercaseOperation()
let reverseOp = ReverseOperation() // Assuming you have a ReverseOperation: Operation where Input/Output are String

struct ReverseOperation: Operation {
    typealias Input = String
    typealias Output = String
    func execute(input: String) -> String {
        return String(input.reversed())
    }
}

// Now we can store them in an array!
var stringOperations: [AnyOperation<String, String>] = [
    AnyOperation(uppercaseOp),
    AnyOperation(reverseOp)
]

let result1 = stringOperations[0].execute(input: "hello") // "HELLO"
let result2 = stringOperations[1].execute(input: "world") // "dlrow"

print(result1) // HELLO
print(result2) // dlrow

// We can also define and use an operation with different types:
let addOp = AddOperation()
let anyAddOp = AnyOperation(addOp) // Type is AnyOperation<(Int, Int), Int>
let sum = anyAddOp.execute(input: (5, 3)) // 8
print(sum) // 8

Notice how stringOperations is an array of AnyOperation<String, String>. Each element in this array is a concrete type, even though the underlying operations (UppercaseOperation, ReverseOperation) are different. The AnyOperation wrapper provides a uniform interface, effectively "erasing" the specific concrete types of the underlying operations while preserving their behavior.

Type Erasure Solution with AnyOperation UppercaseOperation (Input:String, Output:String) ReverseOperation (Input:String, Output:String) AnyOperation<String, String> Conforms to Operation (Input:String, Output:String) wraps wraps Array: `[AnyOperation]` Homogeneous collection can store

Practical Use Cases and Benefits

Type erasure is not just an academic exercise; it solves real-world problems in Swift development:

1. Homogeneous Collections of Heterogeneous Types

As demonstrated, the most common use case is to store different concrete types that conform to the same PAT in a single collection. This is crucial for building flexible systems where you might have various implementations of a service, a data source, or a UI component, all sharing a common protocol interface but differing in their associated types.

2. API Design and Abstraction

When designing public APIs, you might want to return a type that conforms to a protocol with associated types, but you don't want to expose the specific concrete type or its associated types to the API consumer. Type erasure allows you to return an AnyFoo wrapper, hiding the implementation details and simplifying the API.

For example, if you have a DataLoader protocol with associatedtype Data, you might have JSONDataLoader and XMLDataLoader. Your API can return AnyDataLoader<MyModel> without forcing consumers to know about the underlying JSON/XML specifics.

3. Bridging Type Boundaries

Sometimes you need to pass an object conforming to a PAT across different modules or layers of your application where specific generic constraints are not desired or possible. A type-erased wrapper provides a concrete type that can cross these boundaries easily.

4. SwiftUI's AnyView

A prime example of type erasure in Apple's frameworks is SwiftUI's AnyView. When you use an if statement or switch to conditionally return different View types, the compiler might complain that the return type is not consistent. AnyView allows you to wrap these different views, presenting a unified AnyView type to the compiler, thus "erasing" the specific underlying view type.

struct MyConditionalView: View {
    let showText: Bool

    var body: some View {
        if showText {
            Text("Hello, World!")
        } else {
            Image(systemName: "star")
        }
        // This works because the compiler can infer 'some View'
        // If you had more complex logic or needed to store these in an array,
        // AnyView would be necessary.
    }
}

// Example where AnyView is directly useful:
struct MyDynamicView: View {
    let viewID: Int

    var body: AnyView { // Return AnyView to allow different underlying types
        switch viewID {
        case 0:
            return AnyView(Text("Zero"))
        case 1:
            return AnyView(Image(systemName: "one.circle"))
        default:
            return AnyView(Rectangle().fill(.red))
        }
    }
}

While some View often handles this implicitly in SwiftUI, explicit AnyView is needed in scenarios like storing different View types in an array, or when returning different view types from a function that must have a single, consistent return type.

5. Combine's AnyCancellable

Similarly, in the Combine framework, AnyCancellable is a type-erased wrapper for the Cancellable protocol. It allows you to store and manage subscriptions without knowing their specific underlying publisher and subscriber types, making it easy to clean up resources.

When to Use and When to Avoid Type Erasure

Like any powerful pattern, type erasure comes with its trade-offs.

Use Type Erasure When:

  • You need to store heterogeneous collections of types conforming to the same PAT.
  • You want to return a protocol with an associated type from a function, but the caller shouldn't care about the specific concrete type or its associated types.
  • You are building an API or framework where you need to hide implementation details of a PAT.
  • You encounter compiler errors about "Protocol 'X' can only be used as a generic constraint" and generics (<T: X>) are not a suitable solution for your specific problem (e.g., storing in an array).

Avoid Type Erasure When:

  • Generics can solve the problem more directly. If you can use a generic function func process<T: Operation>(item: T) or a generic struct struct Processor<T: Operation>, that's generally preferred because it maintains type information at compile time, leading to better performance and stronger type safety.
  • Performance is critical. Type erasure usually involves an extra layer of indirection (calling through a closure or a virtual method table) and potentially heap allocation for the wrapper, which can introduce a small overhead compared to direct generic dispatch.
  • The associatedtype is truly important and should not be hidden. If the client needs to know the specific associated types to interact correctly, type erasure might obscure necessary information.
┌─────────────────────────────────────────┐     ┌──────────────────────────────────────────┐
│             Problem (PATs)              │     │          Solution (Type Erasure)         │
├─────────────────────────────────────────┤     ├──────────────────────────────────────────┤
│ `protocol Operation { associatedtype A }`│     │ `struct AnyOperation<A>: Operation { ... }`│
│                                         │     │                                          │
│ `var ops: [Operation]`                  │     │ `var ops: [AnyOperation<Int>]`           │
│ ❌ Compiler Error:                       │     │                                          │
│    "Protocol can only be used as a      │     │ ✅ Works!                                │
│     generic constraint"                 │     │    Homogeneous collection of concrete    │
│                                         │     │    type `AnyOperation<Int>` instances. │
│ Compiler doesn't know concrete type     │     │ Compiler knows concrete type `AnyOperation<Int>` │
│ for `A` at compile time for collection. │     │ and its fixed associated type.           │
└─────────────────────────────────────────┘     └──────────────────────────────────────────┘

Summary

Type erasure is a sophisticated yet essential pattern in Swift that empowers you to overcome the limitations of protocols with associated types. By creating a concrete wrapper type, you can effectively "erase" the specific generic details of conforming types, allowing you to treat them uniformly in contexts like collections or non-generic function parameters.

While powerful, it's important to understand when to apply type erasure. Prefer generics when possible for compile-time type safety and performance. However, when generics fall short and you need to manage heterogeneous collections or abstract away implementation details, type erasure is the elegant solution that Swift developers reach for, as evidenced by its use in foundational frameworks like SwiftUI and Combine. Mastering type erasure will undoubtedly make your Swift code more flexible, modular, and robust.

Happy Swifting!

Tagged: