Native 纯原生双端

要解决什么问题

Web 或设计稿落地到 App Store / Google Play 时，团队常卡在「两套代码库、两套 HIG/Material 约定、离线/权限/隐私表单各写一遍」——若中途引入 React Native、Flutter 或 KMP/Compose Multiplatform，又会在平台细节（Liquid Glass、Credential Manager、Privacy Manifest、Data Safety）上反复返工。

Native 技能把目标钉死在 纯原生：iOS 用 Swift 6.3 + SwiftUI，Android 用 Kotlin 2.4+ + Jetpack Compose。它承接 Port/Forge/Vision/Muse/Builder/Frame/Polyglot/Launch 等上游产物，输出可进 Radar、Gear、Launch、Guardian、Cloak、Crypt 等下游环节的移动端实现与审查材料。

如何工作

核心思路是「先蓝图、再实现、再平台适配、再质量门控」，而不是先堆 UI 再补合规：

• 输入侧：移植蓝图（每屏实现规范、一致性矩阵、架构图）、原型验证结论、移动设计方向（Liquid Glass / Material 3 Expressive）、设计令牌、共享业务逻辑与 API 契约、Figma 移动提取、翻译资源与商店合规反馈。
• 实现侧：按平台检测后再写代码；默认 离线优先（网络能力至少带 T0 缓存）；数据层可走 SwiftData / Core Data / Room；认证侧接 Credential Manager / Passkey；结构性 UI 变更前可对照 _common/ASCII_PREVIEW.md 做 ASCII 线框。
• 输出侧：移动端测试规范（XCUITest、Espresso、Maestro）、组件目录条目、CI/CD 流水线、商店提交与分阶段发布协调、带平台适配摘要的 PR、E2E 交接、Privacy Manifest / Data Safety 审查、密钥与 Passkey 证明审查，以及未翻译字符串与 xliff 导出供 TMS。

边界与注意点

• 明确不在范围内：React Native、Flutter、Kotlin Multiplatform、Compose Multiplatform 等跨平台 UI 方案。
• 默认假设：权限是 UX 时刻；Privacy Manifest / Data Safety 在蓝图阶段就要定；冷启动与类型安全（Swift 6 严格并发、Compose Strong Skipping）是硬门槛，不是事后 lint 能救回来的。
• 项目亲和：Mobile / SaaS / E-commerce 为高匹配；Dashboard、Game 为中等——若产品本质是桌面 Web 仪表盘而非移动优先，应在上游 Port/Vision 阶段就收窄范围，而不是在本技能里「顺便包一层 WebView」。