Rewriting Facebook Messenger
To make the Messenger iOS app faster, smaller, and simpler, we rebuilt the architecture and rewrote the entire codebase, which is an incredibly rare undertaking and involved engineers from across the company.
Compared with the previous iOS version, this new Messenger is twice as fast to start and is one-fourth the size. We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000.
We accomplished this by using the native OS wherever possible, reusing the UI with dynamic templates powered by SQLite, using SQLite as a universal system, and building a server broker to operate as a universal gateway between Messenger and its server features.
[…]
Historically, coordinating data sharing across features required the development of custom, complex in-memory data caching and transaction subsystems. Transferring this logic between the database and the UI slowed down the app. We decided to forgo that in favor of simply using SQLite and letting it handle concurrency, caching, and transactions. Now, rather than supporting one system to update which friends are active now, another to update changes in profile pictures in your contact list, and another to retrieve the messages you receive, requests for data from the database are self-contained. All the caching, filtering, transactions, and queries are all done in SQLite. The UI merely reflects the tables in the database.
This keeps the logic simple and functional, and it limits the impact on the rest of the app. But we went even further. We developed a single integrated schema for all features. We extended SQLite with the capability of stored procedures, allowing Messenger feature developers to write portable, database-oriented business logic, and finally, we built a platform (MSYS) to orchestrate all access to the database, including queued changes, deferred or retriable tasks, and for data sync support.
Many readers focused on the app being native. That shouldn’t be a surprise. The app was fully native before the rewrite, too! So it’s a native app — and rewritten to a native app. Turns out, squeezing out the last bits of performance is about more than “being 100% native”!
Was this a rewrite from RN? No, Messenger didn’t use React Native at the time it was rewritten.
Again, this is a native app rewritten to a native app. The big change is dropping all of the xplat shared FB infrastructure code (not RN) in favour of a lean core in plain C.
[…]
But the whole point is that “native” doesn’t guarantee “fast”. The old app was native, AND it was slow. The difference is in how they solved their requirements in a creative way. For example, they don’t write “native views” like everyone else to save size — UI is driven by DB!
Facebook’s investment in React Native is as high as ever. The main app has 750+ React Native screens, and it’s used for several standalone apps. It’s not the right tradeoff for Messenger, but this ethos (e.g. lean use of C) inspires a lot of the ongoing React Native work.
Previously:
