Behind the Scenes: Building Airbnb’s First Native Tablet App

By Brandon T Withrow

At Airbnb, we’re trying to create a world where people can connect with each other and belong anywhere. Whether you’re traveling, planning a trip with friends, or lying on your couch window-shopping your next adventure, you’re most likely using a mobile device to do your connecting, booking, or dreaming on Airbnb. Our tablet users have probably been surprised to learn that thus far, we have never had a native tablet app. Last summer, a small team decided to change that. We started exploring what Airbnb could become on tablet, and today, we’re excited to share it with the world. It’s a challenging feat to build an entirely new platform while simultaneously maintaining and shipping an ever-evolving phone app; and we’ll tell you more about what went right, what went wrong, and how we ultimately made it happen.

The first little steps are pivotal

After the successful launch of our Brand Evolution last summer, we formed a small team to start laying the groundwork for tablet. In building the tablet app, we took many of the technical learnings from the rebrand. For instance, much like the rebrand, we wanted to build the app over the course of several releases and eventually release the official tablet app. A small team of designers and three engineers (two iOS, one Android) formed to start building the foundation of the app and exploring the tablet space. We knew we couldn’t rewrite the entire phone app, and that if we ever wanted to ship, we’d have to reuse some of the views already existing on the phone. We reviewed every screen of the phone and every feature to determine the engineering to design cost of rebuilding each screen. One thing we quickly realized was that our top-level navigation system, “AirNav,” wouldn’t translate well to the tablet space. Instead, we’d have to design and build something new.

Airbnb goes tab bar

At Airbnb, we strive to have a seamless experience across platforms and to maintain feature parity no matter the device or form factor. This meant that whatever navigation system we chose for tablet would also have to work on phone. In order to quickly find a solution while covering as much ground as possible, the team split up to prototype as many navigation systems as we could. One of our designers, Kyle Pickering, even went as far as teaching himself Swift so he could build functional prototypes. At the end of the week we had several prototypes in all different forms, fully functional (albeit hacky) prototypes built from our live code, functional prototypes built in Swift with baked data, and even some keynote and after-effects prototypes. We took these to our user research team to quickly get some real-world user feedback on the designs. A big part of the culture at Airbnb is to move quickly and run experiments along the way, rather than waiting until the end. With a pending phone release on the horizon, we decided to build and ship the Tab Nav on phone, wrapped behind an experiment we could roll out and test on. Since the majority of the mobile team was still hard at work on building new features, we had to build the new nav quickly and quietly, in a way that would allow the rest of the team to turn it on or off at runtime without restarting the app. We launched the new nav in November 2014, which gave us several months to collect data and iterate on the high-level information architecture while we built out the tablet app.

Fun fact: Up until the launch of tablet, both navigation systems were still active and could be turned on or off via experiment flag.

Dipping our toes in MVVM (kind of)

On iOS, MVC is the name of the game. We knew we were shipping a universal binary; we weren’t going to split targets or release two apps. In terms of code architecture, we worried that shipping a universal app would cause a split in our app that would become unwieldy over time. It wouldn’t take long for the codebase to become littered with split logic, copy-and-pasted code for experiments, and duplicate tracking calls. At the same time, we didn’t want to have massive view controller classes that split functionality between platforms. This required us to rethink the MVC pattern that was previously tried and true. What we realized was that almost every model object in our data layer (Listings, Users, Wish Lists, etc.) have three UI representations: a table view cell, a collection view cell, and a view controller.

Each of these representations would differ from tablet to phone, so instead of having branching logic in place everywhere these objects were used, we decided to ask the model how it preferred to be displayed. We built a view-model protocol that allows us to ask any model object for its “default representation view controller.” The model returns a fully allocated device-specific view controller to be displayed. At first, these view-model objects simply returned the phone view controller, but when we eventually started building the tablet version we simply had to change a single line of code for the tablet view controllers to be displayed app-wide. This reduced the amount of refactoring we had to do once we started building out view controllers and allowed us to focus on polishing the view controllers. Also, this kept all of our code splitting check centralized to a few classes. Next we started moving through the existing phone controllers and pulling all of our tracking and experiment logic into shared logic controllers that would be used for both the phone and tablet views. This allowed the team to continue working on the phone, by adding experiments and features that would automatically find their way onto the tablet app.

Kicking a soccer ball uphill

By January 2015, the tablet team was all-hands-on-deck, and design was in a stage where we could start building the tablet app. We had around two months to build out the app and about a month for final polish and bug fixes. Design had produced several fully working demo apps to prototype interactions and UI animations. In producing these code-driven demos, the design team was able to identify gotchas in the design long before engineering was ramped up, which made for an overall smooth development period. There were, however, a few issues that inevitably popped up. For several scrolling pages throughout the app, design called for a lightweight scroll snapping. The idea was to have scroll views always decelerate to perfectly frame the content. This is not a new or revolutionary idea, but on a large-scale tablet device we discovered that, more often than not, this interaction annoyed the user. One user described it as being like “trying to kick a soccer ball up a hill.” Though the final results were visually pleasing, taking control from the user undermined the beauty of the design. Instead of cutting the feature completely, we decided to take a deeper look at the problem. Previously, we were using delegate callbacks which were fired when the user finished scrolling, and then adjusting the target content offset to the closest pre-computed snapping offset. We realized the problem with this system is that it doesn’t take into account the intent of the user. If a user scrolls a view and slides their finger off the screen in a tossing manner, the system works great. If a user purposefully stops scrolling and then releases touch the scroll view snaps to the nearest point, creating the “uphill soccer ball” effect. We decided to disable scroll snapping on the fly once the velocity of the scroll dropped below a certain point, giving the user control of the scrolling experience. Achieving these small wins and being truly thoughtful around user intent helped elevate the app experience to a whole new level of delight and usability.

Always be prepared

As we crossed the finish line and landed the project (mostly) on time, we took a little time to reflect what worked to complete such a massive project. We were reminded of the old Boy Scout mantra: “Always Be Prepared.” Even though the entire team built the tablet app in just a few short months, it wouldn’t have been possible without the foundation work that was silently laid throughout the year before. From designers learning to code and building prototypes, to shipping the tablet navigation system on phone months ahead of release, this prep work ensured that when it came time to officially move towards our goal, we were ready.

Check out all of our open source projects over at and follow us on Twitter: @AirbnbEng + @AirbnbData

Originally published at on April 29, 2015.



Creative engineers and data scientists building a world where you can belong anywhere.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store