Coconut Architecture: Part One - The Origin

At Bornfight, we use Coconut in most of our iOS apps – it’s our custom architecture that we developed through the years.

Compared to other popular architectures, it is relatively simple, but at the same time it’s powerful enough to be easily scaled to accommodate larger projects.

Once upon a time

Back in the spring of 2016., in the early morning, the sun was just coming up and shining through our office windows and I was just about finishing a project that I was working on for the previous several months. The project was using a standard MVC (Model-View-Controller) pattern, and I was not the first person who was working on the project so I tried to keep it consistent with the overall structure. The controllers were quite heavy, so for the next project I really wanted to try something new.

So many choices

I had some time before the new project officially kicked off, so I was looking at different architecture options that already existed.

The popular MVC alternatives from the time were:

  • VIPER
  • MVVM
  • Clean Swift

I heard a lot about VIPER before and one of our projects (Mediatoolkit) was also written in VIPER. I believe that the separation of concerns is very good, but it comes with a tradeoff that you now have a lot of classes and protocols per one screen, which often leads to a lot of boilerplate. MVVM, on the other hand, has a lot less boilerplate, but I felt it was missing something. The ViewModel itself is not enough to properly separate everything that a UIViewController normally does. Clean Swift is very similar to VIPER, which makes sense because they are both based upon the The Clean Architecture by Robert C. Martin.

For the majority of our projects, VIPER and Clean Swift just offered too much and would bring a lot of overhead. Yeah, they would work eventually and we would get used to them, but the developer experience is something really important and it should be taken into account when choosing an architecture. If developers are entangled in writing many protocols, abstractions and classes, adding a new screen in your app can sometimes feel like a chore instead of joy. So what about MVVM then? Unlike VIPER and Clean Swift, it does not bring a lot of overhead, but the ViewModel would bring in too many responsibilities, such as formatting models for presentation, acquiring the models for the API or database, etc. And that’s a little too much for my taste!

The crossroads

I had a choice to make. Either use an existing architecture or make a brand new one myself. It was definitely more exciting to create an architecture myself, but it will certainly come with a cost. Existing architectures were proven to be effective by a number of experienced developers and had many apps written with them. I, on the other hand, didn’t have that much experience at the time and was certainly going to make some mistakes and wrong calls along the way. What I noticed from other companies that make iOS apps is that even if they start using an existing architecture like MVVM or VIPER, they modify it so it suits their developer culture and business needs. So basically they end up with their own architecture, in a way.

The decision

I really like to learn new stuff. Seriously, Learner is my top talent according to the Gallup Strengths Finder. 🙂 That is why the choice became clear – I will create an architecture that suits our needs and culture from the ground up. I knew what bothered me the most in previous projects and that’s what I was going to start with. I also didn’t want to start too big and create an architecture master plan immediately. I was sure that I was going to learn the constraints of an architecture only when I start to use it in real projects, so I was going to start small and evolve it gradually.

And that’s how I started building the Coconut architecture (although it got its name much, much later). After I decided to create a brand new architecture, I said to myself I need to focus on the core, so I did.

This is what I started with:

  • Fetching data (from API, local database or basically anywhere)
  • Presenting views (formatting models, adding colors, toggling states, etc.)
  • Navigating from one screen to another

This is how it all began with the Coconut.
Read the next blog in the series to learn how Coconut evolved over the years!