Generated banner for Expo Module
Generated logo for Expo Module

Expo Module

ExpoOfficialPublished by Expo

  • Skill
  • Tool integration
  • Software development
  • MIT
  • Low risk

From the author

Guide for creating and writing Expo native modules and views using the Expo Modules API (Swift, Kotlin, TypeScript). Covers module definition DSL, native views, shared objects, config plugins, lifecycle hooks, autolinking, and type system. Use when building or modifying native modules for Expo. Not for migrating an existing Swift module from the definition DSL to the Expo Modules API 2.0 macros; use expo-migrate-module (from the expo-experiments plugin) for that.
— the description by Expo

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a complete reference for building native modules and views in Expo using Swift for iOS, Kotlin for Android, and TypeScript for the JavaScript interface. It covers the module definition DSL, native view components, shared objects, configuration plugins, and lifecycle hooks. It emphasizes using the scaffolding tool to ensure correct project structure, autolinking, and build configuration.

What it does

  • Provides a DSL for defining native modules and exposing functions to JavaScript
  • Guides the creation of native UI components for Expo apps
  • Explains how to write config plugins to modify native project files like Info.plist or AndroidManifest.xml
  • Details the lifecycle hooks for modules and platform-specific application delegates
  • Outlines the structure for expo-module.config.json to support autolinking
  • Offers patterns for wrapping platform-specific SDKs for use in React Native

When to use it

  • When you need to build a new native module or native view for an Expo project
  • When you need to expose native platform functionality to your JavaScript code
  • When you need to create a config plugin to automate native project modifications
  • When you are adding support for a new platform (iOS, Android, or Web) to an existing module

Advantages

  • Standardizes native module development across iOS and Android
  • Simplifies native integration with built-in autolinking support
  • Provides a consistent DSL for both Swift and Kotlin
  • Enables deep customization of native build processes via config plugins

Usage examples

“How do I create a new local Expo module with a function and an async function?”
The agent will guide you to use the create-expo-module CLI with the --local flag and specify --features Function AsyncFunction to scaffold the necessary files.
“How can I modify the AndroidManifest.xml of an Expo project using a plugin?”
The agent will provide a code example using the withAndroidManifest config plugin function to add metadata or permissions to the manifest.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/expo/expo-module/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip expo-module.zip -d .agents/skills

Documentation by Expo

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

  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.

  4. Replace generated example code with the real implementation.

  5. 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.

Submitting Feedback

If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:

npx --yes @expo/agent-cli@latest feedback --category skills --subject "expo-module" "<actionable feedback>"

Only submit when you have something specific and actionable to report. Include as much relevant context as possible. If an agent repeatedly fails at an Expo task or the user has to step in, submit a brief report of the task, expected result, and what went wrong using --category evals and the relevant Expo package or command as --subject.

Files

references/create-expo-module.md

create-expo-module

Use create-expo-module to scaffold new Expo modules and create-expo-module add-platform-support to extend existing Expo modules.

Prefer create-expo-module over manually creating module files and directories. In most cases, the right move is to generate the scaffold first and then build on top of it.

Choose the Module Type First

Local module

Use a local module when the native code only belongs to one Expo app.

  • lives inside the app

  • uses the app's dependencies and tooling

  • does not create an example app

  • respects package.json:expo.autolinking.nativeModulesDir, or falls back to modules/

Standalone module

Use a standalone module when the module should be reusable across apps, live in a monorepo package, or be published to npm.

  • has its own package.json

  • installs its own dependencies

  • builds TypeScript during scaffolding

  • usually creates an example app unless --no-example is passed

  • may initialize a Git repo if not already inside one

When creating a standalone module, default to keeping the example app. Only skip it when the user explicitly asks for --no-example or clearly does not want the example project.

Local module

Use an explicit slug or path.

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

If you need deterministic non-interactive output, pass the slug or path explicitly and then pass the rest of the options:

EXPO_NONINTERACTIVE=1 npx create-expo-module@latest key-value-store \
  --local \
  --name KeyValueStore \
  --package expo.modules.keyvaluestore \
  --platform apple android \
  --features Function AsyncFunction

Important quirk:

  • in non-interactive local scaffolding, omitting the positional slug causes the CLI to fall back to my-module

  • --name changes the native module class name, not the directory name

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

Creation Options

These are the module creation options exposed by the CLI:

