Keep your dependencies explicit

This is a brief advice. Think about the parts of your application as they were isolated modules. And inject the dependencies explicitly.

This will be short. These are some rules that I try to respect when thinking about modularity in iOS development:

Storyboards are harmful.

Please, avoid them.

First, you can’t inject dependencies using the view controller constructors, and people tend to forget passing very important data between controllers. Of course there are workarounds, like creating a function that configures the destination view controller, but it’s just that, a workaround. You shouldn’t depend on workarounds.

Second, view controllers know a lot about the other controllers. They are strongly coupled, and can’t be replaced without a lot of struggle.

Remember Gamma, when he said: “Program against an interface, not an implementation”.

Organize your groups in modules

Stop creating a group for View Controllers, another for View Models, another for Cells, etc. I found that it’s better to have a group that is called Home, another one that is called “Posts List”, etc.

Groups thought as modules contains everything needed for a section or screen to work, and you can stop using the search bar to find files too often.

Of course there are some things that are reused across the entire application, it’s fine, those things should be in their group outside the other modules.

Inject your logic explicitly

You can write your logic in objects like View Models, Presenters, Stores, Interactors, etc. That depends entirely on the architecture you have chosen for your project, but my advice here is relying on contracts between those and your views, and injecting the logic in the controllers using init.

Contracts are Protocols. Imagine that you have your logic encapsulated in an Object, and you want to replace your logic with another, or you want to reuse your view in another side but with a different logic. If you use protocols, you can replace your implementation with another one and nothing will change. This reduces coupling a lot, producing much better code and architecture.

Don’t overengineer

My final advice is DON’T OVERENGINEER. It’s bad and you will just spend a lot of time for nothing. Modularity is great while it doesn’t reduce your productivity.