A scene can be thought of a section, feature, or use-case inside an app. A small but internally complete and contained part of the whole application. How big or small you want to make the scene is up to you.

I usually find that definining a scene as a feature works quite well. It is usually a collection of 1 to 4 screens that are meant to achieve a single purpose. For example a login flow, a picture upload process, or a purchase funnel.

Organization

To begin with I create a folder inside my Xcode project called Scenes which will contain subfolders for all the scenes. Inside a particular scene (as you can see in the Search example below) I have all of the parts pertaining to that scene. From the Coordinator down to the Views. These folder structure will be repeated for each scene.

I think this helps compartmentalize each Scene of the app as a complete little self-contained app inside of the bigger whole application. I could drag this Scene’s folder to another app and it should mostly work.

Storyboards

As you can see from the screenshot above each scene should have it’s own Storyboard with the same name as the scene.

Storyboards are still a little bit of a controversial topic in the iOS community. Some people can’t imagine creating an iOS app without using storyboards, and some other people in the community wouldn’t be caught dead using a storyboard. They either create their views programmatically or they only use XIB’s on a per screen basis.

One of the complaints against storyboards is that sometimes developers cram all of their app’s screens inside one massive storyboard and it becomes a mess, especially when there is multiple people working on the same storyboard. Gotta love those impossible to understand GIT merge conflicts where you have to parse over XML text to understand what’s happening.

But there are still a lot of benefits to using storyboards. They make size-classes and auto-layout a breeze, they allow for static table views, they let you visualize your app’s flow, etc…

I won’t get into all of the pro’s and con’s of using storyboard’s here, but I think I’ve found a middle ground. Each scene should have one storyboard which contains only the ViewController’s included in that scene. This goes a long way to preventing merge conflicts as usually only one developer is working on a specific feature or section inside of an app.

And most importantly, altough I do use storyboard’s to contain the ViewController’s for each scene I do NOT set any segues or relationships on the storyboard. It is only for configuring the View’s for each ViewController included in the particular scene.

Coordinators

This previous point is really important. We can use storyboards but we do not use segues or any other kind of relationships that we can create using interface builder. The reason for this is that the Coordinator is going to be responsible for handling the navigation and relationships between ViewController’s.

Many people think Coordinators and Storyboards can’t co-exist. When in reality if you don’t use segues or relationships they can work together quite nicely.

For more on coordinators head on to the next article in the series:

iOS Architecture: MVVM-C, Coordinators (3/6)

iOS Architecture: MVVM-C, Scenes (2/6) was originally published in Sudo by Icalia Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the last part of this architecture’s name but I think it’s the most important part. If you can only implement one part of this architecture as a whole I would recommend the you implement this pattern, as I think it has incredible potential to improve your overall application structure.

A coordinator is an object (Class type in Swift) which has the sole responsibility, as it’s name implies, to coordinate the App’s navigation. Basically which screen should be shown, what screen should be shown next, etc.

This basically means that the coordinator has to:

• Instantiate ViewController’s & ViewModel’s
• Instantiate & Inject dependencies into the ViewController’s and ViewModel’s
• Present or push ViewController’s onto the screen

(Don’t worry about ViewModels right now, we will look at them in the next article)

Why use a coordinator?

Coordinators are a great tool because they free our ViewController’s from a responsibility that they should not have. This helps us adhere to the single responsibility principle, which makes our ViewController’s much leaner and easier to re-use.

A ViewController should not know what ViewController came before it, which one should come next, or what dependencies it should pass on. It should just be a “dumb” wrapper around the View/Subviews on the screen, and handle only UIKit related stuff. Any action regarding navigation on the ViewController should be sent up to the Coordinator for proper handling.

Coordinator base class

Let’s see some code. We start with a an abstract base class that all our Coordinator’s will inherit from.

This base class is not absolutely neccesary, you could use a protocol if you prefer. But I find that this way of organizing coordinator’s makes sense and has worked well for me.

If you want to create your own coordinator you first subclass this base class, and then override the start and finish methods. Then you have built in methods to handle adding and removing child coordinator’s. Very similar to how a UIViewController works.

AppCoordinator

Your app should consist of multiple coordinators, one for each scene. But it should always have one “main” AppCoordinator, which will be owned by the App Delegate.

The following code is an example of a basic AppCoordinator. All other coordinators in the application will be children of this coordinator.

Let’s go over it, there are 3 important part’s here:

