Expo SDK 56 ships with a custom Kotlin compiler plugin that eliminates reflection from Expo Modules on Android. The result: 70% faster module initialization and a 30% reduction in time to first render.

The plugin runs during compilation, so app developers get these performance gains automatically without changing any code. Module authors can unlock even bigger wins with a single annotation.

This post walks through how we built it and why this approach succeeded where previous attempts failed. For the Swift side where we now talk to JSI directly, check out our companion post Talking to JSI in Swift.

The reflection problem we inherited

Before Expo Modules, we had Unimodules. They worked like old React Native bridge modules: you'd sprinkle annotations across methods you wanted to expose, and the runtime would discover everything through reflection.

class ClipboardModule(context: Context) : ExportedModule(context) {
  override fun getName() = "ExpoClipboard"

  @ExpoMethod
  fun getStringAsync(promise: Promise) {
    val clip = clipboardManager.primaryClip?.getItemAt(0)
    promise.resolve(clip?.text?.toString() ?: "")
  }

  @ExpoMethod
  fun setStringAsync(content: String, promise: Promise) {
    clipboardManager.setPrimaryClip(ClipData.newPlainText(null, content))
    promise.resolve(true)
  }
}

Reflection made sense when we needed metadata about our own code. What methods does this module export? What arguments do they accept? The JVM could answer those questions. But reflection costs time, and on Android that time comes straight out of your startup budget. Every module the runtime introspects adds milliseconds before users see your app.

Building the Expo Modules API gave us a chance to fix this. We wanted better ergonomics and less reflection. The Kotlin DSL delivered both in one move, removing most reflection while making modules easier to write. But we couldn't eliminate all of it. Type information for function arguments and Record properties still required runtime reflection calls like typeOf<T>() and the metadata parsing that comes with them.

Where reflection actually hurts

The remaining cost shows up in two places. First, reconstructing type parameters. Our DSL reads argument and return types through typeOf<T>(), which works because T is reified. The JVM normally erases generics at runtime, so you can't ask what T actually was. Reified type parameters work around this limitation. The compiler inlines the function and substitutes the real type directly. Getting type information this way is usually cheap, but costs add up when modules have many functions or deeply nested generics.

The second cost is heavier: Record conversion. A Record represents a typed JS object on the native side. Converting one means discovering its shape at runtime: which properties it declares, which ones are exposed to JS, and what type each property has.

This discovery process is expensive because it involves multiple layers of reflection. You ask the JVM for the class's memberProperties, then ask each property for its annotations and type, then make the field accessible for writing. Some of that information isn't even directly available in bytecode. The JVM knows about classes and members, but nothing about Kotlin's type system. The Kotlin reflection library has to reconstruct that by parsing the @Metadata annotation, which contains a binary blob the compiler generates.

We could sidestep some of this work. Top-level nullability doesn't need full reflection with a reified T, a simple null is T check answers it. But nested cases like the T in List<T> are different. The JVM erases generics, so type arguments disappear from bytecode at runtime. It has no concept of Kotlin nullability either. The only place that information survives is the @Metadata annotation, and there's no shortcut to reading it. You have to parse that metadata, which is exactly the cost we were trying to avoid.

Why we skipped code generation

The standard solution for this problem is code generation. Both Java and Kotlin have established tools for it. Annotation processors (kapt) and the Kotlin Symbol Processing API (KSP) run at build time and emit source files that pre-compute type metadata, so you never touch reflection at runtime. We also looked at standalone codegen tools that run before compilation, like React Native's TurboModule generator.

We tested this approach and didn't like what we found. Generated code becomes part of your project. It appears in call stacks, you step through it in the debugger, and when something breaks in the JS-to-native bridge, you're reading machine output that's painful to debug. Also, kapt and KSP can only add new files, never modify existing ones. Instead of augmenting a Record class in place, you'd generate a parallel class from scratch. Standalone tools just swap those problems for others: another build step, more toolchain integration, more maintenance overhead.

We were stuck for a while. We lived with the reflection cost and watched for better options.

What K2 changed

Kotlin 2.0 shipped with the new K2 compiler and changed what was possible. The add-only limitation of kapt and KSP is exactly what K2 removes. The new compiler plugin API gives you access to the intermediate representation (IR) the compiler produces. You're editing code as the compiler sees it, before it becomes bytecode. If you produce invalid code, the compiler catches it. You can write tests against the transformed IR. Unlike codegen, the result isn't a parallel layer of code you have to maintain. It's small, surgical changes in well-defined places.

We always knew we could modify bytecode directly, but we didn't want to maintain that. Too fragile, too easy to produce something that only breaks at runtime on specific Android versions. The compiler plugin API gives the same power with actual safety guarantees.

