At Passenger, we are constantly evolving the software we build to meet the needs of its users (be that end-users, customers or even developers), and to be prepared for the next iterations and innovations. Building and maintaining industry-leading features means creating and maintaining a modular infrastructure that meets the demands of a rapidly growing product.

Since the launch of the Passenger Premium iOS app in 2015, we have been using a custom networking wrapper that makes requests using AFNetworking, and manually decoding HAL JSON responses from our APIs using NSObject subclasses.

Over the ~6 years that we’ve been using this structure, we’ve noticed that building new features requires a fair amount of boilerplate code. The resulting models are complex and do not lend themselves well to code review. In 2021, we decided to refactor our verbose models to use Swift’s Codable type.

Apple introduced Codable in 2017 with Swift 4, making encoding and decoding between external representations like JSON much easier. It does this by encoding and decoding Codable types automatically, drastically reducing the amount of required boilerplate code. As you’d expect, many common types from the standard library like String, Int, and Double all conform to Codable, and we use these a lot.

A welcome side effect of this work is that we have also been able to change the majority of our models from the reference type `class` to the value type `struct`. This gives our models better thread safety which helps avoid various mutation-based bugs that may be hard to diagnose. Using structs is also likely to improve performance due to how they are allocated memory, resulting in faster loading speeds for users across the board.

At the same time, we also switched our networking library to Alamofire (AFNetworking’s Swifty younger sibling) which plays very nicely with Codable types by providing a responseDecodable helper once again removing additional boilerplate code per request.

Like all the best product teams, our work is heavily user-focussed. Passenger are constantly building new and iterating existing app features to improve our user experience, so putting down feature work in order to make large structural changes is not something we do lightly.

However, to get the wheels in motion without causing a big backlog it was decided to take a ‘little and often’ approach. This is where our product’s existing modular structure truly comes into its own. The Engineering team is able to pick off one module at a time and slot the refactoring around other work, giving us the flexibility we need to keep our ship sailing.

The result is a much cleaner, more readable and robust networking layer. Building new features with Codable is a pleasure and helps to keep the team excited about new feature development, knowing that we are maintaining the highest-quality product, prioritising users needs and meeting the demands of rapid growth.

Passenger is currently recruiting for a Mobile Lead. If you’re ready to guide our Android and iOS teams in developing our industry-leading apps, we would love to hear from you.

Find out more about our open vacancies on the Join the Team page.

Keep up to date with our email newsletter