Facebook’s Release Process Behind the Move from Web-based to Native App

| by Manuel Pais Follow 9 Followers on Dec 28, 2013. Estimated reading time: 2 minutes |

Chaitanya Mishra, from Facebook, spoke at Velocity Conf London last month about the approach to scale Facebook’s Android app from a web view interface to a full-fledged native app. To achieve this transition each product team took ownership of their features on Android. A core integration team regression tests and focuses on global app optimization over individual features optimization in order for the distributed development model to work.

Because shipping new app versions (and fixes) to users depends first on an external party approval and then on the users’ initiative to upgrade, the continuous delivery model used for Facebook’s web development (the site ships twice a day) needed to be adapted to keep a fast cycle time for Android development. Immediate feedback to developers when a build breaks, dog fooding new releases (shipped internally to employees 4 weeks before shipping to the app store) and production-like monitoring (providing quick feedback to dev on functional errors and performance problems) help increase confidence in the releases before they get delivered externally. During that 4 weeks period fixing takes place in a release branch parallel to the master branch (where new features are continuously added and tested for later release).

Besides functional and performance testing (via the UI using Selendroid), other Android specific checks in the build process include app size (are changes unwittingly increasing the app size), memory usage and power consumption (down to actual battery usage). Chaitanya gave the example of a significant and hard to explain power usage increase which turned out to be due to a minor change with a polling mechanism which prevented the app from going to sleep mode.

After shipping to the outside world, app performance and error monitoring is done using Analytics Logger. Feedback data is analysed regularly using an in-house tool called Scuba. Chaitanya mentioned an example when an increasing number of DB crashes was found. Suspecting of low available space on users’ devices, the team added free space measurements only to discover it was actually the app which was consuming a lot more space than needed due to over allocation or even entire copies of database, large caches and also some unnecessary files. After the fixes the rate of DB crashes diminished considerably.

Despite the success in transitioning to a fully native app, Chaitanya conceded that the swing towards native probably went too far occasionally, in particular for less used features that could have remained purely web based. According to Chaitanya the drawback of relying on web is the need to maintain a backwards compatible web site API as much as possible. 

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you