I accidentally wrote the first ever ViewModel in an iOS app (and swore I'd never do it again)
An unofficial history of MVVM in iOS development
This is a story of how I inadvertantly committed a ViewModel to a native iOS codebase. And an explanation of why I instantly regretted it.
Backstory
I’ve been doing mobile development long enough some assume I’m a Mac old-timer. I’m not. I came on the Apple dev scene around 2011. This was post-ARC, but still before much of what we now recognize as standard iOS development. I’d previously helped out with a small Mac project around ‘05. But that was it.
What I was doing before iOS development
The couple years prior to 2011 I’d been doing enterprise .NET work. But I had a long history in client development (embedded and Windows apps).
Enter mobile development
I got my start in mobile development when I helped a startup ship their MVP using C# & Monotouch (now called Xamarin).
I started developing in Objective-C when I took over iOS development for my own startup. Even though I had done mobile development before, another dev wrote the iOS app while I handled tech lead duties.
That Xamarin startup? It was one of the first “Airbnb for X” apps. It’s still kicking.
My own startup. Not so much.
In 2012 I joined a team working on a massive iPad port of a music instruction app. My first large-scale native iOS app using Objective-C.
What problem was I trying to solve
I was tasked with writing a submission form.
It had all the things you’d expect from a form
- Network call to submit the data
- Email address validation
- Number validation and formatting
Enter the Massive View Controller
We were starting to realize the limits of putting everything in the ViewController. The ViewControllers were becoming huge. We wanted to break things up. The pejorative “Massive View Controller” had not been named yet. But we were definitely experiencing the pain.
So what to do? I extracted the validation and networking logic into a separate class, checked-in the code, and scheduled a code review.
You didn’t review the code before merging?
Yes, kids. I checked-in the code first. Today’s Pull Request flow was not yet standard. Additionally, this codebase was already 20 years old. And it was massive. It never would have fit into Git. Seriously, we tried.
Some might ask, you didn’t do a code review before committing the code? Yes. We committed our code to the main branch as often as we could. Multiple times a day. Reviews happened later. We didn’t know the term Continuous Integration. But we lived it.
How did you catch the bugs?
Bugs? We had way fewer bugs. Stories were completed routinely and releases were painless. It was one of the most productive teams I’d ever worked with.
Back to the code review
We did them in real-time using a projector. I plugged my laptop and displayed the code.
The other reviewer squinted at the screen and said, “it looks like you wrote a ViewModel”. We both had a .NET background. And were familiar with MVVM from our time writing Silverlight and WPF apps. MVVM wasn’t a new pattern to us.
I looked closer and realized he was right. And quickly realized I’d made a terrible mistake
Why was writing a ViewModel a terrible mistake?
If that sounds weird, here are some things you should know about iOS development in the early days.
Early days of iOS programming
Apple development had its own history and patterns. They were recognizable to those, like me, who’d done client development before. But the historical Mac devs had their own ways of doing things. And they were a far cry from what we see today.
Enterprise patterns were weird
Enterprise-y patterns felt weird. Terms like Repository, Factory, and Adapter were unheard of. Except for Singletons. Wow! Those things were everywhere (and always hanging off the AppDelegate).
Microsoft was the enemy
Enterprise-y patterns may have been weird. But Microsoft patterns were anathema. Microsoft was the Evil Empire. It represented everything the Mac devs had been struggling against for a decade+. Anything remotely tied to Microsoft was immediately written off.
The aftermath
This is why I was so horrified. I don’t recall what I named the class. But it was something we’d recognize today as a ViewModel.
The look of terror on our faces was immediate.
“We must never speak of this again.”
We made a solemn vow to take this knowledge to our graves.
In shame, I unplugged my MacBook from the projector. We went back to our cubes and went about the rest of our day. Praying no one would ever discover what we had done.
Times change
As mobile development exploded, there weren’t enough of the old-school Mac devs to handle the demand. In response, more and more devs were entering the iOS dev scene. The new devs didn’t have the anti-Microsoft baggage of the Mac devs. They brought influences from stacks like .NET & Ruby on Rails.
Microsoft influences still rare
Even with the new flux of influences, explicitly recognizing a Microsoft influence was odd enough (even in 2014) to prompt me to Tweet this.
This was from a ReactiveCocoa talk given during WWDC week in 2014. It was help at the GitHub offices in San Francisco. About 50 of us skipped the main event to check out the bleeding edge of iOS development.
Reactive in iOS, in 2014?
In hindsight, ReactiveCocoa having a Microsoft influence wasn’t surprising. Rx extensions had been common in Silverlight and WPF development for years by that point. But they were bleeding edge in the iOS space.
What about the Enterprise-y patterns
Enterprise patterns were still a couple of years off. At least in the apps I worked on. The Java devs familiar with Enterprise design patterns gravitated towards Android, not iOS. When asked why, they usually said they couldn’t get the hang of Objective-C. This was commonly attributed to a Fear of Brackets. But that’s another story.
Who else was talking about MVVM for iOS in the early 2010s?
Not many. At least in native iOS circles. Justin Spahr Summers did a talk in 2013. But from the evidence, GitHub was still developing using C# and Xamarin, not Objective-C.
The tech lead at the startup and I may have been discussing, in 2011, using ViewModels to share code between iOS and Android in the Xamarin app. But that might be a false memory too. In any case, I rolled off that project before Android work was begun.
By 2014 I too was openly discussing MVVM as an acceptable alternative to MVC in my talks1 and podcasts2. But I was only advocating MVVM for specific cases much like the ViewModel I described above.
How did MVVM become so popular?
This 2014 article from Ash Furrow helped drive visibility and acceptance of the MVVM pattern in native iOS development. From there things snowballed. By 2016 MVVM was largely accepted and used widely for new apps.
Even with some pushback from myself and Soroush Khanlou MVVM became the default architecture for iOS apps.
Conclusion
Despite the title of the post, It’s highly unlikely that I actually wrote the first ViewModel in an iOS app. And some details may have been embellished for narrative purposes.
But I’m interested in hearing from others who may have. Or, at least, were the early adopters who wore their shame with pride.