The iOS journey

Co-authored by Steve Overmars

Catawiki is more than a great website, we also develop and maintain native mobile apps for both Android and iOS. This post will cover the history of our iOS app and evolution of our technological stack.

The Early Days (2014-2016)

When Catawiki was up-and-running as an auction website, around 2013-2014, we started looking into new ways of reaching our customers and seeing opportunities in the world of smartphones. An external company was attracted to start work on native mobile apps for both Android and iOS and a dedicated API was set up to support this.Eventually the first internal iOS developers were hired to release and expand the app. Initially, this app only contained bidding and buying functionality.

At that stage, the architecture of the app was pretty standard for its time: using Objective-C and an MVC architecture.The v1 generation of our app was only available on iPhone. In late 2015, we started working to make our app available on iPad, by making it universal. This means that we bundled iPhone and iPad screens in one app. It was released as our v2.0 in 2016, after testing this with external beta testers, for the first time. These testers were current app users and colleagues.

In 2016, another team started building a separate app for Catawiki Sellers to submit lots for sale and to maintain an overview of these lots throughout the auction and sales process. With this change, we also slowly started introducing our first frameworks to be able to share code across the two apps.

During this time, some pain points of the old approach became visible: having two separate apps made it harder to reuse the same code, having separate mobile teams and a dedicated mobile backend made it harder to keep feature parity with the backend and web teams, and increased the technical debt. It was also confusing for users and hard to scale up the teams in a growing company.

On a technical level, Swift was released and became a mature programming language and we started running into the issues with the MVC pattern: plenty of hard-to-maintain Massive View Controllers, lots of tight coupling which made maintenance difficult and new features that were hard to make.

Towards a More Mature App (2017-2020)

Around 2016-2017, a lot of big changes were about to happen to the Catawiki iOS app, both for users, for developers and for the code itself. After our first experiments with it in 2016, we decided to develop all new features in Swift from 2017 onwards.

In 2017, we also integrated our seller app into our buyer app. We did this by extracting the seller code into an SDK, a separate Swift Framework, marking the start of modularisation of our code incrementally into separate frameworks. This became v3.0.

To also start solving the maintenance issues involved with MVC, we started building new features in the VIPER architecture. This has helped us a lot in giving our code more structure, making features and screens more reusable.

Later in 2017, the development teams were reorganised and the mobile developers were integrated into full-stack feature teams. This helped us focus on getting rid of all the discrepancies between the mobile apps and web, including a push to use the same APIs for all three platforms.

The combinations of all these changes, while still having a small team of around four iOS devs, meant that most of the transitions we started around this time weren’t completed overnight. Because there was also ongoing development for new features and fixes for our live app, we had to be very pragmatic in migrating to Swift, VIPER, Frameworks, and new APIs. We tried to do it all at once when a certain screen was scheduled for big features or changes, but in general the process required longer.

A New Hope (& Brand) (2020-)

We were heading in a good direction. We accelerated our evolution when we started work on the Catawiki 2.0 branding. Simultaneously, we grew our iOS platform team to nine developers. Because of this, we were able to focus on some of our oldest parts of the code, and bring them up to the latest standards. This is a good example of how we take managing our technical debt seriously. In September 2020, we were able to release the new brand (v4.0), and are continuing to migrate the last old parts of the app to make them Swift, VIPER and use up-to-date Microservice APIs, while also creating more Swift Frameworks. We expect this effort to be finally finished by the end of 2021.

Will that mean iOS developers at Catawiki will be “done”? Besides our product and UX people coming up with ever new and improved features, we’re already looking towards the iOS tech stack of the future, like how SwiftUI could (or rather, will) replace UIKit in our app, and whether VIPER will still be a good architecture for us in that case.

If you’d like to join us on our journey of continuously improving our apps and delighting our customers, give us a shout!

Cover photo by Ernesto Velázquez on Unsplash.