Enumerating The Reasons Why ENUMs are AWESOME!!

updated over 1 year ago; latest suggestion over 1 year ago

This proposal has been withdrawn...


If you’ve ever been surprised or delighted by enum in Swift, or have ever regretted typing @property BOOL in Objective-C, then this talk is for you!


When people were just getting familiar with Swift, the concept of Protocol-Oriented Programming swept the community. But the improvements to enums have the same potential to completely change the way you design code! Let’s spend some time focusing on all of the reasons why using enums in your project will lead to a much simpler and more maintainable design than using boolean state variables to represent all of the cases your app needs to handle.

Getting Started with enum

Boolean state variables are the enemy of clean code. Of course we’ve all used them though, and they aren’t so bad at first:

@property (nonatomic, assign) BOOL connected;

One variable to represent if something is connected or not. No problem. At least we aren’t using nil value checks as a proxy for true or false :) But there will probably be a dozen or more methods that need to check that variable, so now your code is dependent on it. Eventually new variables will be added to represent something like a connecting state, and your code will be dependent on them too. We start to see that the web of state gets tangled very quickly.

But the real problem comes when you want to mimic the behavior of a class in the connected state…without actually being connected :( You might start setting that variable to true when it isn’t really, or create a new variable called actSortOfLikeWeAreConnected and check both of the variables with an || operator.

if self.connected || self.actSortOfLikeWeAreConnected { self.imageView.setImage(greenCheckImage) }

At this point, congratulations! You’ve reached the limit of boolean state variables and you need enums :)

Replace those unrelated state variables with an enum that includes the context to define specific behavior!


Using enums this way makes entire classes of bugs no longer possible, because the invalid state that causes the bug cannot be represented by the available cases. The challenge with tangled webs of state is remembering which variables should be set to what values, when enums reduce this down to a single setting. Invalid states become impossible to represent - thanks to Swift's type checking and default value semantics :)

ENUMs are simply delightful

Keeping code clean is just more fun with enums. Enum cases can contain associated values, so your state variables are always available in the context where they are most relevant. And because enums can have method implementations and protocol conformances in Swift, all of your state checking and branching can happen right there in the enum itself!

You can create an OnboardingViewController and enumerate configurations for how it can be used - complete with setup parameters and business logic in each case. You can pass an order object through each stage of the checkout process. You can replace data loading state variables and arrays with a far more precise model like the one below:


case notLoaded
case partiallyLoaded(placeholder : [TableObject])
case fullyLoaded(first : [TableObject], second : [TableObject])

func dataForTable() -> [TableObject]? {
    switch self {
    case .notLoaded:
        return nil
    case .partiallyLoaded(let placeholder):
        return placeholder
    case .fullyLoaded(let first, let second):
        return first + second


About This Talk

I want this to be a talk that everyone can learn something from. I think that choosing a focused topic like enums is what makes that possible. We’ll be diving into the details of several examples, but those examples are how we learn about this topic. You should read the Swift language chapter on enums for what they are and how they work, and come to this talk for inspiration on when and why to use them.


  • The proposal author responds over 1 year ago

    Hi! I'm looking for feedback on improving the Markdown syntax that I'm using to represent code blocks :) doesn't seem to be working reliably :)