App Architecture, the book review
I went thoroughly through the great new book by objc.io authors. Given its topic, you can expect I have lots to say.
objc.io’s App Architecture,by Chris Eidhoff, Matt Gallagher and Florian Kugler
I was waiting for an opportunity to dive into this book ever since Chris and Florian announced it months ago. I love their style of explanations. I’m a day-one subscriber to Swift Talk. I used the code and examples from their Code Data book for years. Plus having Matt Galagher was cherry on the top as I was reading Matt’s articles for a decade or so, since ObjC days. Hence…high expectations. 🙂
Topic of the book is near and dear to my heart in the last two years with pretty strong opinions.
···
Initial chapter which introduces and explains various architecture patterns is all talk, no code. It was rather dry to plow through and to be honest – I did not understand half of it. Unless you already know this stuff, it’s really hard to visualize and comprehend the concepts presented in bullet-point form.
Only when I got to the actual one architecture per chapter part I found examples of significant new concepts highlighted with code snippets. In hindsight, I believe that first chapter should have been the last since then it would be a summary of the concepts explained in the previous chapters. By then, you would already have much better grasp of the terminology and concepts behind them.
Another issue I have with the book is the big jump in complexity from MVC chapter to MVVM chapter. Not only is ViewModel introduced but also Coordinators and reactive programming with observables and subscribers and such. This is unfortunate since it clouds the benefits of introducing just ViewModel. Or just Coordinator.
After you get through all this, there is a chapter somewhat misleadingly titled “Implementing ViewModel without reactive programming” since it still uses Rx, only less so. Only after that one, there’s a sub-chapter which removes all of Rx and uses KVO-based bindings which is more akin to regular UIKit modus operandi. I think that if the order was reversed – by gradually introducing ViewModel, then Coordinator, then Rx – it would be easier to understand.
I’m teaching beginner iOS in Swift for the last several years and know first-hand that such big jumps can be highly discouraging for the students. This book is certainly not for the beginners – it targets experienced developers – but the issue is the same on any knowledge level.
MVC is the bread and butter of UIKit. All documentation and every beginner tutorial on the net is explaining MVC thus by the time you need a book like this you should know UIKit by heart. In other words – the first chapter should be entirely familiar to the reader. If, then, the second out of six architectures introduces so much new stuff, a reader may ask itself: ”jiminy, what awaits me further in the book..?”. And indeed a lot more awaits. I first thought I could go through this book in a day or two but it took me far more than that.
If you persevere though, you will be rewarded with rather good implementations of the same project in each architecture. To get the most out of the book I recommend to read the book on an iPad and look into the code on the Mac, so you can see the full context of the code and not just a snippet which could be put into the book.
Despite the critique so far, I recommend this book as required reading for developers tasked with implementing large apps with dozens and dozens of UIViewControllers. You will see all the pros and cons of each pattern over the fairly simple yet just complex enough app.
You’ll clearly see the differences in approach and – most importantly to me – magnitude of code size required for each. Which translates into magnitude of time spent to write and maintain said code.
Some additional commentary…
···
Networking chapter uses MVC as starting point to present how network-sourced data can be implemented
- inside the UIViewController
- inside the Model
The first approach should never be used in any kind of apps, no matter how simple it is. Authors pretty much concur, only say it more verbosely and less harshly. Networking code has no place inside the UI layer of an app, period.
The second one is more sensible but IMO still wrong. I recently spoke at NSBudapest about proper architectural design of the non-UI app parts (recording is from my Mac, while I stood in front of it thus the audio is a bit bad). Data model and transformations should be clearly separated from data sourcing and data delivery. This is all part of the general LAYERS architecture approach I promote and it’s a much larger topic.
···
Regarding conference-speaker-favorites – VIPER, Redux and their derivatives – book authors have this to say:
Attempts to bring “Clean Architecture” to Cocoa usually claim to manage “massive view controllers,” but ironically, do so by making the code base even larger.
👏🏻👍🏻
However, I would add that some of the architectures in the book also fall into this category; particularly TEA and MAVB. There is so much overhead added to each model/UI component that the cost of on-boarding new developers to a project using them is really, really high. Nothing in the UIKit and Apple’s documentation and guides prepares you for this. Thus I’m not sold on their practical use outside of academic curiosity.
It’s not that I believe that anything other than MVC is bad. It’s that architecture pattern alone is just part of the picture as the book authors readily accept (emphasis mine):
TEA is a pattern attributed to the Elm community, and it reportedly emerged naturally from the constraints of the language and the target environment.
Also this:
MVVM requires explicit framework support for the binding between the view and the view-model, whereas presenters traditionally propagate changes manually between the two.
(Hence the forced use of Rx to add such functionality into UIKit)
Then this:
TEA and other patterns with a declarative view layer suffer from the same problem: UIKit’s view state changes independent of your view state or model.
Etc.
Implicit design constraints of UIKit is what makes these architectures and frameworks non-starters for me. The best architecture for particular framework is the one that gives you the least amount of headache and requires the least overhead. As I said many times before –
if you need to fight or largely augment the framework to get what you want, it’s likely you chose the wrong framework (or platform)
I had some hopes for MVC+ViewState since I like the big picture idea but the sheer amount of code overhead gave me a headache. An architecture like that is applicable only to carefully designed system, top to bottom, front end to backend. In contracting world, where dev companies like mine are hired to write a front-end using dozen of incompatible systems that somehow need to work together, maintaining such a large state graph would drive anyone insane.
Just look at the ViewStateStore.swift in MVC+VS project and imagine something like this being maintained for an app with 6 APIs, 11 Coordinators and 100+ View Controllers where some screens have 10+ UIVCs embedded into one scene. Where at any moment there are half a dozen of (somewhat) parallel asynchronous actions being performed. No freaking way until Apple adds support for ViewState to all UIKit components (which I can’t see happening).
Again – I am very grateful this book exists. It helped to clear out any lingering doubts I had about my chosen approach. It further solidified my belief that MVC (with Coordinators) is the best architecture for UIKit apps. I understand the benefits of the more esoteric architectures but each comes with an increasingly steeper cost of code size and complexity. If you’re single developer or a team of 3-5 people – using those other architectures will drag you down for no good reason. If you have a larger team, then by all means: go for it if you want. Honestly though, even with 100 developers I would say that MVC-C or MVVM-C (without Rx Swift) is still the better choice.