The data layer (an iOS architecture part V)

Old library

The aim of this post is just to explain how to organise the data layer in an architecture. A possible definition of data layer is where the application data is being cooked and served ready for consumption to upper layers.

Data layer is fully responsible of providing data to domain layer, upper layers does not know the origin of the data ( local configuarion, local ddbb, json data, rest api…).

⛔By no means any of the data structures/classes provided by data layer could be transformed by domain or view layer components.

👉Data layer is responsible of notifying any change in the data, in that way views presenting the data affected will be invalidated and forced to fetch the data again.


Data Manager

This component is the outer facade of the data layer, all the domain components will interact always with this component.

👉Data manager is responsible of requesting data to the rest of data layer components and implement all the politics related with data acquisition. Examples of those politics could be:

  • The app configuration is fetched from a rest service, when is not possible to perform such operation, then tries to recover data from persisted data.
  • Persist data remotely via rest service, when not possible data is stored locally. Later on if it is possible, data can be synchronized with the backend.
  • Depending on the criticity of the data could decide whether store data in a persisting securized area or a regular one.
  • Reset all persisted data wether is database, userdefaults or keychain. 💕Very useful if you wanted to reset the app without having to reinstall the app, or just to initialize data layer before executing unit tests.

JSON Manager

This component is the responsible to modelize data persisted in a json file.

Configuration Manager

This component is the responsible of persisting all the app settings.

Security Configuration Manager

This component is the responsible of persisting all the app settings related with the security of the app (e.g. keys, api-keys, information that could identify app user,…). Usually this component is an adaptor of keychain

DB Manager

This component is the responsible of persisting all massive app data. This component could be an adapter of Realm, CoreData or SQLLite.

👉As well as Data Datamanager no other outer component has to know the database technology that wraps.

⛔By no means any internal database entity should have to be exposed to the other components. DB Manager has to convert them to generic ones before providing then to the rest of the components. Following that rule you will get benefits of replacing db technology without major impact in the app.Replace DB technology without any impact on the app.

API Manager

This component is the responsible of fetching or persisting data in the backend via REST api’s. This component is usually an adaptor of URLSession or any other third party library such as Alamofire.


In this post we have reviewed which is the role of Data layer and its components. This post closes all the ones dedicated to this iOS Architecture.

The Domain layer (An iOS architecture part IV)

The aim of this post is just to explain how to organise the domain layer in an architecture. A possible definition of domain layer is where the application business logic is implemented, or the told in the contrary way what is nor view neither data acquisition.

The domain layer is the fuzzy invisible border between View and Data layer. But as app grows in complexity (and in lines of code) is the cornerstone of your development, so this is why is important to have this layer under control.



The sequencer is the component that will handle the start up sequence, this is something thats starts very simple at the beginning of the implementation, but as time (and requirements) goes on could turn into a really nightmare 🎃. You can find the implementation details in the following post.


Managers is the wrapper class for accessing to a unique device services like bluetooth, maps, gyroscope… Or in case that you wanted  to centralize a behaviour in a single class, for instance, a Session Manager for controlling wether a user was logged properly or not. This class is a singleton implementation.

Up to here this is good about this component. But watch out, to start abusing them! Is quite common that will start appear singletons as mushrooms. I recommend to read the following post.

Use Cases

Use cases functions are the entry point for any functionality requested by views.  The reason for living of this component lies in:

  • Unload task from views. Helps to reduce Massive View Controllers problem.
  • Reusability. Is likely that you use the same functionality from different views.
  • TDD. You can apply unit test to this function class.


Coordinators controls the flow of screens presented, is the coordinator who decides which is the next screen to present, not the view any longer…

This will help to reduce the amount of code to put in the view, and also its reusability, the same view can be placed in a totally different screen flow.

Use cases and coordinators working together but not mixed

Presenters interacts with use cases when some functionality has to be performed (e.g request data from a service, try to connect to a bluetooth device, get a map pinpoints,…). But in case that presenter considers that is no more longer usable (e.g. user select dismiss button to remove the view, or selected an item for pushing another view with the item details) it has to interact with the coordinator and will be the coordinator who will decide  which is the next view to present.


In this post we have reviewed which is the role of Domain layer and its components.

What’s next

In the next post will be presented the Data Layer and how to retrieve data independently where is phicially stored (ddbb, service, keychain, user defaults… ).


Reusability in view layer (An iOS architecture part III)

The aim of this post is to reinforce the reusability in view layer, it will be presented a way to handle the fonts (and its sizes), colours, texts translations and accessibility labels (for automated UI tests).

This post is the continuation of  the view layer (an iOS architecture part ii) and part of it is based on the following presentation but supported with a sample project in case you want further investigation or adopt the technics explained in your projects.

The view layer (An iOS architecture part II)

Fonts (and its sizes)

For better folder organization we have placed the font files into ViewLayer/Resources/Fonts:
☝️Do not forget add the resource to project target:

Also do not forget to add the fonts also in the Info.plist:

Edit the Info.plist and add the following chunk of xml:

The helper for the font sizes is placed at ViewLayer/Resources/Styles:

For each presenter we have defined an structure that gathers the fonts that is using, this approach lets you have centralised in a unique file the font definitions for WHOLE app:

I let the reader to download the sample project and review the rest of structures contained in the file for further understanding.

Finally for setting the file in the outlet is as simple as:

And the result is the following:


For colors we will use the same approach as in fonts, define a helper in Styles folder:

As well as in fonts  we will define the palette of colours used as well as the palette-dolors used by each presenter:

Finally for setting the color in the @IBOutlet:

And the result is the following:


We have just created a string extension for automatically handle the translation depending on the project language bundle:

For avoiding the problem of text identifiers during execution time, we use R.Swift so during compilation time we will know if resource really exists or not. This is also very useful for images, cell reusability, segue identifiers… In that way you will avoid bugs related with identifiers that do not match with the resource. 🚑 Really, do not hesitate in incorporate this pod in your projects!!!!

Finally for set the texts is as easy as:

Even that constants has 6 elements in the keypath, 5 of them are always constant: R.string.localizable.<textId>.key.localized

Accessibility labels

iOS developer will not get direct benefit in setting accessibility labels to @IBOutlets, but when there  is a test team for handling UI tests we have to facilitate their job. In return we will have quick and precise bug reporting. All in all this will save you time in middle-long term.

As well as in fonts and colors, we will create a new module that will concentrate all accessibility constants:

With the following structure:

Finally for applying accessibility to @IBOutlet:


With this and previous post we consider the view layer of the architecture already presented. If you have any doubt, and you can download the source sample project from here.

What’s next

In the next post will be presented the Domain Layer and how View Layer interacts with it using UseCases (Interactors in Viper) and Coordinators.