3.6 article rate

  • Created: Aug 11, 2022
  • 5 min read

SOLID Principles in iOS Development

SOLID Principles in iOS Development.

SOLID are principles that lead you to write great code without additional effort.

With great application comes great responsibility. It means that the code base should be flexible, expandable without much effort, and easy to test. SOLID principles are the exact things that let you support the top level of quality.

In this article, I’ll explain the meaning of each principle.

Five SOLID principles:

Single Responsibility

There should never be more than one reason for a class to change.

Single Responsibility.

In other words, every class should have only one responsibility. Each class needs to have a focused, specialized role.

This is how the Single Responsibility principle is violated. We can’t use a single class for presenting UI and Network requests. Instead of this, we should use another class for Network requests.


Software entities should be open for extension but closed for modification.


An entity can allow its behavior to be extended without modifying its source code.

For example, it should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs.
A module will be said to be closed if it is available for use by other modules. This assumes that the module has been given a well-defined, stable description (the interface in the sense of information hiding).

Hotly disputed principle as it is not clear how to use this one. Someone provides an example of using an interface type instead of a particular class type. But it is the dependency inversion principle.

Instead of it, let’s use protocols extensions. For example:

So we want to change the mine function without changing FoxMiner class realization. Let’s create two protocols: DiamondMinerProtocol and RubyMinerProtocol.

Now we will create extensions for these protocols:

Now let’s return to our FoxMiner class:

Now, if we want FoxMiner class realization, then we use FoxMiner type variable or variable without type:

If we change variable fox type to DiamondMinerProtocol type:

And RubyMinerProtocol:

Also, you can change function call without creating a new instance of the class:

That’s how this principle could be used in Swift.

Liskov Substitution

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Liskov Substitution.

Liskov substitution is based on the concept of “substitutability” — a principle in object-oriented programming stating that an object (such as a class) and a sub-object (such as a class that extends the first class) must be interchangeable without breaking the program.

This principle is often used in iOS development as we love to use BaseClasses.

For example, we have an app with a similar design on every screen. This means we can create some BaseClass that will set up all UI, and we will just inherit from that BaseClass instead of copy-pasting the same code in every ViewController.


Interface Segregation

Clients should not be forced to depend upon interfaces that they do not use.

Interface Segregation.

The Interface Segregation Principle (ISP)splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.

This is too easy — just don’t make supermassive protocols (interfaces).

Dependency Inversion

Depend upon abstractions, not concretions.

Dependency Inversion.

When following this principle, the conventional dependency relationships established from high-level policy-setting modules to low-level dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details.

I’ve already mentioned this principle in Open-Closed. This one is very useful when we are working with third-party libraries. For example, we have FirebaseAnalytics for events logging, and after some time, we decide to change it to AppDynamics. To make it less painless, we should use this principle.

But AppDynamics has an API that is different from Firebase one. So instead of changing log events everywhere, we should use abstraction:

And implementation:

Now in our app, we will send events through the adapter:

If we will move from FirebaseAnalytics to AppDynamics, it means that changes will be only in EventsServiceAdapter.


In this article, I’ve tried to describe all 5 principles of SOLID and given examples. SOLID principles are also great to use when you’re creating app architecture.

These principles should be used for simplifying your code life, not making it hell.

Optimization of Software Delivery Pipeline

Optimization of Software Delivery Pipeline

Optimization of Software Delivery...

Optimization of Software Delivery Pipeline

The development process can be compared with a construction site. While a lot of work is needed to develop databases, applications, etc., a...

Software Engineering Project Report

Software Engineering Reports: How to Write a Project...

Software Engineering Reports: How to...

Software Engineering Reports: How to Write a Project Status Report

Project reporting is important in software development. Among all the reports that we write, a software engineering report takes a special place....

Software Maintenance Costs.

8. Software Maintenance Costs

8. Software Maintenance Costs

8. Software Maintenance Costs

Having a brilliant idea for a product is only half the battle; software development is similar. When a product is technically completed, it doesn't...