Introduction

Swift enums do not expose a count automatically, but modern Swift gives a clean answer for simple enums: conform to CaseIterable and use allCases.count. That works well when the enum has plain cases. More complex enums, especially ones with associated values, need a different approach because the compiler cannot generate a complete finite case list for you.

Use CaseIterable for simple enums

For enums without associated values, CaseIterable is the standard solution:

1enum CompassPoint: CaseIterable {
2    case north
3    case south
4    case east
5    case west
6}
7
8print(CompassPoint.allCases.count)

The compiler synthesizes allCases, so the count stays correct automatically when you add or remove cases.

This is the best answer for most fixed enums used in app code, especially when you need the count for UI sections, picker choices, or validation.

Raw values do not solve counting by themselves

An enum with raw values can still use CaseIterable, but the raw values alone are not enough to count cases reliably.

1enum Planet: Int, CaseIterable {
2    case mercury = 1
3    case venus
4    case earth
5    case mars
6}
7
8print(Planet.allCases.count)

It can be tempting to infer the count from the highest raw value, but that breaks if values are skipped or assigned manually. CaseIterable is the safe source of truth.

Associated values change the problem

Enums with associated values do not have a single finite list of cases the compiler can synthesize automatically:

1enum NetworkState {
2    case idle
3    case loading(progress: Double)
4    case failed(message: String)
5}

There is no sensible automatic allCases here because loading(progress: ...) and failed(message: ...) can have infinitely many payload values.

If you only want to count the distinct case shapes, you have to define that list manually:

1enum NetworkState {
2    case idle
3    case loading(progress: Double)
4    case failed(message: String)
5
6    static let kinds: [NetworkStateKind] = [.idle, .loading, .failed]
7}
8
9enum NetworkStateKind: CaseIterable {
10    case idle
11    case loading
12    case failed
13}
14
15print(NetworkStateKind.allCases.count)

That separates the finite case categories from the payload-bearing values.

Manual allCases is still possible

If the compiler cannot synthesize CaseIterable, you can implement allCases yourself for enums that still have a finite, meaningful set of values.

1enum Direction: CaseIterable {
2    case north, south, east, west
3
4    static var allCases: [Direction] {
5        [.north, .south, .east, .west]
6    }
7}
8
9print(Direction.allCases.count)

For simple enums the compiler-generated version is better, but manual definition is still useful in specialized cases.

Count only when the count has meaning

Sometimes the deeper issue is not how to count the enum, but whether counting is the right model at all. If the enum represents state with payloads, a fixed count may not be meaningful to the domain.

Ask what the count is for:

• showing a list of selectable cases
• creating UI pages
• validating coverage in tests
• measuring the number of logical case categories

Once that intent is clear, the right implementation becomes more obvious.

Common Pitfalls

The most common mistake is assuming Swift enums have a built-in count property. They do not.

Another common issue is trying to count associated-value enums as though they were plain finite lists. In many cases they are not.

People also infer count from raw values, which is fragile when raw values are sparse or manually assigned.

Finally, if you use a manual count property, it can drift out of sync. CaseIterable is preferable when the compiler can generate the case list for you.

Summary

• For simple enums, conform to CaseIterable and use allCases.count.
• Raw values do not provide a reliable case count by themselves.
• Enums with associated values usually need a different design because they are not a finite list of cases in the same way.
• Manual allCases is possible when needed, but compiler synthesis is safer.
• Count the enum only when the domain actually has a meaningful finite set to count.