Swift Developer Skills: App Architecture

(This is part 2 of my series of posts about some of the things I have learned since completing my Udacity Nanodegree 2 years ago. If this is useful, you can read the first post in the series where I talked about the awesome tool SwifLint)

I recall a conversation I had with a school friend of mine who is currently hiring developers. He has interviewed 35+ developers in the past month — and has only hired 3 of them. When I asked what made those developers stick out, he said that those were the great developers in the group — and he only wants great developers who weren’t going to make it hard for his team. So what makes a great developer you may wonder?? Its these 6 things:

Characteristics of a Great Developer

  1. Understands System Architecture
  2. Knew Design Patterns
  3. Understands how to write clean code
  4. Thinks about the users they are writing code for.
  5. Cares about their team.
  6. Has a good personality and is fun to get on with.

In the spirit of this useful information — I thought I would spend a bit of time posting about app architecture. After finishing my nano degree, I must admit- I had fallen in love with MVC on IOS. That was until recently when I tried something new to sway my passions. ( dare I call it cheating?) Officially my new favourite way of architecting an app is now strongly in the MVVM corner (aka Model — View — ViewModel which rolls off your tongue like a ball of chewing gum)

but before I can do that — let’s talk about the architecture that started it all: MVC ( Aka Model- View Controller)

MVC App Architecture Overview

MVC is a architecture pattern where you separate out your apps logic into :

MVC architecture
An Overview of how Model, View, Controller ( MVC) architecture is structured

Model
handles the data behind the app and all the methods that involve manipulating this data. Models should never be connected directly to views

View
are responsible for the presentation of the data held in the models. The are typically reusable so you can use the same “template” to support multiple screens. There shouldn’t be any logic in there

Controller
this is where the logic and intelligence of you app come in. Controllers are the bridge in the app between the models and the views. Controllers are responsible for a lot of tasks including:

  • Looking for changes in the data models
  • Responding to user requests for actions .
  • Maintaining the state of the various elements in the view

Apple have a great summary of MVC on their site which can go into more details if you are interested.

Ease of MVC in Xcode

Having previously worked on Android apps, and other frameworks for web — MVC has become a standard go to method for managing digital architecture. Entire platforms are written around it.

Apple has followed suit and has actually built the whole app ecosystem and its tooling around MVC.

When I first started learning iOS Xcode and Interfacebuilder seemed perfect and MVC was the perfect architecture to produce apps with it. One of the joys of programming in IOS has been the great IDE(Integrated development environment) that Xcode is in comparison to other languages and how much its helps developers to code using MVC.

It seems so logical:

Image for post
Xcode has built in support for View Controllers and MVC
  1. Create a new file using the add file wizard in Xcode. Give it a name and tell Xcode it needs to be a subclass of UIViewController.
  2. You build your UI as a StoryBoard in interface builder in Xcode.
  3. Connect up the IBOutlets to the methods in your view controller, by Ctrl-dragging from the outlet to the method that it triggers/ or the reference it connects to.
  4. Make sure you have your models setup nicely as their own files, and then you can do all the heavy lifting in your view controllers.

Easy right?

MVC Drawbacks

I couldn’t have been more wrong — even by refactoring your code into using helper files, clients or event using Swift Extensions and ‘MARK:’ syntax— you will invariably end up with the single biggest problem related to MVC which has been dubbed

“Massive View Controllers”

— with whatever app you do, you will invariably end up with a skyscraper load of view controller code. The largest challenge about using MVC is that the view controller simply does too much and becomes a bottleneck in development. As an example — the open source AnimeNow manages the large View Controllers problem by using 4 separate extension files to break up its UIViewcontroller.

Image for post
AnimeNow breaks up its

Using extensions is a great tactical solution to solve the massive view controller problem — but the problem really sits within the domain of resolving it an app architecture level.

MVC’s Impact

Large complex files should be seen as a massive anti-pattern, and result in difficult to change and understand code. They increase the amount of maintenance needed, and also result in it being harder to find the connections between various parts of the code. Even the overhead of keeping multiple files open in multiple panes results in slower development.

Most importantly MVC appears to break item 3 and item 5 of my friends list of what makes up a great developer. Large files are hard to understand, and hard to change. Its not clean and its definitely not respecting your team if this is part of your standard output.

MVC can work — but after discovering MVVM — I don’t think I will ever go back. More on that in my next post.