Bryn Bodayle

When constructing an app’s user interface (UI), the choice of framework is incredibly important. The right UI framework can make an app feel smooth, responsive, even delightful, while a UI framework that doesn’t match an app’s needs can make it feel sluggish and broken. This principle extends to developer experience as well; a UI framework with well-designed APIs can enable engineers to express themselves fluently, efficiently, and correctly, while one with the wrong abstractions or inconsistent APIs can make engineers’ jobs more difficult by slowing them down with unnecessary complexity.

At Airbnb, we want our mobile apps to provide a world-class user experience and a world-class developer experience. This desire led us to build our own UI framework named Epoxy in 2016. Epoxy is a declarative UI framework, which means that engineers describe what their UI should be structured like for a given screen state and the framework then figures out how to make updates to the view hierarchy to render the screen contents. Epoxy uses UIKit under the hood to render views.

The iOS UI framework landscape shifted in 2019 with the introduction of SwiftUI, a first-party declarative UI framework that accomplishes many of the same goals as Epoxy. Although SwiftUI was not a good fit for our needs during its first three years, by 2022 it offered increased stability and API availability. It was around this time that we started to consider adopting SwiftUI at Airbnb.

In this post, we share why and how we ultimately replaced Epoxy and UIKit with SwiftUI at Airbnb. We’ll detail how we integrated SwiftUI into Airbnb’s design system, explain the results of this effort, and enumerate a few challenges we’re still working through. After reading this post you’ll understand why SwiftUI has met our high bar for both user and developer experience.

Evaluating and Planning for SwiftUI

Switching to a new UI framework is not a task that should be undertaken lightly. After much investigation, we posited that SwiftUI would not regress the user experience and would improve developer experience because of the following hypotheses:

• Flexible and composable: SwiftUI would offer more powerful and flexible patterns to manage view variants and styling along with generic views and view modifiers. This should substantially reduce the number of views required to build the app, since it would be both easier to customize existing views and to compose new behavior inline at the callsite.
• Fully declarative: SwiftUI code would be simpler to reason about and change over time. There should typically be no context switching between imperative and declarative coding paradigms like we had in Epoxy, for which engineers frequently needed to “drop down” into UIKit code.
• Less code: As a result of SwiftUI being fully declarative, we believed it would take dramatically less code to build a SwiftUI view component. Generally, bug count correlates with lines of code.
• Faster iteration: Xcode previews would enable near-instant iteration cycles on SwiftUI view components and screens, as compared to 30 second or more build and run iteration cycles with UIKit.
• Idiomatic: SwiftUI would lower cognitive overhead when building UI, due to fewer custom paradigms and patterns. This would make it easier to onboard new engineers.

With these hypotheses in mind, we hatched a plan to evaluate and to adopt SwiftUI in three phases:

• Phase 1: Build leaf views, such as reusable view components, from our design system
• Phase 2: Build entire screens such as the reservation details page or the user profile page
• Phase 3: Build complete features composed from multiple screens

As of the writing of this post, we have successfully completed the first two phases of SwiftUI adoption and for Phase Three await flexible navigation APIs to be added to SwiftUI. For the component (Phase One) and screen (Phase Two) phases, we conducted a small pilot in which engineers signed up to try SwiftUI for their use cases. The pilots were used to collect feedback and improve our SwiftUI support at that phase before progressing to the next. This approach enabled us to deliver value at each stage of adoption, as opposed to adopting SwiftUI for whole features from the get-go with a large and uncertain infrastructure investment upfront.

Enabling SwiftUI

We made a number of infrastructure and education investments to set engineers up for success.