How the plugin works

The plugin's approach is simple: everything reflection discovers at runtime, the compiler already knew at build time. Built on the K2 API, the plugin targets the two most expensive operations we described:

1. Pre-computed type descriptors

When an Expo Module needs type information, it calls typeDescriptorOf<T>(). The function itself is a stub that throws if it ever runs:

fun <T> typeDescriptorOf(): PTypeDescriptor =
  throw NotImplementedError(
    "typeDescriptorOf<T>() should be replaced by the compiler plugin"
  )

It exists so code compiles, but should never execute. During compilation, the plugin intercepts every call to typeDescriptorOf<T>() and replaces it with a direct reference to a pre-computed type descriptor object:

// What you write:
typeDescriptorOf<List<Int>>()

// The equivalent of what the compiler emits:
PTypeDescriptorRegistry.getOrCreateParameterized(
  List::class.java,
  isNullable = false,
  parameters = arrayOf(
    PTypeDescriptorRegistry.getOrCreateConcrete(
      Int::class.java, 
      isNullable = false
    )
  )
)

Think of typeDescriptorOf<T>() as our own, leaner version of typeOf<T>(). Both return objects that describe types, but where typeOf returns a full KType, ours returns a PTypeDescriptor (P for Pika, the plugin's internal codename) that carries only what we actually use: a Class<?> reference, a nullability flag, and a list of parameter descriptors. No dependency on the Kotlin reflection library.

The lean shape also reduces allocation. For simple types like String or Int, the registry returns pre-allocated static fields, so there's no allocation. For parameterized generics, descriptors are cached and deduplicated across modules, so the cost is paid once. In JVM microbenchmarks, building descriptors this way runs roughly 2x faster than typeOf for complex types like Map<String, List<Int?>>.

2. Pre-computed Record metadata

The fix for reflection-heavy conversion is a single annotation. Mark a Record with @OptimizedRecord and the plugin takes over:

@OptimizedRecord
class UserRecord : Record {
  @Field val name: String = ""
  @Field val age: Int = 0
  @Field val address: AddressRecord? = null
}

That annotation is the opt-in. For any class marked with @OptimizedRecord, the plugin does at compile time exactly what SDK 55 did at startup: reads property names, types, and annotations and bakes them into bytecode as plain objects, paired with direct accessors that use simple index-based dispatch. Setting a field goes from "make it accessible via reflection, then set it" to a plain assignment.

If compiled metadata is present, the runtime takes the fast path. If not (annotation was omitted or plugin didn't run), it falls back to the same reflection-based conversion from SDK 55. Either way, your module keeps working.

Records aren't the only beneficiary. Jetpack Compose props marked with @OptimizedComposeProps get the same treatment, applied to prop resolution instead of field conversion. This matters because prop resolution was a major bottleneck for packages like expo-ui that use Android's declarative UI heavily.

Performance results

Performance gains depend on how many Expo Modules your app uses and what types they export. We measured cold starts of a module-heavy test app (all official Expo modules plus popular third-party TurboModules) on two devices: a OnePlus 9 Pro and an older Samsung Galaxy S9.

The results:

• Android module initialization: ~70% faster
• Time to first render: ~30% improvement
• Record conversion: ~6x faster

Raw cold-start numbers from our module-heavy test app (clean mean over 150 iterations, outliers removed):

What you need to do

App developers: nothing. The compiler plugin runs automatically in SDK 56. The typeDescriptorOf replacement applies to all types without code changes.

Module maintainers who use Records can opt into faster conversion with @OptimizedRecord:

@OptimizedRecord
class MyConfig : Record {
  @Field val apiUrl: String = ""
  @Field val timeout: Int = 30
}

If you use props with our Compose integration, annotate with @OptimizedComposeProps:

@OptimizedComposeProps
data class MyViewProps(
  val title: MutableState<String> = mutableStateOf(""),
  val count: MutableState<Int> = mutableIntStateOf(0)
) : ComposeProps

Skipping these annotations doesn't break anything. Modules fall back to the same reflection-based conversion from SDK 55. You just miss out on the 6x speedup for Records.

Looking ahead

This isn't the finish line. The compiler plugin currently handles type metadata and Record conversion, but the same approach can extend to other parts of the module lifecycle, like function dispatch. We're also investing in the plugin itself, making it more capable and easier to maintain, so we can expand its scope without expanding maintenance costs. The goal remains the same: keep the ergonomic APIs module authors write today while pushing more work to compile time.

This post is based on content from the Expo blog. Follow @expo for more React Native content.