Build native modules for Expo and React Native apps

Writing Expo Modules is a reference for building native modules and views with the Expo Modules API, using Swift for iOS, Kotlin for Android and TypeScript for the JavaScript side. It is an official Expo skill under the MIT license. It is organized into reference files for scaffolding and adding platform support, the module definition DSL (Name, Function, AsyncFunction, Property, Constant, Events, the type system and shared objects), native views (View, Prop, EventDispatcher, view lifecycle and ref-based functions), lifecycle hooks (module hooks, iOS app and AppDelegate hooks, and Android activity and application listeners), config plugins (modifying Info.plist and AndroidManifest.xml and reading values in native code) and expo-module.config.json with autolinking.

The recommended approach is to prefer create-expo-module over creating native module files by hand, because the scaffold sets up the expected layout, expo-module.config.json, podspec or Gradle files, TypeScript bindings and the standalone example app flow. If an existing module only needs another platform, use create-expo-module add-platform-support instead of copying native directories.

The workflow has five steps:

1. Choose the scaffold type: a local module for a single app, or a standalone module for reuse, monorepos or publishing.
2. Decide which features are needed from Constant, Function, AsyncFunction, Event, View, ViewEvent and SharedObject.
3. Scaffold deliberately with an explicit slug or path, an intentional --platform choice and --features to pick code samples that will be modified.
4. Replace the generated example code with the real implementation.
5. Add later platforms with add-platform-support instead of manual copying.

Scaffolding rules to remember: feature examples are opt-in, so a module with no features selected is minimal; ViewEvent implies View; local modules do not generate an index.ts barrel unless --barrel is passed; in non-interactive local scaffolding the slug or path must be passed explicitly because --name changes the native class name and not the folder name, and omitting the slug falls back to my-module; local modules live in expo.autolinking.nativeModulesDir if set, otherwise in modules/; and standalone modules have their own package metadata, scripts and usually an example app, while local modules use the host app's tooling.

Use it when creating a new Expo native module or native view, adding native functionality such as camera, sensors or system APIs to an Expo app, wrapping platform SDKs for React Native, building config plugins that modify native project files, adding Android, Apple or web support to an existing module, or editing expo-module.config.json, config plugins or lifecycle hooks.

Use it only when the task matches its upstream product scope, and verify commands, API behavior and deployment effects against current official documentation. Generated examples do not replace environment-specific tests, security review or user approval for destructive or costly actions. add-platform-support works only with modules that use the Expo Modules API DSL, not older module formats, and refuses to overwrite existing android/ or ios/ directories.

Inputs are the module name, platforms and features. A local module can be scaffolded like this:

npx create-expo-module@latest key-value-store --local --platform apple android --features Function AsyncFunction

For deterministic non-interactive output, set EXPO_NONINTERACTIVE=1 and pass the slug plus --name, --package and the other options. The CLI options include --local, --platform (apple, android or web), --features (or all), --full-example, --barrel, --source for a local template directory, --name, --package for the Android package, and, for standalone modules only, --description, author flags, --repo, --license, --module-version, --package-manager (npm, pnpm, yarn or bun), --with-readme, --with-changelog and --no-example. Omit web at scaffolding time rather than removing it later, and use View only when the module actually renders UI. Local modules skip dependency installation and do not create an example app; standalone modules install dependencies, build TypeScript and generate scripts build, clean, test, prepare, open:ios and open:android.

The Swift and Kotlin definitions share one structure. In Swift, a Module subclass returns a ModuleDefinition with Name("MyModule") and functions such as Function("hello"); in Kotlin the class extends Module and overrides definition; and in TypeScript the module is loaded with requireNativeModule("MyModule") and wrapped in exported functions.

The expo-module.config.json file sits at the package root for standalone modules or the module root for local ones. Its platforms field accepts android, apple, web and devtools (granular values such as ios, macos and tvos are allowed, but apple is preferred), apple.modules lists Swift class names (iOS uses just the class name), apple.appDelegateSubscribers lists subscriber classes and android.modules lists fully qualified Kotlin class names. Autolinking finds modules with this file and needs no manual native configuration beyond pod install, resolving in order explicit dependencies in react-native.config.js, custom searchPaths, the local nativeModulesDir (default ./modules/) and recursive npm dependencies. add-platform-support requires --platform in non-interactive mode, adds only platforms missing from the config, and tries to detect existing features, with --features as an override for unusual or generated modules. Environment variables include EXPO_BETA, EXPO_DEBUG, EXPO_NO_TELEMETRY, EXPO_NONINTERACTIVE and CI.

It works with create-expo-module, npm and other package managers, CocoaPods, Gradle, the Expo autolinking system and react-native.config.js.

It suits developers writing native iOS and Android functionality for Expo and React Native apps, including library authors publishing standalone modules.