[EN] S.I.A: Architecture
Simple Intuitive Architecture
[Update in progress] : The article is being updated in the meantime, find the news in video https://youtu.be/eaZO3tD8xeo
— — —
Translated by : Jonathan NGUYEN — Senior iOS Developer — Freelance
https://www.linkedin.com/in/proutto-jonathan-nguyen/
[FR] — https://jbarbier.medium.com/s-i-a-architecture-463ddb3e988f
# Introduction.
This architecture that i’m about to present you has been mainly designed to respond three issues
- Allow senior developers to act freely, and not being limited by the architecture
- Presenting a simplified clean architecture for new developers
- To allow a developer who does not know the project to quickly find what he is looking for.
These problems were defined via my personal experience and therefore problems that I could meet, but especially via discussions that I could have during interviews with other developers on their experiences with the use of VIPER, MVVM, MVC …
Technical stack: Swift + SwiftUI.
# Architecture structure
The architecture is composed of 4 main folders (Tools / App / Ressource / Data).
I’ll introduce them one by one and i’ll show you a proper example, from the designer template to the code implementation using the SIA architecture
## Tools
Let’s start with the common toolbox (aka Tools).
All extensions classes, protocols and common things should be in there.
To keep a clean tools folder, there is some advices:
- When creating your tool, if you decide to use it on another projets in order to be reusable, you should export it as a library (using cocoapods or spm)
- Don’t create a “Tools” file extension but only extension from existing classes (ex: UIViewController+yourFunction)
## Apps
The app folder contains what we call “user screens”, for instance:
- The home screen
- The account screen
- Login screen
- …
A screen is build from components, components that are created in our “Data” folder
To avoid a naming conflict, a screen must follow the following naming: “App + your screen name”
It must be created inside the “App” class in order to precise the right perimeter.
App referring to “@main” in our sample below:
## Ressource
The resource folder remains classic as in many architectures. In this one we will find our colors, our images etc.
An article is being written to explain how to integrate a DesignSytem in a quick and easy way in an iOS application, so think of following me to receive the notification 🎉 #ad, little teasing
## Data
This folder regroup all your models and how you want to display them
Let’s take a look:
To handle this, we have created a “Todo” folder into the Data folder.
Inside this one, we have created a Model folder, which contains our raw model.
⚠️ Warning: Make sure you have split your model separately (for instance, if your Todo model contains a “User” property, then User should be in its own folder: Data/User/Model/User.swift ).
By doing this, each model has its own ways of being displayed.
For our example, let’s presume that we have two display formats:
- As a list — TodoList.swift
- As a row — TodoRow.swift
These two display methods (the Row and List class) extend from “Todo”
Important:
The “Data” folder has for sole purpose the management of the data and its different display formats.
For example, the component “Todo.List” should not make an API call to retrieve the list of todos, it is not its role, it receives an array of “Todo” as input and displays it as a List only.
# Divide and conquer.
As we have seen, the architecture is based on an intelligent use of scopes, which allows us to structure the different parts of the code in a simple and intuitive way, in order to respect our initial problems.
So we will see how to convert a design.
To begin, we have a landing page with a todo list
In the Data part, we have the Todo model, which can display a list populated by rows.
For the API part, like we explained earlier there is a component that’ll have this purpose so multiple views can call this component.
About the App part, we have our view “Home” and its role is:
- to fetch todos from our API component
- to display the view title
- to display todos data in the Todo.List() component
# Test it yourself
Before I summarize SIA and share my feedback with you, let’s test ourselves with this information:
A product owner asks you to modify the preview of a game, he wants to add a shadow on the image and put the text on top of it. Do you think you can locate the folder containing the file to modify?
If the answer is yes, we have solved one of our initial problems:
Allow a developer who is not familiar with the project to quickly find what he is looking for.
# Retour d’expérience
SIA has been in place at Prisma Media for almost 2 years, the architecture has been progressively integrated on top of an existing architecture via the addition of the “Tools”, “App”, “Resource” and “Data” folders without much difficulty. Then we took advantage of each evolution/redesign of parts of the application to migrate the files into their corresponding folders
The architecture underwent some modifications at the beginning, but after the first months of implementation and adjustment, the architecture has met our needs and expectations. The project is structured, readable, and easy to understand, the use of SIA does not increase the time of realization of a ticket, there is no need to create 50 folders / files upstream. The reuse of components is simple and fast thanks to auto-completion (Todo.List(), User.Row()..)
SIA is meant to be agile, the architecture can adapt to your needs, there are no hard and fast rules, keep in mind to correctly scope your games and the auto-completion will greatly simplify your task.
# Conclusion
In conclusion, using SIA has allowed us to have a simple and clear architecture of use with the advantages of the clean archi without the heaviness that these can generate.
New developers can quickly find their way in the project without the need for a lot of support.
SIA can be used to structure an application as well as a pod, which allows us to keep consistency in our projects.
THANK YOU !
Feel free to give me your feedback in the comments, hoping that SIA will meet your expectations.
Example project : https://github.com/joey-barbier/SIA
Portfolio / Contact me : https://www.joeybarbier.com/
PS: A part 2 will complete the use of SIA, with the goal to detail the transition from a simple application (as in our example) that would grow to a large application with different distinct parts.
For example, an application containing only articles is added a video part, then a podcast part. SIA allows us to manage this case very easily, even with complexities such as, for example, two “User” models differing between the article part and the podcast part.