OptionApplies toNotes
[path]local, standalonePositional slug or target path. Use this explicitly for stable local scaffolding in non-interactive mode.
--locallocalCreate a local module inside the current Expo project.
--platform <platforms...>local, standaloneValid values: apple, android, web.
--features <features...>local, standalonePick generated feature examples. Use all to include everything.
--full-examplelocal, standaloneEquivalent to --features all.
--barrellocalGenerate a local index.ts barrel. Ignored for standalone modules.
--source <source_dir>local, standaloneUse a local expo-module-template directory instead of downloading from npm.
--name <name>local, standaloneNative module name, for example KeyValueStore.
--description <description>standalonePackage description.
--package <package>local, standaloneAndroid package name, for example expo.modules.keyvaluestore.
--author-name <name>standalonePackage author name.
--author-email <email>standalonePackage author email.
--author-url <url>standalonePackage author profile URL.
--repo <url>standalonePackage repository URL.
--license <license>standalonePackage license identifier.
--module-version <version>standaloneInitial package version.
--package-manager <manager>standaloneOne of npm, pnpm, yarn, bun.
--with-readmestandaloneKeep README.md in the generated package.
--with-changelogstandaloneKeep CHANGELOG.md in the generated package.
--no-examplestandaloneSkip creating the example app.

Notes:

  • --description, author flags, --repo, --license, and --module-version only affect standalone modules because local modules do not have a standalone package manifest.

  • --with-readme, --with-changelog, --no-example, and --package-manager are standalone-only concerns.

  • --barrel only affects local modules.

  • --name changes the native module class name. It does not rename the local module directory.

Platforms

Valid values are:

  • apple

  • android

  • web

Behavior to remember:

  • standalone modules default to all platforms when --platform is omitted in non-interactive mode

  • local modules also default to all platforms in non-interactive mode

  • interactive local scaffolding preselects platforms from app.json:expo.platforms when available, mapping ios to apple

  • invalid platform values are ignored with a warning; if all provided values are invalid, the CLI falls back to all platforms

If you do not want web support, omit web during scaffolding instead of removing it later.

Feature Examples

Feature examples are generated starter snippets, not capability restrictions. They are small working examples of common Expo Modules API patterns.

Available values:

  • Constant

  • Function

  • AsyncFunction

  • Event

  • View

  • ViewEvent

  • SharedObject

Important behaviors:

  • no features selected means a minimal module

  • in interactive mode, feature examples start unselected

  • in non-interactive mode, no features are included unless --features or --full-example is passed

  • --full-example is equivalent to --features all

  • ViewEvent automatically includes View

Use View only when the module actually renders UI. For native-only modules, do not scaffold the view files unless you plan to use them.

Local Module Quirks

  • local modules do not generate an index.ts barrel by default

  • use --barrel only if you want a root barrel file

  • local modules skip dependency installation and do not create an example app

  • local modules do not have a local package.json; they rely on the host app

If --barrel is not used, the CLI's follow-up instructions point to direct imports from the module's src/ files.

Standalone Module Quirks

  • --package-manager is only relevant for standalone modules

  • if omitted, the CLI detects the package manager from the user agent or available package managers

  • the scaffold builds TypeScript after installing dependencies

  • the example app is created only when examples are enabled; --no-example skips it

  • --with-readme and --with-changelog opt into those files

The generated standalone scripts include build, clean, test, prepare, open:ios, and open:android.

add-platform-support

Use this subcommand when an existing Expo module needs another supported platform.

Interactive usage from the module root:

npx create-expo-module@latest add-platform-support

Explicit usage:

npx create-expo-module@latest add-platform-support --platform android

You can also pass the module path:

npx create-expo-module@latest add-platform-support ./packages/expo-key-value-store --platform web

Important behaviors:

  • supported values are apple, android, and web

  • in non-interactive mode, --platform is required

  • the command only adds platforms that are not already present in expo-module.config.json

  • it refuses to overwrite existing android/ or ios/ directories

  • for native modules, it only works with modules that use the Expo Modules API DSL

  • older module formats are not supported

Feature detection

add-platform-support tries to detect the existing module's feature examples from the native module definition. This is best effort.

Use --features to override the detected feature examples when:

  • the module is unusual

  • the module uses generated code

  • the definition is spread across multiple files

  • the generated files do not match the existing module's shape

If no features are detected or provided, the command creates a minimal scaffold for the new platform.

Environment Variables

  • EXPO_BETA: use the next template version

  • EXPO_DEBUG: enable debug logs

  • EXPO_NO_TELEMETRY: disable telemetry

  • EXPO_NONINTERACTIVE: force non-interactive mode

  • CI: same as EXPO_NONINTERACTIVE, used in CI environments

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Expo
Publisher
Expo (Official)
Source
expo/skills · plugins/expo/skills/expo-module · commit a9e5bd3
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from plugins/expo/LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Expo or Expo.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download expo-module.zip