• Properties: These are the properties this object owns. In this case since it’s the AppCoordinator it must own the window. It also owns the root and other ViewController’s, and any dependencies it will need, like the ApiClient in this case.
• Init method: Here you must take in any dependencies you will need in this coordinator. In our case since it’s the first coordinator the only dependency we need is the app’s window.
• Coordinator: Here you must override the Start() and Finish() methods. The start method is the most important one, which is where you present your UI onto the screen. In this case what we do is set our root view controller onto the window.

This is how you would “start” your application from the AppDelegate using the AppCoordinator.

You will hold onto the AppCoordinator as a property in your AppDelegate, the same way that the window is held on to. Then in the application: didFinishLaunchingOptions: method of your AppDelegate you instantiate the App Coordinator with the UIWindow, then call start() on it.

That’s it!

Child Coordinators

Your app will obviously need at least one, if not many more, child coordinator’s to handle all the scenes in your app.

Let’s go over an example of this kind of coordinator so you can get an idea. It is going to be similar to the AppCoordinator but it’s going to have some more responsibilities, depending on how complicated your scene’s are.

This part is very similar to our AppCoordinator, but let’s go over it anyways.

• Properties: We have a reference to the storyboard related to this coordinator/scene, and all other view controller’s and dependencies.
• Init, Root View Controller: This coordinator is initialized with a root ViewController, not a window like in the AppCoordinator.
• Init, Api Client: Notice that we also get the ApiClient in the initializer. As I said regarding the AppCoordinator we should get all the dependencies we are going to need in the initializer. Since the ApiClient already has important session headers we want to use the same one all around our app. This is one of the biggest benefits of using coordinators, you don’t really have to use Singletons anymore. Yes, we only have on instance of this ApiClient, and we pass it around using dependency injection, BUT we are not using a static global variable to access it from everywhere which is usually considered an anti-pattern.
• Start: Basically the type of root “container” we are initialized with dictates what we are going to do in the Start() method. In this case, since it’s a TabBarController we will add ourselves to it. If it was a NavigationController we would push ourselves onto it, and if it’s a plain ViewController we would present ourselves on it.
• Finish: Here we have to clean up any ViewControllers we have on the navigation stack, or anywhere else. Tell our service layer to cancel any pending requests. And finally, call our delegate, if we have any, and let it know that we are finished.

Navigation

Navigation is a big part of Coordinators. I like to add an extension to the coordinator to handle all navigation, having a method for each navigation that can happen.

We will get into where these methods are called from, but for now let’s just focus on them in isolation. I like to name my navigation methods starting with the goTo prefix. You will usually have a bunch of these.

Notice how these two examples are different:

• The first one, goToLocationSearch instantiates a ViewController and presents it on the ViewController passed in as a parameter. Remember, this ViewController is still part of the same scene.
• The second one, goToSearch is different because here we are leaving this scene. This part of the application that we’re navigating to is another scene, so it’s going to be handled by another coordinator. So here we only instantiate the other coordinator, send in any dependencies, like the root ViewController. We call start on it, and most importantly we add it as a child coordinator. If we don’t do this nobody is going to be holding onto the coordinator and it will be released.

Coordinator Callbacks

Another important part of the coordinator are the delegate callbacks we are going to be getting from the ViewModel’s (or ViewControllers) and other child coordinators.

First, we may have callbacks from our child coordinator’s. If a child coordinator has to inform us of something it’s going to have a delegate protocol we must implement.

In this case we are implementing the didFinishFrom: delegate method of a child coordinator. Here if our child coordinator is finished, it’s finish method should be called, and it’s finish method should call it’s delegate to let it know it’s finished. Afterwards, we remove the child coordinator from our stack. That assures that it’s removed from memory.

ViewModel Callbacks

Finally, the other kind of callbacks we might have are from our ViewModel’s (or ViewControllers if you are not using ViewModel’s).

These callbacks let us know if the user want’s to navigate to another part of the app, and from this is where we would call our goTo navigation methods. Notice how the ViewController this request is coming to is a paremeter in these delegate methods. This makes it much easier to be able to present view controllers on top of them without having to keep a reference or go looking for the view controller in our hierarchy.

That’s basically it for Coordinator’s. A big part of how our coordinator’s will handle everything has to do with the ViewModel’s so that’s the topic we will discuss next.

iOS Architecture: MVVM-C, ViewModel’s (4/6)

iOS Architecture: MVVM-C, Coordinators (3/6) was originally published in Sudo by Icalia Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s have a thought experiment. Take a typical view controller and split it into two parts. On one side leave all of the UIKit/UIViewController specific methods and everything that deals directly with views and subviews. And on the the other side put everything else, all of your business logic; i.e. network requests, validation, preparing model data for presentation, etc…

