Designing iOS architecture: Motivation

Let’s approach the topic of creating own architecture in this series of articles.

What is Architecture?

Architecture is the highest level of a system design.

System design is a way to facilitate production of code for an application.

An application is a medium needed to fulfil a (business) goal.

Can I skip it?

Even when you don’t prepare system design before making the app, you still have to think before writing any code, and this is called accidental system design, which leads to accidental architecture (AA).

It is easy to detect accidental architecture:
Q: Why our code is so ugly?
A: Historical reasons…

What will I gain?

The purpose of setting up a formal architecture rather than jump into coding stuff is to establish guidelines, constraints, and patterns according to which the code is going to grow.

Think of setting up architecture as laying a railroad for a code to move along it like a train.

Why would I restrain myself?

Guidelines, constraints, and patterns help to:

• code following the principle of least astonishment;
• understand how an existing system works;
• avoid reinventing the wheel;
• spread working ideas in the community.

Can I use one of those from the internet?

You should learn from those, but that they all suffer from many problems:

• don’t provide growth strategies;
• good fit for only one size of apps and team;
• random level of components abstraction and communication;
• vague distribution of roles (I’m looking at you “Worker”);
• unforgiving and fanatic ;)

Do I have enough skills to design it?

No one has enough, but the more you have, the easier it is to see the light at the end of a tunnel.
Here is what will help you:

• read old books and white papers about system design and patterns;
• avoid new articles trying to sell you a silver bullet;
• learn what works for others in production;
• use other platforms as a source of inspiration;
• try ideas at home, if they work, bring them to work;
• defer the decision if you are in doubt (make a dumb thing meanwhile);
• discuss ideas and implementations with others.

Where to start?

We should always start by analysing requirements (as in any mature endeavour) which come from the goal.

Functional requirements.

In the worst case you can get a high-level functional specification, like this:

• Shopping list application;
• Ability to collaborate on lists;
• Ability to use with no internet connection.

At this stage, the business might think that requirements are sufficient, and it is your responsibility to find answers to the swarm of questions which arise, for example:

• How will the UI look like?
• Which devices the app has to support?
• Do I have to make server-side as well?

When you can’t think of other questions to ask, its time to move on to the next stage.

Organisational requirements.

If it is not a greenfield project there might be plenty of restrictions on your architecture choice, at least try to answer these questions:

• Who is my team?
• What do they expect from our architecture?
• Do we have established tools and languages?
• Can we reuse an existing architecture?

Can I finally start making architecture?

Yes, you can! By putting functional and organisational requirements together, you can start outlining your ideas and then eventually compose a formal Architecture! But its an entirely different story to tell…

Can I go home now?

Before you take your ideas into the wild, I suggest you stress-test them against a comprehensive checklist I’ve compiled for your convenience.

How to use the checklist?

Take your candidate architecture and pretend to be its advocate by answering questions like on trial (imagining a jury of iOS community helps).

Thank you for reading!

Message me on Twitter for feedback.

Where to go from here?

Overview of existing iOS Architectures.
Review of the MVC pattern.