Expo Modules API custom native module in Expo Go versus development build

Question

The goal is to confirm the native-module boundary between Expo Go and a custom development build when using the Expo Modules API in Swift or Kotlin. A JavaScript import should resolve to the native module object without requiring ejection to bare React Native.

Expo Go ships a fixed set of Expo SDK native modules, and available documentation indicates that arbitrary Expo Modules API code is not loaded at runtime from the JavaScript bundle. A custom development build produced with EAS Build or locally can include the module alongside the SDK. Whether Expo Go offers any runtime fallback or proxy for an absent module remains unresolved, and exact behavior may vary by Expo SDK version and expo-modules-core release.

Module registration names must match between native code and JavaScript imports, and Expo Modules API is distinct from React Native TurboModules, so cross-layer compatibility is not automatic.

Can Expo Go resolve a custom Expo Modules API module through any runtime mechanism, or is a custom development build strictly required? If a development build is required, what confirms the boundary at build time rather than runtime?

Tasadduq Burney · Answer

Expo Go Cannot Load Custom Expo Modules API Native Modules
Confirmed behavior: Expo Go ships with a fixed set of Expo SDK native modules compiled into its binary. Custom Expo Modules API modules written in Swift or Kotlin are not loaded at runtime from the JavaScript bundle. If a JavaScript import references a native module that isn't pre-bundled in Expo Go, the import fails with a "Native module not found" error at runtime.

Why Expo Go Cannot Resolve Custom Modules

Expo Go is a pre-built client app with no mechanism to inject or compile arbitrary native code at runtime.
The Expo Modules API is distinct from React Native TurboModules and has no automatic bridging or proxy layer for absent native modules.
Module registration happens at native compile time; Expo Go contains only the modules that the Expo team explicitly includes in each SDK release.

Development Build: The Required Path
A custom development build (via npx expo run:ios, npx expo run:android, or EAS Build) compiles your native module code into the binary. This is the only supported way to make a custom Expo Modules API module available.

Verification Steps

Test in Expo Go: Run expo start, scan the QR code, and attempt to import your custom module. Expect a runtime error: Unable to resolve module [moduleName] or Native module not found.
Build a development client: Execute npx expo run:ios or npx expo run:android (or eas build --profile development). This compiles your native code into the development binary.
Confirm resolution: Once the development build is installed on your device or simulator, the same JavaScript import should resolve without error.

Key Boundary at Build Time
The boundary is enforced during the native compilation phase. When you run expo run:, the toolchain:

Collects all native modules from your project and the Expo SDK.
Compiles them into the binary using Xcode or Android Gradle.
Embeds the resulting native library in the development client.

There is no runtime discovery or dynamic loading of native code in Expo Go. The module must exist in the binary before the app starts.

Module Registration Name Must Match
Ensure the name used in your native ExpoViewController (iOS) or ExpoActivity (Android) registration exactly matches the string in your JavaScript require() or import statement. A mismatch results in a "module not found" error even in a development build.

Expo Modules API custom native module in Expo Go versus development build