So basically, the former part (UIKit stuff) will remain, as it should, in the view controller. Everything else, all of app specific business logic, will now be in the ViewModel.

This separation helps the view controller adhere to the single responsibility principle. Now the view controller which is a part of UIKit as it’s a UIViewController subclass only deals with UIKit stuff. Handling rotation, view loading, constraints, adding subviews, target actions, etc.

This leaves the ViewModel totally clear of UIKit land. Which let’s it focus on the core business logic, adhering to SRP. This makes it much easier to reason about and to test, among other things.

The ViewController will have a one-to-one relationship with the ViewModel. There will be one ViewModel per ViewController, and the ViewController will own it’s ViewModel. By that I mean that it will own a strong reference to it’s ViewModel, but it will not create it itself, it will get passed on to it via dependency injection. In our case, it will get created by the Coordinator and passed on to the ViewController.

Let’s see some code

First step for creating a ViewModel is defining a protocol. ViewModel’s should be protocol based because when you inject the ViewModel dependency into the view controller we don’t want to depend on a concrete type. This let’s us experiment with different implementations, for testing or other purposes.

Protocols

There should usually be three protocols:

• YourNameViewModelType: This is the protocol that our ViewModel’s should implement. It is conformed of two main parts. The Data Source which will have all the formatted data the view controller needs, and the Events which are events that the ViewController will send up to us on any user action.
• YourNameViewModelCoordinatorDelegate: This delegate protocol will let us bubble up any action’s that we can’t handle and must be handled by our coordinator. This delegate should be set by the coordinator when it creates each corresponding ViewModel.
• YourNameViewModelViewDelegate: This delegate protocol will let us communicate with the ViewController. Whenever we have new data for example, we let the ViewController know so it can update it’s screen. Since the view controller owns the ViewModel we don’t want to create a reference cycle by holding onto a strong reference of the view controller. So we have a delegate which is set by the view controller to itself when the ViewModel gets injected into it.

If you choose to use a framework like RXSwift or ReactiveCocoa to do Funcional Reactive Programming, then the ViewModelViewDelegate protocol and the event methods inside the main protocol would not be needed because all two-way communication between your ViewModel and ViewController would happen via those frameworks. But those topics are beyond the scope of these articles. I personally think that this is a good way to architect this without having to introduce any other foreign concepts, at least for now.

Implementation

Let’s look at our sample implementation.

In this previous code we have three important parts:

• We have several properties which include both our delegates, our data models, and a service layer object. (More on services next)
• We have an init method in which we should get all the dependencies we will need. In our case it’s the Place service which will let us do network requests.
• An example of network requests that would happen in the ViewModel, and how we would use the viewDelegate to let the ViewController to update it’s screen to reflect the new available data.

Data Source & Events

Besides all our business logic like network requests in this example, we need to implement the ViewModel’s protocol.

• The Data Source methods will handle formatting any model data the ViewController might ask for. We don’t want to send any model object directly to the View layer so usually we will only return formatted String’s or other struct’s like ViewData’s (More on that next).
• The Event methods will get called by the ViewController when there is a user action and we need to do something about it. Sometimes we will need to kick off a network request, or sometimes if it’s a navigation issue we will need to bubble it up to the coordinator via the coordinatorDelegate.

ViewController

So how will this look from the ViewController side? Let’s see some code. I cut most of the code out of the example just to show you the basic idea.

A couple of important points in this example:

• We have a strong reference to the ViewModel and we have a didSet listener ready to set ourselves as the viewDelegate once this get’s set on us by the coordinator.
• We use our viewModel reference to get all the formatted data we need, and to send any relevant events.
• And finally, we implement the ViewDelegate protocol so the ViewModel can let us know when we have to update our screen.

Conclusion

That’s basically it. All the major parts of the architecture have been covered. The Scenes which own a storyboard and a Coordinator which instantiates ViewController’s with their respective ViewModel’s.

The next and last two parts of the series will focus on two other “extra” patterns that I think are really beneficial to the overall structure of the architecture.

Let’s start with ViewData’s since I already mentioned them in passing up above.

iOS Architecture: MVVM-C, ViewData’s (5/6)

iOS Architecture: MVVM-C, ViewModel’s (4/6) was originally published in Sudo by Icalia Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a little bit of a controversial concept, and you won’t usually hear it mentioned when talking about iOS architectures, not by this name at least.

