Catawiki’s iOS journey
As Europe’s most-curated marketplace for special objects, we develop and maintain native mobile apps for both Android and iOS. This blog will cover the history of our iOS app and the evolution of our tech stack.
The Early Days (2014–2016)
Once Catawiki was firmly established as an auction website around 2013–2014, we started exploring new ways to reach our customers with smartphones. Initially, an external company was contracted to work on native mobile apps for both Android and iOS, as well as the set up of a dedicated API to support this. Shortly after, we hired iOS developers to release and expand the app. At first, the app only contained bidding and buying functionality.
During this stage, the architecture of the app was pretty standard for its time: it used Objective-C and an MVC architecture. The v1 generation of our app was only available on iPhone. In late 2015, we worked on making our app available on iPad by making it universal — the iPhone and iPad screens were bundled in one app. In 2016, the v2.0 iteration was released after testing with beta testers, who were current app users and colleagues.
At the same time, another team started building a separate app specifically for Catawiki sellers to submit special objects for sale and to maintain an overview of these objects 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.
However, some pain points of the old approach became visible: having two separate apps made it harder to reuse the same code. Moreover, having separate mobile teams and a dedicated mobile backend made it harder to keep feature parity with the backend and web teams, also increasing the technical debt. It could be confusing for users, and made it difficult for our teams to scale up as part of a fast-growing company.
Key changes took place on the technical side. On the one hand, Swift was released and became a mature programming language. On the other hand, we started running into issues with the MVC pattern, such as difficulties maintaining Massive View Controllers, with lots of tight coupling, and new features that were tricky to build.
Towards a More Mature App (2017–2020)
Around 2016–2017, significant changes were set in motion for the Catawiki iOS app, its users, developers, and the code itself. After our initial experiments in 2016, we decided to develop all new features in Swift from 2017 onwards.
In 2017, we 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 the modularisation of our code incrementally into separate frameworks. This became v3.0. As a way to solve the maintenance issues associated with MVC, we began building new features in the VIPER architecture, which helped us give our code more structure, making features and screens more reusable.
Later in 2017, the development teams were reorganized 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.
During these major developments, we were still a small team of around four iOS devs, so most of the transitions we started around this time weren’t going to be completed overnight. We were also continuing to develop new features and fixes for our live app, so we had to be pragmatic in how we migrated to Swift, VIPER, Frameworks, and new APIs. When launching major features or changes for a screen, we aimed to do it all at once (yet, it often took longer).
A New Hope (& Brand) (2020-)
We were heading in the right direction, accelerating our tech evolution as part of the new Catawiki 2.0 brand. In 2020, we also expanded our iOS platform team to nine developers, which allowed us to focus on some of the oldest parts of the code and bring them up to the latest standards — an example of how important it is for us to resolve and reduce our technical debt.
In September 2020, we were able to release the new brand (v4.0), and continue to migrate the final outdated parts of the app to Swift, VIPER, and to use up-to-date Microservice APIs, while also creating more Swift Frameworks. This work was completed by the end of 2021.
Does that mean the work of iOS developers at Catawiki is “done”? Far from it! Aside from the new features and innovations coming from our Product and UX colleagues, we’re already casting one eye toward the iOS tech stack of the future. In particular, how SwiftUI will replace UIKit in our app, and whether VIPER will still be a great architecture for us going forward.
Be a part of the Catawiki journey
Want to join us on our journey to improve the Catawiki app and delight our millions of monthly visitors? Get in touch and you could be our next colleague!
Special thanks to Steve Overmars, senior iOS developer at Catawiki and co-author of this post.
