Better Programming

Advice for programmers.

Follow publication

Member-only story

The Case Against Immutable Objects in Swift

Michael Long
Better Programming
Published in
12 min readAug 9, 2021
Photo Adam Nieścioruk on Unsplash.

Design patterns come and go, and one of the fads currently ascendant in the iOS/Swift programming world is the concept of Immutable Objects.

To quote Wikipedia:

In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.

Pretty straightforward. Immutable objects are considered to be desirable because anyone who depends upon any given instance of an object can be assured that that object won’t change on them.

That can minimize bugs and make code easier to understand and to reason about. All good things. And functional programmers are fond of them because they’re one of the core building blocks found on the road to writing pure functions.

But immutability often comes with a fairly stiff price, and that price is that it often requires a lot of boilerplate code.

Not to mention that in Swift we’re actually solving the wrong problem entirely, but I digress. More on that later.

Let’s tackle the boilerplate code issue first.

Boilerplate Code

Create an account to read the full story.

The author made this story available to Medium members only.
If you’re new to Medium, create a new account to read this story on us.

Or, continue in mobile web

Already have an account? Sign in

Michael Long
Michael Long

Written by Michael Long

I write about Apple, Swift, and SwiftUI in particular, and technology in general. I'm also a Lead iOS Engineer at InRhythm, a modern digital consulting firm.

Write a response