This is basically an off-shoot of the ViewModel concept. I learned about this concept after hearing an awesome discussion on the Fatal Error iOS development podcast, on their ViewModel episode, in which Soroush Khanlou mentioned using something called a ViewData. I don’t really know if his idea of this concept and mine are completely equal, but I’ll try to at least explain mine.

The reason why I say this concept might be controversial is because reading up on ViewModel’s on the web I realized that there were two camps. On the one side some developers think ViewModel’s should be these reference based, live objects that make network requests and all sort’s of stuff. Basically, what I explained on the previous article on ViewModel’s.

But there was another camp, which said ViewModel’s should be much simpler, just a simple struct. It should do no network request or anything of the sort. It should just be a simple wrapper around a specific Model which formats it’s properties for presentation by the view, but that’s it. No two-way back and forth communication.

Altough I came on the side of that ViewModel’s should be live objects handling all the business logic, that’s why I decided to use term Soroush coined, this other concept of a ViewData and use that as the simple wrapper around a model. Best of both worlds!

What is a ViewData?

So in simple terms, a ViewData is just a dumb wrapper that takes in a model like for example a Trip and wraps it up in struct called TripViewData. This ViewData can then be sent from the ViewModel to the ViewController, without having to send the bare model. As we know the view should not be dealing directly with model objects, and since MVVM considers the ViewController part of the View layer then we must give the ViewController already formatted data ready for presentation.

So a ViewData is basically a much simpler, inert version of a ViewModel that we can use to wrap around our model objects.

Let’s see some code

As always, we start with a protocol. Our View layer should not depend on a concrete implementation. It is quite common that we might want to use a different implementation of this same ViewData in a different part of our app, or do some testing as well.

In this case we have a Trip model, therefore we create the TripViewDataType protocol.

The protocol should have any user facing, formatted for presentation properties the ViewController/View might need from our model. The View layer should have to do no extra work to get this data ready.

Then we can implement our protocol using a struct.

Our view data implementation should do two things:

• Have an initializer in which we get the actual model and any other extra information we might need.
• Implement the ViewData protocol so the View layer can get everything it needs from the model without actually seeing the model.

Usage

This is how we might use the ViewData in our Trips ViewModel.

Our ViewModel has access to all the Trips. But whenever the view asks for one of these trips it returns a TripViewData to it. Remembering to return the protocol signature, not the actual concrete implementation.

Conclusion

That’s it! This ViewData concept is basically just an off-shoot of the ViewModel concept, and when these two concepts are used in tandem it can be a powerful way to design your architecture. ViewData’s wrap around Model objects to prepare them for presentation by the View, they have a one-on-one relationship with a Model. They are similiar to the adapter design pattern. ViewModel’s can also do that, but they are a more powerful concept that do much more than wrap around models, and they have a one-on-one relationship with the ViewController’s.

Up next, in the final article in the series we talk about Services.

iOS Architecture: MVVM-C, Services (6/6)

iOS Architecture: MVVM-C, ViewData’s (5/6) was originally published in Sudo by Icalia Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

This will be the first article in a series of six articles detailing my specific implementation or flavor of the MVVM-C iOS app architecture pattern.

If you want a general introduction to the different architectures in the iOS world please check out my previous article where I go over them.

It is a combination of the Model-View-ViewModel architecture, plus the Coordinator pattern. My specific implementation has more parts to it than that but the tech world does not need any more longer and complicated initialisms. MVVM-C is already out there so I’ll just build on top of it.

I recommend going through them in order for it to make the most sense.

1. Introduction (You are here)

2. Scene: Here I go over my concept of a scene and why I think it’s important to modularize the app according to this concept. This may also be referred to as a “use-case”.

3. Coordinator: I go over my implementation of the FlowCoordinator pattern, and it’s relationship to the app’s Scenes.

4. ViewModel: Here I talk about my implementation of the famous MVVM architecture, which in my case is just a small but important part of the architecture as a whole.

5. ViewData: This is the first one of two concepts which I think is really important for my implementation of this architecture, but I don’t think it needs to be added to the name, MVVM-C-VD would be a mess. It is a related concept to the ViewModel but a little different.

6. Service: MVVM-C-VD-S would be even worse! So it’s also not included in the name, but I think it’s really important as well. If you’ve read about the Service Layer pattern you know what I’m talking about. I’ll go over my specific implementation of this pattern and how it fit’s into the whole.

This is how the overall architecture will look. Don’t worry if you don’t understand what each part is doing, once we reach the end of the series it will hopefully all make sense.

Go ahead to the next article in the series:

iOS Architecture: MVVM-C, Scenes (2/6)

iOS Architecture: MVVM-C, Introduction (1/6) was originally published in Sudo by Icalia Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

