Expo Modules 2.0 previews a simpler way to connect native code

Less repeated binding code

The iOS macros already included in SDK 57 cover module declarations, JavaScript-exposed members, records, shared objects and events. Instead of separately describing each method in the old module-definition style, developers can annotate Swift code closer to where the behavior is implemented.

The main maintenance opportunity is easier-to-follow native integration code. A smaller amount of binding boilerplate can make a module simpler to inspect, but it does not remove the need to test the JavaScript contract, lifecycle behavior or platform-specific edge cases.

Sources and release notes: [1]

What is available now

Expo describes the SDK 57 implementation as experimental and undocumented, with an API that may still change. An official beta, documentation and an agent skill are planned for SDK 58.

Android implementation, native-view support and generated TypeScript declarations are still described as work in progress. That makes this a preview to evaluate, rather than evidence that a complete cross-platform replacement has already shipped. Modules 1.0 remains supported.

Sources and release notes: [1]

Try one module before planning a migration

Expo says Modules 1.0 and 2.0 can coexist within a module. That gives a team room to move one function or property at a time while keeping an existing application working.

A useful experiment would take one small iOS integration with a clear test contract. Check its values, errors, events and behavior when the app moves between lifecycle states. Keep the Android implementation and existing release process intact while assessing the new API.

• Start with a narrow module and known JavaScript behavior.
• Test the native boundary, including errors and lifecycle changes.
• Record the experimental SDK/API versions used in the evaluation.

Sources and release notes: [1]

Read the benchmark at the right scale

The announcement reports faster synchronous native calls in a specific release-build test setup. Async calls stayed close in that comparison. Those measurements describe calls across a boundary, not the speed of an entire application.

Our take is to evaluate maintainability and correctness first, then measure a real bottleneck if the app has one. Teams with stable native modules can follow the preview without turning it into an urgent rewrite.

Sources and release notes: [1]