Should Swift Presenters Be Classes or Structs?

Swift structs aka Swift structures came into being and there was much excitement. Members of my own team back then were leaning heavily towards the idea of structs everywhere. As shared in Swift Protocols With Associated Types – PATs, “We were going to use structs and protocols wherever we could.”

Swift Struct All The Things

Should Struct All The Things?

The excitement is over, the dust has settled, and lessons have been learned. Now the question has been raised, should Presenters be classes or structs?

Stack Overflow Discussion and Unfortunate Answer Bias

Titled Why Choose Struct Over Class?, this Stack Overflow post’s chosen answer has been subtly framed in a way that reflects that initial excitement of leaning heavily towards creating Swift structs. It’s framed as if there is a contradiction between the WWDC 2015 talk Protocol Oriented Programming in Swift and Swift Programming Language documentation.

Based on what I and others can tell, there’s no contradiction. Also, the final line in the accepted answer is under scrutiny. Here’s the line under scrutiny:

Also, keep in mind that these concepts are always evolving and The Swift Programming Language documentation was written before the Protocol Oriented Programming talk was given.

As Dan Rosenstark rightfully pointed out:

Last line should say, “My personal advice is the opposite of the documentation:”… and then it’s a great answer!

That said, the content in the accepted answer copied from various sources is good and the post has had a lot of great interaction in it. This content and the Apple sources referenced clearly show when to use a class and when to use a struct.


First, let’s get something out of the way right away. Are our Presenters really Presenters in our CARFAX app architecture? As shared in A Hungry Reflection on “How to Isolate Client-Server Interaction Logic in iOS Applications”, there’s often a debate as to whether we’re set up more for a Model-view-presenter (MVP) architecture, versus Model View ViewModel (MVVM) architecture, versus a Presentation Model architecture. This kind of discussion has gone on for over a decade. Regardless of where you land in the debate, the things that hold our display logic are known as Presenters. For the purposes of this blog post, let’s call them Presenters.

Presenters – Class or Struct?

Presenters contain display logic. There is one instance of them created and they are hooked up to the View Controller classes. Their purpose in life is to contain display logic that is unit testable and help keep the View Controllers from being too big.

Copying or comparing instances of the presenters doesn’t make sense. Presenters don’t fall anywhere near the “Examples of good candidates for structures” list in the section titled “Choosing Between Classes and Structures” of the Swift documentation’s Classes and Structures page. The same is true for the “Classes and Structures” section of The Official Swift Style Guide which is a favorite of many teams.


Structs are awesome to use when passing around simple value objects, whose properties are value types, and are meant to be compared and/or copied. To use structs in other situations is an understandable mistake. In hindsight, our own team tried to make some things structs that should have been classes from the beginning. We fell slightly into the Golden Hammer Anti-Pattern trap. Using a struct for a Presenter or other things like Presenters isn’t upholding the semantic differences between a Swift struct and a Swift class.

Update: Added reference to the “Classes and Structures” section of The Official Swift Style Guide

Comments are closed.