The service layer is a design pattern that has been around for decades. It is based on the concept that a system should be separated into different layers, like an onion, with different responsibilities on each of each of those layers. The service layer should be the connection to the outside world, whether that be a database, a remote server, a bluetooth connection, etc.

In that service layer there should be multiple Services and each one of those should have a single responsibility of dealing with a specific kind of service or resource.

That’s basically it, it’s actually a simple concept, and we are probably already using it in one way or another in our app. We usually have an ApiClient class that deals with a REST API on a server for example. But the point I want to make, and the reason this fits in well with the architecture we’ve been building throughout this series, is that we should organize and architect this layer to take the most advantage of it.

Let’s continue working on the ApiClient example. All of us are probably already familiar with the concept of an ApiClient. We build an object that has the responsibility of making HTTP requests, either based on Apple’s URLSession or some other framework. But that should be it, that should be it’s sole responsibility. It should have no knowledge of our models and our business logic.

So if all that business logic can’t be in the ApiClient, and most definitely should also not be in our lower ViewModel/View layers, where should it go? That’s where the Service layer comes in.

A Service implementation

A service will usually wrap around some sort of client, in this case an ApiClient, and add all the the model parsing and business logic on top of it. We might be tempted to create just one ApiService to handle all of the API needs in our application, and in a really simple app it might work.

But what I recommend is that we separate Service’s, even if they are of the same kind like in this example, by logical units. For example, you might have a SessionService which deals with login/signup, and a PostService that deals with posting pictures up to your server.

This way, when a ViewModel get’s injected with the Service it needs it is getting a specific Service that deals only with the needs of that specific part of the application. Again, SRP.

Let’s see some code

This is an abbreviated example of a really simple service. A PlaceService that let’s us search for places on our API.

We start with a protocol that outlines the action’s we will call on this service. Having a protocol here is really useful because we might want to switch out the implementation that does these same action’s but with a different source, like a different API or cache. Or, as always, it makes testing much easier.

Afterwards, we move on to an implementation. In this case its the PlaceApiService. Because it’s going to use an API to fulfill the protocol. But we will be dealing with the protocol type almost everywhere in our app, the implementation will be hidden from us.

There’s two parts to this code:

• We must take in any clients we will need to perform our actions.
• Then we must implement our Service protocol. In this case we internally use our ApiClient to fulfill the protocol making requests to our API. Here is where we should know what model’s there are, what endpoints will be used, what parameters, etc.

Don’t worry if you don’t follow my implementation of these methods, it is just meant to give you an idea. You should do whatever it is you need to do to make these requests here.

Usage

Then in your Coordinator you have to set up this service and pass it on to your ViewModels for usage. Since our Coordinator already has an ApiClient that was passed onto it as a dependency, it can use that to create the Service.

In this example whenever we create this ViewModel, we create a concrete implementation of a PlaceService and initialize the ViewModel with it. Remember, the ViewModel should depend on the abstract protocol for the service, only the coordinator which is responsible for setting up dependencies knows about the concrete implementation.

Conclusion

Although these last two parts of the architecture are not the most important parts and they are not part of the architecture name, I think they really round the architecture out and make it very complete.

This architecture implementation was arrived to after learning about many other architecture implementations, and by organic iteration using it in many production apps. Altough it is pretty solid and has been used in major production apps, there is definitely room to improve and add other concepts to it.

Take a look at the diagram again to see if clicks! Let me know.

iOS Architecture: MVVM-C, Services (6/6) was originally published in Sudo by Icalia Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is architecture? What does the word actually mean? If you look in the dictionary you have two main definitions.

The art or practice of designing and constructing buildings.

The complex or carefully designed structure of something.

The first definition is the one most of us are probably familiar with, it’s designing a building (or any other kind of structure). Before you can actually build a house, for example, you have to design how it’s going to be built. You have to design how it’s going to look, how it’s going to work, which doors will lead into which rooms, where support beams will be, etc.

This leads us to the second definition: The complex or carefully designed structure of something. This takes the same idea as before and applies it in a more general sense. It is the thoughtfully designed structure of something. The something we are going to talk about here is Software.

It is inconceivable that someone would start building a house without a blueprint, without any kind of plan or design. It’s obvious that before you start building a house you need to have a well thought out, designed blueprint that follows standard industry patterns, amongst other things. One of the many reasons for this is because after the house is built (or half-way built) it is going to be hard, if not impossible, to go back and change the basic structure of the house. Also, if you have no blueprint or design I can only imagine the mess of a house it would be, with inconsistencies and surprises at every corner.

