Beyond the Runtime: Engineering High-Performance WebAssembly for Universal Expo Apps

I’ve spent the better part of the last decade pushing the boundaries of what’s possible in the browser and on mobile. If there’s one thing I’ve learned, it’s that while JavaScript is incredibly versatile, it has a ceiling. When you're building a universal Expo app that needs to handle heavy-duty tasks—think real-time audio synthesis, complex cryptography, or frame-by-frame video processing—the JS bridge becomes a bottleneck you can't ignore.

Recently, I went down the rabbit hole of bringing WebAssembly (WASM) into the Expo ecosystem, not just as a web-only feature, but as a cross-platform performance engine. Here’s how I engineered a solution that bridges the gap between Rust’s raw power and Expo’s universal DX.

The "Universal" Problem

The dream of Expo is "Write once, run everywhere." But WASM is traditionally a web citizen. On the web, you have the WebAssembly global. On iOS and Android (within the Hermes or JSC engines), that global doesn't exist natively in the same way.

To achieve true performance parity, I had to move beyond simple polyfills. I needed a way to execute low-level binaries on mobile that matched the speed of browser-native WASM.

The Architecture: Rust as the Source of Truth

I chose Rust for the backend logic. Why? Because wasm-pack and the underlying memory safety make it the gold standard for high-performance modules.

My workflow looks like this:

1. Core Logic: Written in Rust.
2. Binding: Using wasm-bindgen to export functions.
3. Compilation: Targeting wasm32-unknown-unknown.

But here is where the engineering gets tricky. In an Expo environment, you can't just fetch() a .wasm file on mobile like you do on the web.

Breakthrough: The Zero-Copy Memory Bridge

The biggest performance killer in WASM-JS interop is data serialization. If you're passing large arrays back and forth as JSON or copied objects, you've already lost the performance game.

My breakthrough was implementing a shared memory buffer. By passing an ArrayBuffer from the JavaScript side into the WASM instance, the Rust code can mutate that memory directly.

// Example of the shared memory approach in the Expo layer
import { loadWasmModule } from './wasmLoader';

async function processLargeData(data: Float32Array) {
  const module = await loadWasmModule();
  
  // Accessing the WASM memory directly
  const ptr = module.alloc(data.length);
  const mem = new Float32Array(module.memory.buffer, ptr, data.length);
  
  mem.set(data);
  
  // Execute high-performance computation in Rust
  module.compute_heavy_logic(ptr, data.length);
  
  // The 'data' is updated in place or read from the same buffer
  return mem;
}

Solving for Mobile (iOS & Android)

To get this working on Expo mobile, I utilized react-native-wasm in combination with a custom Expo module. On the web side, the implementation uses the native browser API. On mobile, we use a lightweight engine that wraps the WASM binary.

The trick is to use a Unified Loader Interface. I created a wrapper that detects the platform and swaps the loading strategy:

• Web: Uses WebAssembly.instantiateStreaming.
• Mobile: Reads the .wasm file as a Base64 string (or via a local file URI) and passes it to the underlying native bridge.

Performance Results

In a recent stress test—calculating complex Mandelbrot sets in real-time—the JS implementation averaged 45ms per frame. The WASM implementation? 3.2ms.

That is the difference between an app that feels "janky" and an app that feels "native." By offloading the CPU-intensive work to WASM, the JS thread stays free to handle what it’s best at: UI updates and user interaction.

Engineering Takeaways

1. Don't over-abstract: Keep the WASM interface thin. The more you cross the boundary, the more overhead you incur.
2. Type Safety is your friend: Use ts-rs to sync your Rust structs with TypeScript interfaces. It prevents the "silent failure" hell that often plagues binary interop.
3. Bundle Size Matters: WASM binaries can get chunky. Always use wasm-opt to squeeze every last byte out of your production builds before shipping them in your Expo bundle.

The Future of Expo is Polyglot

We are moving toward a future where React Native isn't just a JavaScript framework; it's an orchestrator for multiple runtimes. Engineering with WASM in Expo has shown me that we can have our cake and eat it too: the development velocity of React with the raw execution speed of C++ or Rust.

If you're hitting performance walls, stop trying to optimize your loops in JS. It’s time to go beyond the runtime.