Ready… Set… Xcode! Annex 1: General project architecture… Explained.

A more detailed explanation for the architecture diagram referred to in “Ready… Set… Xcode!”.

On my first blog post, “Ready… Set… Xcode!“, we spoke about a general project architecture that is common to standard iOS Apps (note that architecture for games can be considerably more complex).

Here is a copy of the diagram to refresh our memory:Untitled drawing As you can see, in the middle we have the one design pattern to rule them all: the MVC pattern, roughly taking around 70% of the entire application’s architecture. A brief explanation of the components in this diagram follows: BASE (what you get for free):

  • Application: The app, generally composed of UIApplication and UIApplicationDelegate classes.

OTHER (what you create): MODEL LAYER:

  • Models: The raw data objects of your application, normally they will be NSObject, UIDocument or NSManagedObject subclasses.
  • Managers: Intermediaries for editing and managing specific general data or specific sections of data, model objects or the device. Normally they are setup as singleton objects, as you would normally only need a single instance of these classes to do the heavy lifting for your application. (a lá NSFileManager)
  • Datasources: Read only intermediaries between view controllers and the raw model data, i.e: NSFetchedResultsController.
  • Networking: Any code that calls an external API will need this layer.


  • Views: Your application views. Even if you are using Xib files or Storyboards, having a clear separation between UIViewControllers and their contained views is essential for achieving better code structures with more reusability.
  • Components: Subviews contained within general app views. Rule of thumb is if the view is not contained by a UIViewController and/or is used in more than one part of your application, I suggest you chuck it here. (i.e: Cells)


  • Navigation: (optional) Commonly a UINavigationController or a subclass of. If you are using Segues or a root view with modal subviews it’s not strictly necessary.
  • View Controllers: The crux of our model. Should be the most lightweight part of your code as it will be the least reusable. If you think any code you have here has an even remote chance of being used somewhere else in your app I suggest you move it elsewhere.
  • Child View Controllers: … I heard you liked view controllers so I put a view controller inside your view controller.


  • Globals: (optional) Application global files, in the form of header files containing defines, general static variables, or shortcuts that are common to your or your team’s style of coding.
  • Extensions: Here is where you leverage what is arguably the most flexible and useful part of the iOS SDK: the use of categories to extend object functionality, and you’d be pretty wrong in not using them. Make no mistake, chances are any code you put into a category will quickly become highly reusable and your best friend while coding, if you develop them with an abstract thinking in mind, you can even port them across projects!
  • Factories: (recommended) You can use extensions, singletons, abstract classes or dedicated objects here, but note that any code you write in factory objects will only ever usable by the application as it will be very specific to it (so keep them separate from your extensions group if using categories).

Author: Danny Bravo

Director @ EPIC