Well the same applies to software. We should design our system so we have an idea of what high-level structures we will have, what are going to be the relationships between them, and what will be the inputs/outputs of each structure. This will make our system easy to reason about and understand. Change in a software system will inevitably come, so if we have a solid architecture, changing out specific modules of a software system should be simple without having to change the overall high-level structure.

Software architecture is about making fundamental structural choices which are costly to change once implemented.

iOS App Architecture

So how does this all apply to iOS Applications? So let’s start with the basics. We couldn’t talk about iOS architecture without talking about Model View Controller (MVC).

MVC is was invented at Xeroc Parc in the 70’s and it first appeared in the programming language Smalltalk-80. It’s a really simple architecture which separates all objects in a software system into three buckets. These may be a little different depending on the domain you are working on, but for iOS these can be described like so:

• Model: Anything that deals with storing data, transmitting data, and the data itself.
• View: Any user visible object which displays something on screen and handles user input.
• Controller: The mediator between the Model and the View. The controller updates the Model, and the Model notifies the controller that there is new data. Then the controller updates the View, and the View sends all user action

There is no way around MVC in iOS. All subclasses of UIView, which can be shown on screen, are your Views, and all subclasses of UIViewController which control control and own those UIView’s are controllers. And basically everything else is the model. So in a way MVC is the “official” Apple way to handle architecture in iOS/macOS/tvOS/watchOS apps.

If something in the last paragraph sounded a little off, you might be onto something. The sentence, “basically everything else is the model”, is true in many cases. The other objects, in a simple app at least, will be data models, database or server/API access objects, and those are the Model. But herein lies the problem with MVC. It’s too simplistic to assume that everything will be either Model or View or Controller and that’s it. There is no place for other kinds of objects with other kinds of responsibilities.

This is where other architectures come in. I don’t think any of these other architectures are meant to competely replace MVC, because as I said before, MVC is the “only” way to build Apple software because that is the way the Cocoa frameworks are designed. I think of these architectures as a way to expand/redesign/rename/improve MVC to properly account for all the kinds of objects a complex modern app can have.

Beyond MVC

There is no way I could metion all architectures that exist for iOS development since this is something that changes in the community, as people explore and design new ways to architect iOS apps. But the ones I’m going to briefly introduce are the ones I consider to be the most important, and which can be used as a base to build and design our own architectures.

MVVM

Model-View-ViewModel is one of the most common post-MVC architectures in the iOS community. It was originally coined by Microsoft in 2005 to be used in their Silveright software.

What it technically implies can vary depending on your domain or technology. But in the iOS world it is basically an expansion of MVC. The Model is still the Model. The View is still the View, but it now also includes the controller (UIViewController subclasses) inside the View umbrella, since it’s so tightly coupled with it anyways. And finally, it introduces a new concept, the ViewModel.

The ViewModel can be thought of as an improvement of the controller concept. It is the mediator between the Model and the View. You can think of this as basically splitting the controller part in MVC into two parts. One is the UIViewController subclasses which now belong inside the View, and the other is the ViewModel.

This can seem like a really simple change but it’s incredibly powerfull. It makes ViewController’s extremelly simple because now all they have to worry about is controlling the UIView and reacting to events, and all of the complicated bussiness logic now goes in the ViewModel. This decouples our ViewModel’s from Apple’s frameworks and makes them much easier to test.

FlowCoordinator

FlowCoordinators or just Coordinators as they are usually referred to, are also a simple concept. Usually in our iOS apps the ViewController’s handle the navigation. What I mean by this is that when a user clicks on a button in our apps the ViewController (or the storyboard which is even worse!) is responsible for deciding what should happen next, what ViewController I need to instantiate and present or push onto the navigation stack.

This may be ok in a simple application. But this makes for really coupled code in a complex application and makes ViewController’s really hard to re-use. The idea is to move all of the high-level navigation logic up into a Coordinator. This makes ViewController’s much more re-usable as they only need to inform the coordinator that something happened, and they are free of any other responsibility.

The coordinator then is responsible for knowing which ViewController’s to instantiate, to either present or push them, and to inject any dependencies the controller might need. This last point is one of the biggest benefits of using coordinators. Without using coordinators, passing along dependencies (which is a recommended practice!) is a hassle. This leads to having to pass a dependency to multiple controllers just to get it to the controller that needs it. Or, even worse in some cases, having to use (or abuse) Singletons.

VIPER

