●TOOLING — Rork's developer repos keep moving: rork-xcode was updated on July 16, rork-device on July 15, and rork-plist on July 13●OPUS46 — Claude Opus 4.6 is live in Rork, and Rork Max is built to assemble apps on top of Claude Code●SIM — A cloud iOS simulator runs in the browser, with one click to install on a device and two clicks to publish to the App Store●MAX — Rork Max emits pure Swift rather than React Native, reaching iPhone, iPad, Apple Watch, Apple TV, Vision Pro, and even iMessage●NATIVE — That opens up HealthKit, ARKit and LiDAR, NFC, Dynamic Island, Live Activities, 3D through Metal, and on-device inference with Core ML●SEED — Rork raised a $15M seed led by Left Lane Capital, with Peak XV and a16z Speedrun joining the round●TOOLING — Rork's developer repos keep moving: rork-xcode was updated on July 16, rork-device on July 15, and rork-plist on July 13●OPUS46 — Claude Opus 4.6 is live in Rork, and Rork Max is built to assemble apps on top of Claude Code●SIM — A cloud iOS simulator runs in the browser, with one click to install on a device and two clicks to publish to the App Store●MAX — Rork Max emits pure Swift rather than React Native, reaching iPhone, iPad, Apple Watch, Apple TV, Vision Pro, and even iMessage●NATIVE — That opens up HealthKit, ARKit and LiDAR, NFC, Dynamic Island, Live Activities, 3D through Metal, and on-device inference with Core ML●SEED — Rork raised a $15M seed led by Left Lane Capital, with Peak XV and a16z Speedrun joining the round
Rork Max × Expo Modules API: Building and Distributing Custom Native Modules
Learn how to design, implement, test, and publish custom native modules using the Expo Modules API. Extend Rork Max with platform-specific features using Swift and Kotlin.
Setup and context — Why Custom Native Modules Matter
Rork Max covers a remarkable range of app development needs through AI-powered code generation and the Expo ecosystem. However, when building production-grade applications, you'll inevitably encounter situations where existing libraries fall short.
Accessing proprietary hardware sensors, building high-performance bridges to specific OS APIs, or wrapping third-party SDKs — these scenarios demand writing native code directly. The Expo Modules API provides a modern, elegant solution to this challenge.
Compared to the legacy React Native Bridge, the Expo Modules API delivers significant improvements in type safety, performance, and developer experience. This guide walks you through the entire journey — from module design to npm publication — with practical, production-ready code examples.
Who this article is for:
Developers who have shipped (or are about to ship) a Rork Max app
React Native developers ready to dive into native platform extensions
Anyone wanting to publish reusable native modules as npm packages
Expo Modules API Architecture and Design Philosophy
How It Differs from the Legacy Bridge
The traditional React Native Bridge relied on JSON serialization for JavaScript-to-native communication. While flexible, this approach had fundamental limitations.
Legacy Bridge issues:
Performance overhead from asynchronous JSON serialization
No type safety (prone to runtime errors)
Different implementation patterns required for iOS and Android
Expo Modules API solutions:
Synchronous communication via JSI (JavaScript Interface) for better performance
Type-safe design that leverages native Swift/Kotlin types directly
Unified, declarative API across both platforms
// Legacy Bridge — asynchronous communication via JSON// NativeModules.MyModule.doSomething(callback)// Expo Modules API — synchronous JSI-based callsimport { requireNativeModule } from 'expo-modules-core';const MyModule = requireNativeModule('MyModule');const result = MyModule.doSomething(); // Synchronous result
Module Lifecycle
Modules built with the Expo Modules API follow this lifecycle:
Registration: Automatic module discovery via expo-module.config.json
Definition: Module definition by extending the Module class in Swift/Kotlin
Linking: Expo's autolinking integrates the module into native projects automatically
Runtime: Direct invocation from JavaScript through JSI
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦Understand the Expo Modules API architecture and implement modules in Swift and Kotlin from scratch
✦Apply unit testing and E2E testing strategies for custom native modules
✦Master the workflow for publishing your module as an npm package for the community
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
Implementing the Native Module in Kotlin (Android)
Basic Structure
The Android implementation follows the same declarative API pattern. The nearly symmetrical code structure between Swift and Kotlin keeps the learning curve low.
// android/src/main/java/expo/modules/mynativesensor/MyNativeSensorModule.ktpackage expo.modules.mynativesensorimport android.content.Contextimport android.hardware.Sensorimport android.hardware.SensorEventimport android.hardware.SensorEventListenerimport android.hardware.SensorManagerimport expo.modules.kotlin.modules.Moduleimport expo.modules.kotlin.modules.ModuleDefinitionimport expo.modules.kotlin.Promiseclass MyNativeSensorModule : Module(), SensorEventListener { private var sensorManager: SensorManager? = null private var accelerometer: Sensor? = null private var isTracking = false override fun definition() = ModuleDefinition { // Module name (must match iOS) Name("MyNativeSensor") // Constants Constants( "isAccelerometerAvailable" to (getAccelerometer() != null), "isGyroAvailable" to (getGyroscope() != null) ) // Events Events("onSensorUpdate", "onError") // Synchronous function Function("getCurrentReading") { // On Android, real-time sensor values can't be // fetched directly — return the last cached reading lastReading ?: mapOf( "x" to 0.0, "y" to 0.0, "z" to 0.0, "timestamp" to System.currentTimeMillis().toDouble() ) } // Async function AsyncFunction("startTracking") { interval: Double, promise: Promise -> val manager = getSensorManager() val sensor = getAccelerometer() if (sensor == null) { promise.reject( "SENSOR_UNAVAILABLE", "Accelerometer is not available", null ) return@AsyncFunction } val delayMicros = (interval * 1_000_000).toInt() manager?.registerListener( this@MyNativeSensorModule, sensor, delayMicros ) isTracking = true promise.resolve(true) } // Stop function Function("stopTracking") { sensorManager?.unregisterListener(this@MyNativeSensorModule) isTracking = false true } // Cleanup OnDestroy { if (isTracking) { sensorManager?.unregisterListener( this@MyNativeSensorModule ) } } } // Cache the last sensor reading private var lastReading: Map<String, Double>? = null override fun onSensorChanged(event: SensorEvent?) { event?.let { val reading = mapOf( "x" to it.values[0].toDouble(), "y" to it.values[1].toDouble(), "z" to it.values[2].toDouble(), "timestamp" to (it.timestamp / 1_000_000.0) ) lastReading = reading sendEvent("onSensorUpdate", reading) } } override fun onAccuracyChanged(sensor: Sensor?, accuracy: Int) {} private fun getSensorManager(): SensorManager? { if (sensorManager == null) { sensorManager = appContext.reactContext ?.getSystemService(Context.SENSOR_SERVICE) as? SensorManager } return sensorManager } private fun getAccelerometer(): Sensor? { if (accelerometer == null) { accelerometer = getSensorManager() ?.getDefaultSensor(Sensor.TYPE_ACCELEROMETER) } return accelerometer } private fun getGyroscope(): Sensor? { return getSensorManager() ?.getDefaultSensor(Sensor.TYPE_GYROSCOPE) }}
Designing the TypeScript API Layer
Type Definitions
Strict TypeScript type definitions for the native module ensure type safety on the JavaScript side.
# 1. Compile TypeScriptnpm run build# 2. Dry run (verify contents without actually publishing)npm pack --dry-run# Output: lists all files that would be included# 3. Log in to npmnpm login# 4. Publish (scoped packages require --access public)npm publish --access public# Expected output:# npm notice Publishing to https://registry.npmjs.org/ with tag latest# + @your-scope/my-native-sensor@1.0.0
Versioning Best Practices
It's important to clearly communicate Expo SDK compatibility in your module's versioning:
v1.0.x — Expo SDK 52 support
v1.1.x — Expo SDK 53 support (backward compatible)
v2.0.x — Expo SDK 54 support (breaking changes)
Including a support matrix in your README makes life much easier for users.
Performance Optimization Tips
Here are techniques to get the most out of your custom native modules.
Controlling Event Frequency
For modules that fire events at high frequency (like sensor data), implement throttling to prevent JavaScript thread congestion:
// iOS: Throttle events to a minimum intervalprivate var lastEventTime: TimeInterval = 0private let minInterval: TimeInterval = 0.016 // ~60fpsprivate func throttledSendEvent(_ data: [String: Any]) { let now = CACurrentMediaTime() guard now - lastEventTime >= minInterval else { return } lastEventTime = now sendEvent("onSensorUpdate", data)}
Preventing Memory Leaks
Always implement the OnDestroy handler in your native modules to release listeners and timers. Neglecting this causes memory leaks during app background transitions.
Summary
Building custom native modules with the Expo Modules API dramatically expands what's possible with Rork Max. Thanks to the declarative API design, you can write Swift and Kotlin implementations using unified patterns, improving maintainability across platforms.
The sensor module pattern demonstrated in this guide applies to any native extension — camera controls, Bluetooth communication, OS-specific UI components, and more. Give it a try in your own projects.
Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.