Facebook has been at work to rewrite its iOS Messenger app using native technologies. Soon to be available on the App Store, the new Messenger is twice as fast on launch and less than one-fourth in size, says Facebook. Its unified architecture outlines a new SQLite-centered approach to native app development.
Counter to a number of other organizations that chose Facebook own React Native as the technology to go to build their mobile apps, Facebook rewrite of Messenger put OS-native features center and front.
While UI frameworks can be powerful and increase developer productivity, they require constant upkeep and maintenance to keep up with the ever-changing mobile OS landscape. Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs. This reduced not only size, by avoiding the need to cache/load large custom-built frameworks, but also complexity.
An exception to this rule is admitted in case the OS does not support some kind of feature satisfactorily. In this case, Facebook engineers wrote the smallest possible library to deliver that functionality. For code meant to run cross-platform, e.g., business logic, they resorted to using C.
Another key factor in Facebook approach was creating dynamic UI views based on a template stored in SQLite. So, instead of storing multiple variations of, e.g., a contact list, in the app, the appropriate contact list for a given context is built dynamically by composing sub-views corresponding to the features that are required in that specific context, such as group creation, user search, sharing, and so on.
This brings us to SQLite and its central role in Facebook Messenger architecture. Instead of using SQLite only as a convenience for persisting data, Facebook engineers decided to make the app UI directly reflect the database content and rely on SQLite to transparently handle concurrency, caching, and transactions without re-implementing those features for each view.
This led to the definition of a single integrated schema used to describe all UI features, to extending SQLite so it supports stored procedures, and to create a library (MSYS) to orchestrate access to the database and provide data sync.
With MSYS, we have a global view. We’re able to prioritize workloads. Say the task to load your message list should be a higher priority than the task to update whether somebody read a message in a thread from a few days ago; we can move the priority task up in the queue.
A final tenet of Facebook approach to creating Messenger is streamlining server infrastructure as a way to further simplify the client side. In particular, instead of having each client feature talk to its related server-side feature, Messenger uses a server broker which is what the client talks to in a single, unified way.
The server broker acts as a universal gateway between Messenger and all server features, whereas in the past all client features directly communicated with their server counterparts, using a variety of approaches.
Now that Messenger has shrunk its code base by 84%, the challenge for Facebook engineers is adding new features and fixing bugs without incurring major costs. To this aim, each change will be evaluated also in terms of the additional binary weight it brings to the app.
At the moment of this writing it is not clear yet whether Facebook will open source its SQLite extension or its MSYS library. InfoQ will amend this post once this information become available.