VIPER is one of the most complete iOS architectures out there. Instead of focusing on only a specific part or problem of an architecture it aims to create a completely new architecture from the ground up. I have not used VIPER before not because I don’t like it but because I think architecting your iOS app should be more of an art, and it should be built for your the specific needs of your app, and VIPER is so complete that it really leaves no space for you to create your own.

VIPER is the whole package and I personally prefer the approach of creating a custom architecture that fits your app, obviously basing it on top of and borrowing from other architectures. That is why I think it’s important to mention VIPER and read about it, because it is a great example of how a complete architecture can look. And as you’ll see, most of the parts of VIPER already exist in other architectures just under different names. So it’s a really useful example to learn more about iOS architecture.

VIPER is split into these parts:

• View: The same View we know and love.
• Interactor: All different modules of Business logic your app can have. (Similar to ViewModel)
• Presenter: Prepares content for display. Interacts with View and Interactor. (Also similar to ViewModel)
• Entity: The plain data-Model objects. (Model)
• Routing: Logic for displaying screens and navigating. (Similar to coordinator)

Conclusion

This article is meant as a very high level introduction of what iOS app architecture is, why it’s important, and to introduce some of the basic concepts of the different architectures out there. This is in no way a complete look at all of this subject, I recommend you use this as an introduction to the subject and keep learning about this. I will include some links below.

This article is also meant as an introduction of a series of architecture blog posts I wrote detailing my own implementation of the MVVM-C (Model-View-ViewModel-Coordinator) architecture. This is obviously not an architecture I invented, it’s out there, but I think it’s interesting to share my own specific implementation that I am using in a big production app I am working on.

There is no universal guide to iOS architectures so all we can count on in the iOS community is blog posts and sample code from other developers to learn more about this subject, so this is my contribution.

Sources, Further Reading

• Software architecture - Wikipedia
• Addy Osmani
• An iOS Coordinator Pattern
• Improve your iOS Architecture with FlowControllers
• Khanlou
• Architecting iOS Apps with VIPER

Introduction to iOS App Architectures was originally published in Sudo by Icalia Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

But still today you will want to use XIB’s for some cases when storyboards are too much. Unfortunately loading from XIB’s can be confusing sometimes as there are several ways to do so.

That’s why I created these extensions to make it a little bit easier and less error-prone.

Loading a View Controller’s view from a XIB file

Doing this is pretty simple:

let viewController = MyViewController(nibName: "MyViewController", bundle: nil)

But the information needed to load this View Controller is outside the class itself, and it’s using a String which can be error prone. That’s why I prefer to do this in an extension on UIViewController, like so:

All I’m doing here is getting a String representation of the View Controller’s Class, and also getting the Bundle for that same class (in case we are inside a framework or extension). Then I’m loading the nib and returning it.

Then inside my UIViewController subclass all I would need to do is override the loadView() method, and set the view property.

Afterwards, loading my View Controller can be as simple as this:

let viewController = MyViewController()

Loading a custom UIView subclass from a XIB file

Loading a View from a XIB file is usually a little more complicated because there are several ways to do so. But I like to do it with an extension on UIView, like so:

The loadFromNib() method is similar to my previous method on the UIViewController extension. But this one is a little more complicated, because instead of returning the View, it goes ahead and adds it as a subview and sets it’s constraints, so that my all my custom UIView subclasses don’t have to add that boiler-plate code.

Then you can create a UIView subclass, and use it like so:

Things to consider

• Remember to create your XIB file and set the “File’s Owner” to your UIView or UIViewController subclass.
• The name of your XIB file must be the same name as your subclass. That’s because the name the extension uses to load the XIB is the String representation of the subclass.
• This is the way I do it and it’s worked great for me. But if you have any improvements, or questions feel free to ask in the comments.

Loading views from XIB’s on iOS was originally published in Sudo by Icalia Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

I used to keep my entire library of photos on Apple’s Aperture application. But last year Apple announced they were discontinuing both Aperture, which was focused for professionals, and iPhoto which was geared for the consumer crowd.

The replacement for both of these was to be called Photos, which if it seems familiar is because it’s the same app you can find on any of your iOS devices. Apple was bringing the same simple, streamlined Photos app from their iOS devices to their Mac OS laptop and desktop computers.

Not only that but they were also introducing iCloud Photo Library which is their new smart photo syncing mechanism (No more Photostream, which was not good), which will sync your entire photo library between all your Apple devices. And, the reason why it’s “smart” is because you can have it keep originals in the cloud and on any of your devices, or you can choose to intelligently optimize the device’s storage.

