The Anatomy of an iOS App (for the backend developer)

Dennis J. McWherter, Jr. bio photo By Dennis J. McWherter, Jr. Comment

Being a backend developer, the whole iOS app world seemed a little odd to me when I started out. I mean, most apps are hitting some backend somewhere that does the “real” work while the app itself is nothing more than a glorified front-end, right? Well, not exactly. Though this model is not uncommon, apps can really do some interesting things either with the data they receive from their backends (i.e. RESTful data serving endpoint), other peripherals (i.e. microphone, camera, etc.), or any other sources (i.e. user input). 

Let’s begin with the basics that you can read anywhere else on the web: iOS application development uses enforces use of the Model-View-Controller (MVC) design pattern. In application development, MVC is generally acknowledged as simply good practice, but we must be honest with ourselves: backend developers hardly concern themselves with this pattern. While I won’t explain it here (Google has many resources), MVC (at least in it’s true form) is much less common in backend development. In particular, this is because we simply concern ourselves with developing APIs and underlying tech that does the cool stuff. With that in mind, we’re almost there. We obviously concern ourselves with the model portion a lot and sometimes we even interact with the controller, but we often neglect the view. This is simply an artifact of the level at which we typically work in the tech stack. But do not fret, understanding the view part of MVC is simple and if Google isn’t helping you, try Yahoo! instead (disclaimer: shameless advertising). I promise there are many great resources out there.

Wait a second, I thought this was an article about iOS apps, not stressing the importance of a design pattern developed and formalized in the 70’s and 80’s. You’re right and I promise that digression wasn’t for not. Instead, I bring this up because Apple appears to have spent a lot of time developing tools to make front-end development as smooth and easy as possible for developers. What’s more is that this makes sense. Think about it; you expect beautiful looking apps on your phone regardless of their function. If my calculator app can calculate ((2 ** 200) ** 200) on the order of microseconds, that’s amazing (and it excites us backend guys), but as a user, if it doesn’t look pretty I’m not going to buy/download/use your app. Consequently, Apple has devoted a lot of time and energy into providing us with nice tools to develop apps and only imposes one constraint on us: use MVC. Since, as a backend dev, you should already have strong programming skills, I suspect this is where you will need to focus most of your efforts since being a great front-end dev is non-trivial.

Now that I’ve convinced you that you’re well equipped to develop an iOS app (we already know the M and the C in MVC) but may need to develop skills to make it pretty (erm. maybe that glorified front-end isn’t all that easy after all), let’s move forward and actually talk about an iOS app. In short, we can dissolve an app’s source code to look kind of like this:

 iOS calculator architecture

This is obviously a breakdown of a toy example, but you can see that this exactly resembles what we were talking about with MVC.

  1. Model. You do your “backend thing” and expose some code API which will be used by your controllers. This can be done in many languages (i.e. C, C++, Objective-C, Swift) and all of these languages are reasonably interoperable with each other. As a result, this component will pertain to the majority of your technical logic.
  2. Controller. The controller should use your backend APIs to transform data and be a glue layer between your model and view. In iOS development, this means that you have a class that conforms to one or more protocols. These protocols have certain callback methods which you override to determine how your app responds to certain events. For instance, if a button is clicked, a callback is then fired. Similarly to how the controller encapsulates the model, it can also directly interact with arbitrary pieces of the view (i.e. text fields, rect’s, etc.). Consequently, the controller contains most of your app’s business logic.
  3. View. Views in iOS are typically made through Xcode’s graphical editor. Once you have grasped the basic features of the editor, you will find that creating nice layouts is relatively easy (great layouts, on the other hand, are always a lot of work). Apple provides us with many default view classes which have most of the features typical apps need right out of the box. As you create views, you can drag and drop links to controller code provided that the code conforms to the protocol required by that view type. You can think of views as the front-end and a large part of the user experience.

As you can see, the anatomy of an iOS app is really just MVC wrapped in a bunch of tools that are supposed to make your life “easier.” That said, it’s a bit overwhelming at first when there are so many tools in which with you are not actually familiar. After reiterating MVC and then approaching the iOS frameworks with the appropriate terminology, it becomes clear how the pieces fit together. Finally, this does make iOS development far easier with the proper understanding of how these tools and conventions work together.

Though we didn’t go into detail here about how to build an iOS app (again, see Google, Yahoo!, duckduckgo, etc.) we did describe an overview of constructing an iOS app. I find this to be a particularly important first step in iOS development since many people can write code. However, if you do not know how to connect that code and make it work for you, then you may as well have written nothing at all.

Happy iOS'ing!

comments powered by Disqus