MobileConfig enables developers to centrally manage a mobile app’s configuration parameters in our data centers. Once a parameter value is changed on our central server, billions of app devices automatically fetch and apply the new value without app updates. These remotely managed configuration parameters serve various purposes such as A/B testing, feature rollout, and app personalization. MobileConfig has been in production since 2015 and serves some of the world’s most widely used apps, including Facebook, Instagram, and Messenger.
In this blog, we describe how MobileConfig enables rapid innovation on the Meta Quest and Ray-Ban Meta smart glasses.
Configuration challenges in mixed reality
Reality Labs devices can have extended development and release cycles; thus, reliable configuration and experimentation are vital for consistency, developer velocity, safety, and overall reliability.
As the mixed reality (MR) ecosystem has grown, we have introduced many more apps. These apps often need to share configuration values. With a lack of common patterns for config usage, there are anti-patterns where engineers reinvent the wheel or build ad hoc ways of fetching configuration that are very specific for each app. We also saw usage patterns when apps and services needed to retrieve values early during boot-up that made these problems more complex. These challenges made configuration and experimentation in MR much more challenging.
Enter MobileConfig
In MobileConfig, a configuration (config for short) is defined as a set of parameters with a specific data type and can control different aspects of an application’s behavior. Developers decided on the data type (Boolean, int, double, string) for the parameter to use when creating it. MobileConfig offers a cross-platform client library and API that allows developers to easily read each config parameter in our many different applications and services. It also provides a complete set of backend tools, allowing developers to precisely control which values a given parameter receives based on client context like region or device type.
MobileConfig has several use cases, including feature flags, A/B testing, and release management. A developer can use MobileConfig to control the release of a new feature separately from the application release by placing it behind a config parameter. The config parameter can be tied to an A/B test and enabled for a small segment of users while monitoring critical application metrics such as performance or engagement.
Alternatively, the parameter can be used as a feature flag, allowing developers to control who has access to the feature while it’s under development. Once the feature is behind MobileConfig, the developer can make all these changes without touching client-side code.
Our blog on “Mobile Configuration at Meta” discusses more on how MobileConfig is implemented and the design decisions behind the technology.
Expanding MobileConfig as a platform in MR
Given our experience with mobile app development, it was clear that Meta’s family of devices would also need a configuration system to move fast, enable experimentation, and remotely control various aspects of the systems. We decided that MobileConfig would be the best solution to fit the needs of these platforms because of its proven reliability and performance, existing suite of tools for troubleshooting and debugging, and its ability to release changes safely.
We centralized all configuration requests through a single Android service (MobileConfigService), resulting in lightweight clients that do not need to fetch configs, report telemetry, or understand backend protocols. We also centralized service authentication, enabling apps on the device to leverage session-based configs with or without user info. Here, with device-level consistency, the service was able to allow for experimentation in multiple apps and services at the same time, streamlining the onboarding process for new apps and allowing them to communicate with the leading service via IPC without needing to provide additional authentication or build-tooling (for configuration).
Additionally, we have built libraries on top of MobileConfig in platforms like Windows to allow fetching configs where the MobileConfig API cannot be built as-is (aka using buck). Overall, we avoided reinventing the wheel at a large scale and had a consistent user experience on MR, as our family of apps provided a vehicle for a net increase in developer velocity with a much lower learning curve.
Expanding MobileConfig to Meta’s family of devices
The novel reuse of the MobileConfig service has enabled us to optimize our development process and improve the functionality of other low-powered devices. We never intended to use MobileConfig libraries on microcontrollers. However, we repurposed them into thin client(s) and removed dependencies to lower the overall memory footprint. Additionally, we optimized the developer authoring flow, allowing developers to target devices without standard buck integration. Work here allows our low-powered devices to communicate and consume configs over Bluetooth and Wi-Fi.
Many of these devices, such as the Ray-Ban Meta smart glasses, have multiple microcontroller architectures controlling the various aspects of the product, including power, cameras, etc. In these cases, we use several technologies and protocols, such as IPC and SPI, to sync configuration values to the various components. In cases where the specific hardware could not run the core MobileConfig library due to language limitations, we could still reuse our highly efficient cache design and data structures to deliver configuration values. We abstracted these details from the developer experience, allowing for a unified configuration workflow.
Now, devices, specifically low-power devices, are not always connected to the internet, and they still need to run experiments and launch features independently of device releases. Our design choices helped us create a seamless companion app experience that uses the same mobile configuration libraries as our other family of apps, enabling these low-power devices for the same suite of features. This newfound flexibility speeds up our development process and time to market significantly, allowing us to deliver cutting-edge technology to our customers more quickly and efficiently.
Enabling future devices with limited connectivity and scarce resources
After our success with MR devices, we consolidated efforts to leverage MobileConfig as a centralized platform. Our goal is to enable the next generation of devices with the same suite of features and capabilities. These new-generation devices possess different challenges and MobileConfig needs to be highly performant and optimized for consuming compute resources on the device.
We optimized our service to run under specific conditions only (e.g., while charging or with Wi-Fi). Even with the configuration syncs to the server, our libs ensure we don’t drain the battery since it’s in minimal supply (much different than our family of apps). We also created customized IPC APIs to reduce memory and CPU usage. Work here enables dynamic configuration sets on newly installed apps to get config values from a centralized MobileConfig service.
While being in such a constrained environment, we successfully enabled experimentation at the OS level with customized AOSP Java and Native APIs while keeping the same user experience as our other family of apps using Meta’s tools. We’ve also developed a customized tool that allows developers to quickly and efficiently use configuration with limited screen real estate, further unlocking developer efficiency. Advancements in future-gen devices have enabled us to provide a best-in-class service that sets us apart from our competitors and offers significant business value.
A leap into the future
Meta’s infrastructure is empowering a new generation of devices, helping developers move swiftly. As we build more devices and applications, we will leverage MobileConfig as a centralized platform, given its capabilities and success with our existing lineup.
Efforts here allow our product groups to scale at rates that would otherwise take months and massive engineering efforts to coordinate. We drive with joint goals across organizations that put our user’s needs at the forefront.
