Let me add my couple of cents about iOS Design Patterns. Recently I researched (and personally experienced) and was surprised that one of the most popular architecture patterns for iOS applications is MVVM + Coordinators, which means almost 30% of medium and large applications are using this architecture more-less. Yes, MVC is one of the most usable too, but I’m talking about applications like financial instruments, mobile banks, educational apps, shops, delivery apps, and more. It’s understandable why, supporting more complicated, let’s say VIPER, is more expensive because businesses want to see a new feature in production asap. After trying to keep code cleaner, engineers come to the MVVM just because this pattern is more convenient and flexible for scale. As a software engineer I have the energy to contribute to the community and who knows maybe this particular example will be useful for the iOS community. Here in this text, I will try to reduce abstractions because from my experience I see sometimes it doesn’t work well to explain complicated things. I will just show you a simplified version. If you are reading this text, you are most likely already experienced guys, you know the basics and are ready to digest and discuss information about at least clean coding approaches. That’s what I want from you after reading this article. App family To be more precise about what we are going to do, we need to consider a situation: let’s say we have a family of iOS applications (2 or more applications). - ... - App One - App Two All these applications are different but with the same UI components, screens, behaviors, and features. And our task will be to design an architecture where all these pieces will be independent and sharable. After identifying the components which are sharable we can move them into the framework. Let’s call it Common. So, this framework is our focus and there we will prepare a foundation. Framework Let’s structure the Common framework where we will create four groups: Views, Base Controllers, Protocols, and Services. ├── Views
├── BaseControllers
├── Protocols
└── Services Common In Views, the folder contains only ready-to-use that could be used everywhere in the apps. In our case, we put there ProgressView and BaseButton. UIViews folder contains View Controllers for inheritance. For example, , and for SiwftUI views, and . All these base controllers already have a property of which can be started and stopped spinning. BaseControllers BaseViewController BaseHostingController BaseNavigationController ProgressView The protocols folder consists of all protocols which are common, for example, , , and so on. We will figure out about them later. BaseViewModel Coordinator Services. Let’s say our family applications use some services and part of them are sharable, for example, and . CommonServiceOne CommonServiceTwo Dependencies Designing dependencies in our case means we will combine all our services into one place and this place will be reachable and can be configurable from all view models. The main idea is that our Common Dependencies object should be opened for inheritance from the applications which are also can have some services which will lay together with common services. As you already know we have two common services. Let’s create two protocols for them: and . HasCommonServiceOne HasCommonServiceTwo As you can see protocol Dependencies are inherited from the two protocols that require to have the services. The property appId will allow identifying an app which are using the services. It’s helpful for some requests that should contain app id in the paths. Finally, we have a class that conformed Dependencies protocol with initialized our two services. Regarding the services, they have just two methods that print the line with the app id: CommonServiceOne } func commonServiceOneMethod () { print ( "== Common Service 1 method fired from \(appId) " ) CommonServiceTwo } func commonServiceOneMethod () { print ( "== Common Service 2 method fired from \(appId) " ) So we will use it later to understand from where we can access them. Dependencies should be accessible from view controllers so for that we need an additional protocol that can be named : WithDelegates Coordinator The protocol Coordinator has typical requirements for any coordinators in the projects. It means it can be also in a common framework. Let’s take a look at what is in there: If you are familiar with the Coordinator design pattern then you should know already why we need these methods. Super easy, — for starting the coordinator with an initialized view controller, and — for poping view controller from the navigation stack. As you can see this protocol has an extension where we can predefine this behavior for both methods. start() finish() BaseController We need an additional protocol to combine two View Controllers: and . As you know they have , and two methods that can start and stop spinning. We are going to move these methods and define requirements for the Base Controllers. BaseViewController BaseHostingController ProgressView BaseViewModel Of course, if the apps then we need to identify common methods. Let’s say it will be: . Additionally, to interact and delegate some jobs to the we need to have a . haveViewModels prepareViewModel() ViewControllers viewDelegate Base Delegates Two delegates. The first one is for View Controllers and the second one is for Coordinators. Let’s take a look at them. BaseViewModelViewDelegate Using this protocol for all we will allow to show and hide activity indicators without repeating these methods in app’s . viewDelegates viewModelViewDelegates BaseCoordinatorDelegte A similar approach in . coordinatorDelegate BaseViewController and BaseHostingController protocol combines two where is . BaseController ViewControllers viewModel BaseViewModel Application All basic components of our framework are done, so it’s time to use them in our applications. It's time to define an app structure: Based on the schema above, we need to prepare: , AppDependencies, Home Module, SignIn Module. Using the prepared Common Framework we can use the protocols from there to prepare all these pieces of the app. AppCoordiantor App Dependencies and services Let’s say an application has its own services and we need to combine them with shared services. For that our protocol Dependencies and opened class will help us. CommonDependecies As you can see additional app services are initialized in the same way as in the common dependencies. So, for now, our has 4 services that we can use across the app. AppDependencies App Coordinator In this implementation, you can see how we can use protocol. will be used in all modules: and . Also, take a look at coordinator delegate and how it is used. To push the view controller to the stack it’s enough to use only method that already exists in protocol. WithDependencies AppDependencies Home SignIn HomeViewModel show() Coordinator View Models The most interesting part is using view models. Again, our view models don’t know about the view and coordinator, that’s why they are independent. Common protocols: and help to encapsulate an implementation where we can potentially use dependencies. BaseViewModel WithDependencies Also in we can use directly some that is defined already in . But, wait, BaseViewModel doesn’t use protocol . So, let’s say we need to use it in all our applications from all . For that we need to update in Framework using this way: prepareViewModel() commonServieMethod() BaseViewModel WithDependencies viewModel BaseViewModel This means the can be used only from View models but not from the views. methodsomeCommonServiceMethod() Additionally, if you don’t need all dependencies in the view model you can specify the particular ones: } final class SignInViewModelImplementation < Dependeincies : HasAppServiceOne & HasAppServiceTwo >: SecondaryViewModel , WithDependencies { What about family? An idea is simple - using the protocols and the classes with associated types from the ﻿Common framework your next app with MVVM + Coordinator will be structured in the same way as the first one but your modules and behavior can be different. The services, coordinator, and base controller will take common responsibility. In this example, it's only showing and hiding activity indicators, but in real applications, you could have a lot of staff. For instance, shared localization resources and a service for managing the strings by a key that can be used from all applications in family. Wrapping Up Recently I had a problem when I needed to prepare a framework with sharable components for multiple applications. Making this kind of framework allowed me to move maintainability to the next level. It means we could scale our projects and this framework without discussing it. Everyone from the team understood where and what they need first before starting a new feature. As you noticed the barrier of entry is really low because you don’t need to know specific things, everything implements in a swifty way. Also, it can be applied with RxSwift or Combine as well. Thanks for reading! Source Code

This story contains new, firsthand information uncovered by the writer.

A Look at the MVVM Design Patterns for iOS

Too Long; Didn't Read

Companies Mentioned

@maxkalik

Credibility

RELATED STORIES