Inside Facebook: iOS Development  

This is an absolutely fantastic inside look at how Facebook builds their iOS app, and the path they took from web to native. I have summarized some of the standout info, but encourage everyone who’s interested in native iOS development to watch the entire talk.

Facebook for iOS was originally created by a single developer. Later, they converted to a web app, using HTML5 and javascript in a native wrapper, a hybrid solution:

Facebook was growing really fast… [the] web was in our DNA, so we decided to use HTML5 and javascript in a native wrapper.

• they developed a bridge between native and web; significant investment
• developed a way of placing web and native components together on one view; this wasn’t easy
  • benefits to hybrid: instant products updates (no app store review), made A/B testing really simple (data guides them on feature decisions), and got them to a single codebase.
• issues with hybrid: performance problems (view load times), lack of multi-threaded strategy in web apps (couldn’t easily prevent the work on the UI thread from blocking user interactions), problems with DOM manipulation and layout (lots of hacks were required), problems with memory management (especially with immersive photos), debugging is really hard

After suffering with the issues which come with a web app in a native wrapper, they moved to a native implementation. This required a rewrite of the app:

We started Facebook for iOS as an experiment. We wanted to see, could we achieve better results with native code and could we scale the team?

• started Facebook for native as an experiment
• couldn’t just drop everything to rewrite the app, and they didn’t have a ton of iOS talent
• sequestered some engineers into a war room to enhance communication and ensure they could build quickly
• took almost a year to rewrite the app
• tweaked the API as they went to optimize for native mobile
• build features for mobile, first, and then port features to the web
• moved to a model where each and every feature team was able to add features to the mobile app; teams are divided by product, not by platform
• they ship and update every 4 weeks; under a chosen cadence. Looking at possibly going shorter. They go through a stabilization period and then a “soak” period", allowing some minor bugs to ship, but fixing more major issues.
• they build features with an on/off switch
• once a feature ships, the on/off switch and old code is removed

Facebook takes pride in moving fast, with quality. But how do they pull this off on iOS?

• make changes on local branch, put up for code review, changes automatically checked with any build and unit tests failures being reported
• they use Git; they love local branching so you can work on a number of features in parallel
• they use a Facebook-built code review tool called Phabricator
• they use ‘arc lint’ for defining rules to catch common coding mistakes; unsupported APIs and style guides
• they have Buildbot which builds the project and informs developers of issues
• internal builds; using an enterprise distribution profile so that anyone in the company can beta test
• use a different bundle identifier for each app distribution type; so you can install, and compare, app versions on a single device
• branching; master, where all the development happens. Release, where the app goes to ‘soak’
• not in their culture to have a heavy QA department
• they have a culture centered around a high quality user experience. They believe in a developer authored unit tests; test driven development (TDD). Not every Facebook engineer uses TDD. iOS does have shortcomings when it comes to TDD. They use SenTesting and OCMock which leverages the dynamic nature of the language.
• They don’t use xib files; not merge-able

Overall, I think Facebook has done a superb job of learning from their early mistakes and refocusing their entire engineering effort around building their mobile apps with user experience and quality at the center of everything. You may not love the Facebook app, but the approach taken above means that they’ll be moving quickly to respond to user feedback, and will be shipping software that is likely much more stable than it once was. A great model to follow for any mobile app team.