Why Mixed Reality Needs Centralized Configuration
Reality Labs devices, including Meta Quest and Ray-Ban Meta smart glasses, operate on development and release cycles that can stretch far longer than typical mobile app timelines. That makes reliable configuration management and experimentation essential for consistency, safety, and developer velocity. As the mixed reality (MR) ecosystem expanded and more apps were introduced, the need for shared configuration values became pressing. Without common patterns, engineers frequently built ad hoc, app-specific configuration fetching mechanisms — particularly for cases where values had to be retrieved early during device boot-up.
The MobileConfig Approach
MobileConfig treats a configuration as a set of typed parameters — Boolean, int, double, or string — that control application behavior. A cross-platform client library and API let developers read parameters across many applications and services, while backend tools provide fine-grained control over which values a parameter receives based on client context such as region or device type.
The system supports feature flags, A/B testing, and release management. A developer can gate a new feature behind a config parameter, tie that parameter to an A/B test, and roll it out to a small user segment while monitoring performance and engagement metrics. The same parameter can act as a feature flag during development, controlling access without requiring client-side code changes.
Extending MobileConfig to the Device Platform
Meta's family of devices clearly needed a configuration system to match the speed of mobile development, and MobileConfig was the obvious fit. Its proven reliability, debugging tooling, and safe release capabilities made it preferable to building something new. The Reality Labs team centralized all configuration requests through a single Android service called MobileConfigService. This yields lightweight clients that don't handle fetching, telemetry, or backend protocols themselves. The service centralizes authentication and supports session-based configs with or without user info, enabling experimentation across multiple apps simultaneously. New apps can connect via IPC without extra authentication or custom build tooling.
In environments where the standard MobileConfig API can't be built directly — for example, with the Buck build system — libraries built on top of MobileConfig fetch configs on platforms like Windows. This approach avoids reimplementing configuration infrastructure at scale while ensuring a consistent user experience across the MR app family.
Configuration on Low-Power, Intermittently Connected Devices
The same MobileConfig libraries were never intended for microcontrollers, but the team repurposed them into thin clients, stripping dependencies to reduce memory footprint. Developers can target devices without standard Buck integration, and low-powered hardware now consumes configs over Bluetooth and Wi-Fi.
Devices like Ray-Ban Meta smart glasses rely on multiple microcontroller architectures controlling subsystems such as power and cameras. Configuration values are synced to these components using protocols like IPC and SPI. Where a microcontroller can't run the core MobileConfig library due to language constraints, the team still reuses the cache design and data structures at the heart of MobileConfig to deliver values. These implementation details are kept out of the developer workflow, so all devices share a unified configuration experience.
Because low-power devices often drop offline, they still need to run experiments and launch features independently of device releases. The design in place enables a seamless companion app experience — the companion app uses the standard MobileConfig libraries, thereby granting the low-power device access to the full suite of experimentation and configuration features.
Optimizing for Constrained Next-Generation Devices
With MR devices proven out, the focus shifted to making MobileConfig a centralized platform for next-generation hardware with even tighter resource constraints. The service is optimized to run only under specific conditions — for example, while charging or on Wi-Fi — ensuring that configuration syncs don't drain a limited battery supply. Customized IPC APIs reduce memory and CPU usage further, and newly installed apps can obtain config values dynamically from the centralized service.
In these constrained environments, the team enabled experimentation at the OS level using customized AOSP Java and Native APIs, preserving the familiar user experience of Meta's other apps. A custom tool addresses the limited screen real estate that complicates configuration authoring, boosting developer efficiency on future-gen devices.
Consolidating on a Central Platform
As Meta's infrastructure powers a wider range of devices, MobileConfig stands as the centralized platform for configuration across the lineup. The work lets product groups scale coordination that would otherwise require months of engineering effort, with joint goals centered on user needs.
