The Evolution of Facebook’s iOS App Architecture
After years of iteration, the Facebook codebase does not resemble a typical iOS codebase:
- It’s full of C++, Objective-C(++), and Swift.
- It has dozens of dynamically loaded libraries (dylibs), and so many classes that they can’t be loaded into Xcode at once.
- There is almost zero raw usage of Apple’s SDK — everything has been wrapped or replaced by an in-house abstraction.
- The app makes heavy use of code generation, spurred by Buck, our custom build system.
- Without heavy caching from our build system, engineers would have to spend an entire workday waiting for the app to build.
[…]
The dylib solution worked beautifully. FBiOS was able to curb the unbounded growth of the app’s startup time. As the years went by, most code would end up in a dylib so that startup performance stayed fast and was unaffected by the constant fluctuation of added or removed products in the app.
The addition of dylibs triggered a mental shift in the way Meta’s product engineers wrote code. With the addition of dylibs, runtime APIs like
NSClassFromString()risked runtime failures because the required class lived in unloaded dylibs. Since many of the FBiOS core abstractions were built on iterating through all the classes in memory, FBiOS had to rethink how many of its core systems worked.[…]
With the new Buck-powered plugin system. FBiOS was able to replace most runtime failures with build-time warnings by migrating bits of infra to a plugin-based architecture.
[…]
Ultimately, the FBiOS team began to advise that product-facing APIs/code should not contain C++ so that we could freely use Swift and future Swift APIs from Apple. Using plugins, FBiOS could abstract away C++ implementations so that they still powered the app but were hidden from most engineers.
I am to say the exact same thing I said to to them when they asked me about some of these choices:
They are large developer with dedicated QA and perf who releases dozens of app updates a year for a network service that can force uses to upgrade.
Which means a number of potentially labor intensive or high risk optimizations are appropriate for them because if they become an issue later they will notice them early and have the ability to undo them.
Having said that, the more elaborate these things are and the less like other apps built with the normal tools are the less likely the future optimizations we are building will improve your apps perf. We knew were doing dyld3 and page in linking years before we shipped them.
And the advice we were giving people on how to structure their apps was to set them up to work well in that future environment we were not ready to discuss.
The post gets into a bit of technical details that are fascinating, but the tone strikes me as weird. While it’s great to celebrate milestones, it seems a little odd to be happy about layers of legacy code and nonstandard, custom choices that lead to a 300MB app that does most of the same things as a web page.
Big cross-platform apps still seem like an unsolved problem. No one wants to write multiple native versions of the same app, so we either get wrappers and in-house abstractions or something like Electron. I guess Microsoft Office probably does it the best. It’s strange to think about this because intuitively it seems like Office does a lot more than the Facebook app, but (as far as I know) Microsoft hasn’t had to go to these lengths.
As Eric Vitiello commented on Mastodon regarding this post, if we assume “thousands of engineers” means just 2,000, that means a new engineer has started adding code to Facebook’s iOS app every two days, nonstop, for a decade. It’s closer to one new engineer every day if we count only weekdays.
Previously:
- Rewriting Facebook Messenger
- iOS 13 Beta
- Analysis of the Facebook iOS App Bundle
- Facebook’s Code Quality Problem
- The Facebook App’s 18,000 Classes
- Rebuilding Facebook for iOS
Update (2023-02-13): Nick Heer:
I am sure there are valid reasons for Meta to treat these applications [Facebook (blue) and Facebook Messenger] differently, but reading these posts back to back sound like they are from two completely different companies.