What this means is that the Photos app will see you much free storage your device has at any given time, and choose a percentage of that which it will use for storing photos. It will only keep your recent and frequently seen pictures in full resolution on your device’s local storage, and all the other pictures will only be on your device in small thumbnails and the full resolution pics will be in the cloud. Which will be ready to be downloaded whenever you want to access them. That way, no matter how large your photo library is your device will never run out of storage.

Another great feature of Photos & iCloud Photo Library is that it will not only sync your pictures, but also the edits you perform on them, on any of your devices. It will always keep the original picture and the edited one, on all your devices. So you can edit a picture on your iPad, continue editing it on your Macbook and revert all the edits on your iPhone since edits are non-destructive.

All that is great, and the Photo’s app does have all the usual editing features you would expect (Cropping, White Balance, Exposure, Temperature, etc…) and some simple, if a little “unprofessional” looking filters. But there is definitely room for more ways to edit your pictures. More filters, film effects, object removal, etc…

That is where Photo Editing Extensions come in. These are new in OS X — El Capitan, but have existed on iOS since iOS 8. These Extensions are like a plugin, in which a third party app can inject some new functionality into Apple’s photos app. Since El Capitan came out there are about 4 apps that have Photo Editing extensions on the App Store, but they are mostly for touching up photos, removing objects, and other specialty things. What I really wanted were some subtle film like filters, and effects (like tilt shift, grain & fade).

So, that’s what we did. By we I mean my awesome & talented graphic designer friend, Noe Araujo (who got married yesterday, congrats!) and me. We decided we wanted to do a simple and beatiful photo editing extension which included the things we wanted to do with our pictures.

Check it out on Instagram, http://instagram.com/lochkamera.co

It’s waiting approval from the Mac App Store so it should be out soon, stay tuned!

As our photo libraries become bigger and bigger there is a huge need for a simple and automatic way of organizing and backing them up. The “cloud” let’s us do this, and for the people that are inside the Apple ecosystem, Photos is the future of photography on Apple devices.

This refactoring does exactly what its name implies. It replaces a long and difficult to understand method and places it in it’s own class. The multitude of local variables that you probably have lying around in that method then become instance variables on the new class.

Afterwards, you probably want to go further and decompose that long method into smaller methods (we should always have small methods) in the new class. This should be easy, since all our local variables are now instance variables, you don’t have to worry about passing a ton of parameters around.

For example, say we have this method in Swift: (This code was shortened and edited for clarity, it was even longer than this.)

func imageFromCurrentFilterChain() -> NSImage?
{

  var filterChain: [GPUImageFilter] = []

  var inputGPUImage = GPUImagePicture(...)
  var lutImage = GPUImagePicture(...)
  var grayColor = GPUSolidColorGenerator(...)
  var grainImage = GPUImagePicture(...)

  if filterChain.count == 0 && !applyBlur{
    return input?.displaySizeImage
  }

  inputGPUImage?.removeAllTargets()
  lutImage?.removeAllTargets()
  grayColor.removeAllTargets()
  ...

  if !filterChain.isEmpty{
    inputGPUImage!.addTarget(filterChain.first)
  }

  var previousFilter : GPUImageFilter?

  for (index, filter) in filterChain.enumerate(){
    
    filter.removeAllTargets()

    if index != 0{
      previousFilter?.addTarget(filter)
    }

    if filter is GPUImageLookupFilter{
      lutImage = GPUImagePicture(...)
      lutImage?.addTarget(filter)

    }else if filter is GPUImageLightenBlendFilter{
      grayColor.addTarget(filter)
      grayColor.setColorRed(...)
      grayColor.forceProcessingAtSize((inputImage?.size)!)

  }else if filter is GPUImageOverlayBlendFilter{
      grainImage.addTarget(filter)
  }

  previousFilter = filter
 
  ...

}

You should never have huge methods like this! All of that could become a new class called FilterChain with an interface sort of like this: (Pseudocode)

class FilterChain{

  instance var filterChain
  instance var lookupFilter
  instance var lutImage
  instance var grayColor
  instance var grayImage

  initWithArray(Array){
    ...
  }

  removeAllTargets(){
    ... 
  }

  setupLookupFilter(){
    ...
  } 

  setupLightenBlendFilter(){
    ...
  }

  public imageFromCurrentFilterChain(){
    ...
  }

}

Then, your old method would look like this:

func imageFromCurrentFilterChain() -> {
   return filterChain.imageFromCurrentFilterChain()
}

This makes each class have it’s own specific responsibility, and now you can reuse the FilterChain class other parts of your code or different projects.

Refactoring 101: Replace Method with Method Object was originally published in Sudo by Icalia Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.