Expo’s Faster JNI Layer Needs App-Level and Lifetime Tests

Summary

Expo’s November 6 engineering report describes Kolibri, the JNI layer beneath Expo Modules 2.0 on Android, replacing fbjni for that use case. It targets native-call overhead and runtime-linked resource cleanup. Expo engineering report

This is a useful follow-up to our SDK 56 Kotlin compiler analysis. That article covered moving reflection work into compilation. The next question is how a cheaper native boundary changes the performance tests and lifetime checks a module needs.

Key Updates

Less work at the boundary. A compiler plugin passes native pointers directly, avoiding repeated JNI lookups. A shared binary buffer replaces per-value JNI construction when transferring data to Kotlin; Kotlin still builds the resulting objects. Scopes release runtime-dependent resources when the JavaScript runtime is destroyed. Exception checks remain the default; opting out requires methods that truly cannot throw. Engineering details

The benchmark has a specific denominator. Expo reports 2.7 ns for a single hybrid-object call versus 76–138 ns with fbjni: roughly 28–51×. Those JNI benchmarks ran on an Apple M3 Pro with JDK 17, not an Android phone. They establish neither an application-wide multiplier nor an independently reproduced result. Kolibri also adds a library and maintenance cost while React Native still includes fbjni. Methodology and tradeoffs

Availability has moved beyond the earlier preview. The October 15 SDK 58 release notes place Expo Modules 2.0 in beta on both iOS and Android. They describe annotated native classes and bindings generated at build time. Separate Android module microbenchmarks range from 1.2× to 39.9× faster than Modules 1.0 across twelve cases. These are different workloads from the JNI hybrid-call test; the figures should not be combined or treated as a forecast for an app. SDK 58 release notes

Why It Matters

Our interpretation is that the most useful unit of evaluation is a user-visible operation: opening a screen, processing a payload or completing a native task. Faster interop matters most when interop accounts for a meaningful part of that operation. If rendering, storage or network waiting dominates, reducing a small native-call cost may barely change the result.

The lifetime question deserves equal attention. A fast success-path benchmark does not tell a team how its module behaves during reloads, interrupted work or cleanup. Treat those as separate acceptance criteria. Likewise, shared storage for transport should not become an assumption that an entire conversion allocates nothing.

Android’s Macrobenchmark guidance provides a complementary measurement level: it exercises larger interactions such as startup, UI navigation and animations from outside the app, with control over the test environment. That makes it useful alongside focused native-call measurements. Android benchmarking guidance

Builder Takeaway

Start with one frequently used native module and record its SDK, build configuration, device and payload shapes. Compare the complete user operation before and after a controlled change. Include small and large payloads, repeated calls, allocation pressure and tail latency; keep the workload and environment comparable.

Then test reload and teardown while objects or asynchronous work remain outstanding, plus exception paths and repeated recreation. Record failures and memory behavior separately from timing. These are proposed validation steps, not tests performed for this article.

Use a measured user benefit and acceptable failure behavior to justify adoption. Beta status and vendor microbenchmarks warrant a controlled evaluation; they do not establish that every application should migrate immediately.