expo-module

Writing Expo Modules

Complete reference for building native modules and views using the Expo Modules API. Covers Swift (iOS), Kotlin (Android), and TypeScript.

When to Use

• Creating a new Expo native module or native view
• Adding native functionality (camera, sensors, system APIs) to an Expo app
• Wrapping platform SDKs for React Native consumption
• Building config plugins that modify native project files
• Adding Android, Apple, or web support to an existing Expo module
• Editing expo-module.config.json, config plugins, or lifecycle hooks

To migrate an existing Swift module from the definition DSL to the Expo Modules API 2.0 macros (@ExpoModule, @JS, @Event), use the expo-migrate-module skill (from the expo-experiments plugin) instead.

References

Consult these resources as needed:

references/
  create-expo-module.md      Scaffolding and add-platform-support workflow, defaults, and quirks
  native-module.md           Module definition DSL: Name, Function, AsyncFunction, Property, Constant, Events, type system, shared objects
  native-view.md             Native view components: View, Prop, EventDispatcher, view lifecycle, ref-based functions
  lifecycle.md               Lifecycle hooks: module, iOS app/AppDelegate, Android activity/application listeners
  config-plugin.md           Config plugins: modifying Info.plist, AndroidManifest.xml, reading values in native code
  module-config.md           expo-module.config.json fields, file placement, and autolinking behavior

Quick Start

Prefer create-expo-module over manually creating native module files and directories. In practice, the best path is usually to create the scaffold first and then build on top of it. 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 Expo module only needs another platform, use create-expo-module add-platform-support instead of manually copying native directories.

See references/create-expo-module.md before scaffolding or extending a module. It covers:

• local vs standalone modules
• --platform, --features, --barrel, --package-manager, and non-interactive mode
• expo.autolinking.nativeModulesDir
• add-platform-support behavior and quirks

Recommended Workflow

1. Choose the scaffold type first:
   • Local module for one app
   • Standalone module for reuse, monorepos, or publishing
2. Determine native expo-module features that you will need.
   • Based on the user's instructions determine which feature scaffolding will be useful.
   • Available features: Constant, Function, AsyncFunction, Event, View, ViewEvent, SharedObject
3. Scaffold deliberately:
   • pass an explicit slug or path
   • choose --platform intentionally instead of relying on defaults
   • use --features to choose code samples which you will modify in the next step to match the real implementation.

• show the exact scaffolding or add-platform-support command to the user, confirm the package source with them, and run it after the user confirms. Run it inside the intended project directory, prefer the tool version that matches the project's Expo SDK, and review the generated files and installed dependencies before building on them.

1. Replace generated example code with the real implementation.
2. If you add a new platform later, prefer add-platform-support over manual file copying.

Practical Scaffolding Rules

• Feature examples are opt-in. A newly scaffolded module may be minimal if no features were selected.
• ViewEvent implies View.
• Local modules do not generate an index.ts barrel by default. Use --barrel only if you want one.
• In non-interactive local scaffolding, pass the positional slug or path explicitly. --name changes the native class name, not the folder name.
• Local modules live in expo.autolinking.nativeModulesDir when configured, otherwise in modules/.
• Standalone modules have their own package metadata, scripts, and usually an example app. Local modules use the host app's tooling instead.

Core File Shapes

The Swift and Kotlin DSL share the same structure. Swift is usually the clearest primary example; consult the references for feature-specific details.

Module Structure Reference

The Swift and Kotlin DSL share the same structure. Both platforms are shown here for reference — in other reference files, Swift is shown as the primary language unless the Kotlin pattern meaningfully differs.

Swift (iOS):

import ExpoModulesCore

public class MyModule: Module {
  public func definition() -> ModuleDefinition {
    Name("MyModule")

    Function("hello") { (name: String) -> String in
      return "Hello \(name)!"
    }
  }
}

Kotlin (Android):

package expo.modules.mymodule

import expo.modules.kotlin.modules.Module
import expo.modules.kotlin.modules.ModuleDefinition

class MyModule : Module() {
  override fun definition() = ModuleDefinition {
    Name("MyModule")

    Function("hello") { name: String ->
      "Hello $name!"
    }
  }
}

TypeScript:

import { requireNativeModule } from "expo";

const MyModule = requireNativeModule("MyModule");

export function hello(name: string): string {
  return MyModule.hello(name);
}

expo-module.config.json

{
  "platforms": ["android", "apple"],
  "apple": {
    "modules": ["MyModule"]
  },
  "android": {
    "modules": ["expo.modules.mymodule.MyModule"]
  }
}

Note: iOS uses just the class name; Android uses the fully-qualified class name (package + class). See references/module-config.md for all fields.