Week 12: Writing a Native Module (Swift & Kotlin)

1. Anatomy of a Native Module

A native module is, at its core, a small bridge: native code that exposes a function or a constant to JavaScript. Before writing one, it's worth ruling out the alternative — a JS library already exists for the vast majority of "I need X from the device" needs (as every earlier week in this phase demonstrated). Reach for a native module when the platform API genuinely has no wrapper, or you're bringing in existing native code (a company SDK, a proprietary library) that has to be exposed to the JS side somehow.

npx create-expo-module@latest --local

This generates a modules/<name> folder with matching Swift and Kotlin starter files, plus the TypeScript glue already wired up — the module below builds on that scaffold.

2. iOS: a Swift Native Module

import ExpoModulesCore
import UIKit

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

    Function("getBatteryLevel") { () -> Double in
      UIDevice.current.isBatteryMonitoringEnabled = true
      return Double(UIDevice.current.batteryLevel)
    }

    AsyncFunction("getBatteryLevelAsync") { () -> Double in
      UIDevice.current.isBatteryMonitoringEnabled = true
      return Double(UIDevice.current.batteryLevel)
    }
  }
}

Function exposes a synchronous call; AsyncFunction exposes one that returns a Promise on the JS side — for anything that might genuinely take time (a system call, disk I/O), prefer AsyncFunction so it never blocks the JS thread.

3. Android: the Same Module in Kotlin

package expo.modules.deviceinfo

import android.content.Context
import android.os.BatteryManager
import expo.modules.kotlin.modules.Module
import expo.modules.kotlin.modules.ModuleDefinition

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

    Function("getBatteryLevel") {
      val context = appContext.reactContext!!
      val batteryManager = context.getSystemService(Context.BATTERY_SERVICE) as BatteryManager
      val level = batteryManager.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY)
      level / 100.0
    }
  }
}

Same module name, same function name, same return shape — the whole point of the Expo Modules API is that the JS side never has to know which platform it's running on to call it correctly.

4. Calling It from TypeScript

import DeviceInfoModule from './src/DeviceInfoModule';

export function getBatteryLevel(): number {
  return DeviceInfoModule.getBatteryLevel();
}

import { getBatteryLevel } from '../modules/device-info';

function BatteryScreen() {
  const [level, setLevel] = useState<number | null>(null);

  useEffect(() => {
    setLevel(getBatteryLevel());
  }, []);

  return <Text>Battery: {level !== null ? Math.round(level * 100) + '%' : '...'}</Text>;
}

From this point, getBatteryLevel() is indistinguishable from a function out of any other package — it's a real requirement of a local native module, though, that a native build (not Expo Go) rebuilds it into the app; a change to the Swift or Kotlin side needs a fresh npx expo run:ios / run:android to take effect.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.