"I be Sam, Sam I am."

— Method Man (Dr Seuss had the audacity to copy him, apparently.)

Hey, I’m Sam. I’m predominantly an iOS developer for my sins, and I’ve been building for Apple platforms for nearly a decade now. Which is mildly terrifying considering University feels like yesterday. I’m currently working at Plex, building out their personal media offerings on iOS and tvOS. Before that, I was at the BBC working on their iPlayer app for iOS, and at Booking.com, working on their car rental side of the buissness for their iOS applications.

And before all of that, I’ve been at agencies and doing my own solo projects. All of which started with good intentions, most of which ended up in the scrap heap.

Working at those larger companies has changed my priorities as a developer, particularly the BBC. The engineering culture on the iPlayer mobile team was exceptional. The amount of information shared amongst the team about software engineering practices was staggering, and it was a real privilege to get to work with such a smart bunch of people.

Given these career experiences, I’d suggest it appears the iOS world is slowly changing in its priorities. What once was a new platform, where the challenge was figuring out "how do we build for this thing?", is now in a maturing state, where the challenge is "how do we keep building for this thing?".

A lot of these issues have been tackled by other platforms much more aggressively. Not only tackled, but the general priorities of the communities of those platforms feel different. Implementation details and specific technologies take focus in the iOS world, where as practices and approaches take focus elsewhere. In a study by Jetbrains, 62% of Swift and Objective-C developers said they didn’t write unit tests for their projects. This difference, and the somewhat “fast-fashion” approach taken by Apple’s frameworks is not only exhausting, but also feels like a small piece of of the puzzle when it comes to building long-lasting software. As an example, the ability for an app to be reactive and withstand the test of time doesn’t depend on the teams knowledge of SwiftUI, as proven by the amount of apps still succesfully using Objective-C. Legacy codebases and Apple’s own guidance on how to craft software keep providing roadblocks that make modifying and adding code to existing projects more of a challenge as the years go by.

This leads on to the motivation for this blog. I’ve keenly felt the sting of how demoralising bad software design is to work on. I’ve also worked on projects that have pushed the boundaries on what good software design can look like, and I’ve felt how empowering that can be when done correctly. And I whilst I definitely don’t have all the answers, I hope to have enough interesting perspectives to share, with the hopes of passing on that motivation as to why architectural design is just as important to Apple platforms as it is to any other platform.

Thank you for taking the time to look at this blog.