Expo Modules: one API, two platforms
Prerequisites: 02-jsi-versus-bridge
Expo Modules: one API, two platforms — mechanism
Mental model verified
Expo Modules API abstracts JSI and related RN primitives. A module definition names the JS-visible surface. Function executes synchronously on the JS runtime thread; AsyncFunction returns a Promise and by default dispatches native work away from that thread.
[S06] [S07]Worked example synthesis
A biometric SDK wrapper could expose isAvailable as a small cached query and authenticateAsync as an asynchronous operation. Swift and Kotlin implement the same JS-facing intent while each platform handles its own permission and result behavior.
[S07]Engineering choice synthesis
Prefer the Expo DSL for a Swift/Kotlin integration when its API fits. Use a TurboModule when the module needs direct C++ access or RN Codegen contracts. Profile before attributing bottlenecks to either framework.
[S05] [S06]Pitfall and next step verified
AsyncFunction does not mean “runs on the UI thread.” Explicitly choose the main queue for UI work; view-bound async methods have their own main-thread behavior. Define failure and cancellation semantics.
[S07]Check yourself: When should an Expo module use AsyncFunction instead of Function?
For I/O, long work, or work that must be dispatched to another queue; a synchronous Function runs on the JS caller thread.