Chopping Expo up into universal modules to take over the world

Expo SDK bundled interdependent APIs, so apps could carry code they never used and contributors had to build the full runtime to make small changes. The team wanted developers to remove or replace APIs and contribute modules independently.

Chmiela uses Camera and Face Detector to explain the design. Camera depends on interfaces for permissions and face detection, so an app can provide its own implementation or omit face detection; Camera can still compile if an implementation is missing.

Chmiela describes four module types: internal modules implement interfaces, exported modules expose methods to JavaScript, singleton modules live once per native application, and view managers manage views. A Module Registry connects modules to implementations, while a provider tracks module classes and manages singleton instances.

Expo Core holds the registry and module interfaces without depending on a platform. A React Native adapter connects that core to React Native and exposes module methods to JavaScript; Chmiela says the same native modules could also serve Flutter. The approach requires several packages and manual linking, and calls pass through two proxies.

The team wanted Turtle builds to let developers exclude Expo native code already moved into universal modules and planned tools such as create-expo-library and Expo Modules. Chmiela said 19 APIs had already been extracted from Expo’s monorepo, with Lua among the additional platforms they were considering.