用途：在保持可观察 JS API 不变的前提下，把现有 Expo 原生模块的 Swift 端从 Expo Modules API 1.0 定义 DSL 迁移到 2.0 宏 API（v2）；当前 JS/TypeScript 接口与测试视为兼容契约，Kotlin 默认留在 1.0 DSL，除非用户明确扩大任务范围。
前置条件：需 expo 57.0.21 或更新版本，更早的 57.x 缺少许多 2.0 特性与性能优化；改动前应检查模块及示例应用 package.json、lockfile 或 npm ls expo 中的实际版本，过旧则先要求升级。SDK 57 中宏为实验性且无文档，官方 beta 在 SDK 58，API 仍可能变化，大规模迁移前应告知用户，并优先采用增量混合模式而非整体转换。
主要能力：按模块命名、函数、属性/常量、事件、共享对象、记录逐组迁移；迁移前先盘点每个导出项，包括 JS 名称、函数元数、标签、默认值、可空性、同步/异步、错误与线程语义、事件名与载荷、记录字段、生命周期钩子与视图。参考 references/migration-map.md 的映射与语义陷阱、references/example.md 的完整前后对照、references/compatibility.md 的编译与运行时能力核查。
使用方式：先按已检出 expo-modules-core 实际支持的宏与核心钩子，把 1.0 项分类为可迁移、保留在 DSL、受阻三类；再逐语义组应用改动，保留 JS 名称、可选性与默认行为、线程行为与异步语义，不要改 Kotlin、JS 包装或 .d.ts，不要让宏生成符号出现在源码中，并保持 expo-module.config.json 中 apple.modules 列出全部模块类且类名保持 public/open。完成后运行最窄检查再到真实集成面：构建或类型检查、原生单测、JS/TS 测试、构建并启动示例应用，并比对最终导出面与清单。
限制：2.0 尚不覆盖的成员可保留在 1.0 definition() 中与 @ExpoModule 共存，或在不可增量挽救时回退并继续其他组；如需记录缺口可在获得用户确认后用 gh issue create --repo expo/expo 提交跟踪 issue。验证时仅看宏展开测试不足，宏生成代码可能看似正确却链接或运行失败；依赖或宏插件标志缺失时，应重装 JS 依赖、执行仓库的 CocoaPods 安装流程并重启 Xcode。报告不要输出宏生成或核心内部符号名，应以宏名与可观察 JS 行为描述能力。具体各成员当前是否受支持需以实际检出的核心与宏为准，本资料未逐一列出明确清单。