As a new iOS developer, there is a huge amount of information you need to master: a new language, new frameworks and APIs, and Apple’s recommended architectural pattern Model-View-Controller, or MVC for short.
The MVC pattern is commonplace in iOS development. While it’s not a difficult pattern to understand and get familiar with, there are things to consider to avoid common pitfalls.
Getting up to speed with iOS development can be a daunting task and, more often than not, MVC doesn’t get as much attention as the APIs or programming language. This can lead to major architectural problems in your apps down the road.
MVC is a software development pattern made up of three main objects.
‍
The Model (M)
‍The model layer encompasses your app’s data. No surprise there, but there are usually other classes and objects in your projects that you can include in this layer:
‍
‍Network code: You preferably only use a single class for network communication across your entire app. It makes it easy to abstract concepts common to all networking requests like HTTP headers, response and error-handling and more.
‍
‍Persistence code: You use this when persisting data to a database, Core Data or storing data on a device.
‍
‍Parsing code: You should include objects that parse network responses in the model layer. For example, in Swift model objects, you can use JSON encoding/decoding to handle parsing. This way, everything is self-contained and your network layer doesn’t have to know the details of all your model objects in order to parse them.
Business and parsing logic is all self-contained within the models.
‍
‍Managers and abstraction layers/classes: Everyone uses them, everyone needs them, nobody knows what to call them or where they belong. It’s normal to have the typical “manager” objects that often act as the glue between other classes. These can also be wrappers around lower-level, more robust API: a keychain wrapper on iOS, a class to help with notifications or a model to help you work with HealthKit.
‍
‍Data sources and delegates: Something that may be less common is developers relying on model objects to be the data source or delegate of other components such as table or collection views. It’s common to see these implemented in the controller layer even when there’s a lot of custom logic that’s best kept compartmentalised.
‍Constants: It’s good practice to have a file with constants. Consider putting these within a structure of structures or variables. That way, you can reuse storyboard names, date formatters, colors, etc.
‍
‍Helpers and extensions: In your projects, you will often add methods to extend the capabilities of strings, collections, etc. These too can be considered part of the model.

The View (V)
‍When users interact with your app, they are interacting with the view layer. It should not contain any business logic.
In code terms, you’ll normally see:
● UIView subclasses: These range from a basic UIView to complex custom UI controls.
● Classes that are part of UIKit/AppKit.
● Core Animation.
● Core Graphics.

Well-written view components are often reusable, but don’t focus on that from the start. When you have multiple use cases, that’s the time to make a component more generic.

‍The Controller ©
‍The controller layer is the least reusable part of your app as it often involves your domain-specific rules. It should be no surprise that what makes sense in your app won’t always make sense in someone else’s.
The controller will then use all the elements in your model layer to define the flow of information in your app.
Usually, you’ll see classes from this layer deciding things like:
● What should I access first: the persistence or the network?
● How often should I refresh the app?
● What should the next screen be and in which circumstances?
● If the app goes to the background, what should I tidy up?
● The user tapped on a cell; what should I do next?
● Think of the controller layer as the brain, or engine, of the app; it decides what happens next.