expo-migrate-module

Topics in the source

• Migrate an Expo Module
• Prerequisite
• References
• Workflow
• 1. Establish the contract
• 2. Verify the available 2.0 surface
• 3. Apply the migration
• When a 2.0 equivalent is missing or a group fails

Migrate the Swift side of an existing Expo module without changing its observable JS API. Treat the current JS/TypeScript surface and tests as the compatibility contract. Leave Kotlin on the 1.0 DSL unless the user explicitly expands the task. Use expo 58.0.21 or newer. Earlier 58.0.x releases lack tuple conversion and the swift:check and swift:expand commands of expo-modules-cli. Older ones also lack lazy @JS properties, SharedRef subclasses in @SharedObject, static shared-object members, and .withAsync, and the oldest lack closure arguments and free-form Any return values. SDK 57 also lacks .concurrent, @Union, and module auto-discovery. Do not target either. Before editing, check the installed version (npm ls expo, or the lockfile). If it is older, stop and tell the user to upgrade first. Check the example app's own dependencies too, not only the module root. The example app is the integration surface you build and launch in step 4, so it needs the same floor. This is a floor, not a guarantee: the macro and core surface changed in almost every 58.0.x patch release, so step 2 must still verify the installed source. The macros are still experimental and undocumented: SDK 58 has no

This is an excerpt. Refer to the complete source and its current requirements.