Build native modules for Expo and React Native apps

Covers building native Expo modules and views with the Expo Modules API across Swift (iOS), Kotlin (Android), and TypeScript, anchored on scaffolding with create-expo-module rather than hand-creating native files. It draws the fundamental choice between a local module - lives inside one app, uses the host app's dependencies and tooling, no example app, no package.json of its own - and a standalone module, which has its own package.json, dependencies, and usually an example app kept by default unless the user explicitly wants --no-example, suited to reuse across apps, monorepos, or npm publishing. The module-definition DSL is identical in shape across Swift and Kotlin - Name, then feature blocks like Function, AsyncFunction, Constant, Event, View, ViewEvent which implies View, and SharedObject - all opt-in as generated example code, so a module with no features selected scaffolds minimal. Six bundled reference files cover the create-workflow, the module-definition DSL and type system, native view components (View, Prop, EventDispatcher, ref-based functions), lifecycle hooks (module, iOS AppDelegate, Android activity/application listeners), config plugins for modifying Info.plist/AndroidManifest.xml, and expo-module.config.json fields and autolinking behavior.

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

Use it when creating a new Expo native module or view, adding native functionality (camera, sensors, system APIs) to an Expo app, wrapping a platform SDK for React Native, writing a config plugin, or adding a platform to an existing module. When an existing module just needs another platform, use create-expo-module add-platform-support instead of manually copying native directories - it refuses to overwrite existing android//ios/ directories, only adds platforms not already listed in expo-module.config.json, and only works with modules already using the Expo Modules API DSL, since older module formats aren't supported; its feature-example detection from the existing module definition is best-effort and should be overridden with an explicit --features flag when the module is unusual, generated, or spread across multiple files. Several non-interactive-scaffolding quirks matter for reliability: omitting the positional slug in non-interactive local scaffolding silently falls back to the name my-module; --name renames only the native class, never the directory; and --barrel is ignored for standalone modules while, for local modules, an index.ts barrel is not generated unless explicitly requested.

Input is the target platform(s) - apple, android, web, where invalid values are dropped with a warning and, if none remain valid, the CLI falls back to all platforms - the desired feature examples, and module metadata (name, Android package, and for standalone modules also description, author, license, repo, version, and package manager). Output is a working module skeleton: for local modules, files placed in expo.autolinking.nativeModulesDir if configured or else modules/, using the host app's tooling with no dependency install and no example app; for standalone modules, a full package with its own package.json, installed dependencies, TypeScript already built during scaffolding, and, unless --no-example is passed, an example app plus build/clean/test/prepare/open:ios/open:android scripts. expo-module.config.json records the platform list and, per platform, the native module identifier - the bare class name for iOS versus the fully-qualified package-plus-class name for Android.

Built entirely on Expo's own tooling: the create-expo-module CLI, with EXPO_NONINTERACTIVE, EXPO_BETA, EXPO_DEBUG, EXPO_NO_TELEMETRY, and CI environment variables controlling its behavior, the ExpoModulesCore Swift framework and expo.modules.kotlin Android library for the shared module-definition DSL, and requireNativeModule on the TypeScript side to bridge into the native implementation.

Developers building native functionality into an Expo app or publishing a reusable native module who want the scaffold-first workflow, the local-versus-standalone decision made correctly up front, and the DSL and config quirks - barrel generation, class-name-vs-directory-name, platform defaults - handled without trial and error.