【学习笔记】Skip：一份 Swift 代码产出双平台原生应用——skip.dev 深度调研与同类框架横评
这两天把 skip.dev 的文档、架构说明、发布日志和社区讨论系统性翻了一遍。起因是注意到两件事撞在一起：2026 年 3 月 Swift 6.3 正式发布了首个官方 Swift SDK for Android（Swift 语言首次官方支持 Android 开发），而同一时期 Flutter 团队因为设计体系解耦、暂停跟进苹果新设计引发了一轮「跨平台框架还能不能跟上原生」的讨论。在这两条线的交叉点上，Skip 是最值得看清的样本——它恰好是「Swift 官方 Android 化」最直接的受益者，也是目前跨平台方案里对「原生」二字最较真的一个。
一句话总结：Skip 让你用 Xcode 写一份 Swift/SwiftUI 代码，iOS 侧产出真正的 SwiftUI（甚至可以做到零 Skip 痕迹），Android 侧产出真正的 Jetpack Compose——Lite 模式靠「Swift→Kotlin 转译」，Fuse 模式靠「Swift 原生编译 + JNI 桥接」。它不是运行时方案，没有自绘引擎、没有 JS 桥、没有垃圾回收器。技术上站上了 Swift 6.3 官方 Android SDK 的东风，但两人团队、订阅转赞助的商业模式和稀缺的生产案例，是它和 Flutter/RN/KMP 之间真实的距离。
先交代调研边界：Skip 的完整开发流程要求 macOS 15+ 与 Xcode 16.4+，我在 Windows 机器上无法实际跑通构建，本文全部内容基于官方文档、官方博客、GitHub 仓库、Swift 官方公告与 Hacker News 一手讨论整理，关键数字均标注来源口径，未实测的部分会明确说明。
一、先排雷：三个「Skip」，别搞混了
动手调研前先纠正一个我自己都差点踩的坑——中文技术圈里至少有三个活跃的「Skip」：
| 名字 | 地址 | 是什么 |
|---|---|---|
| Skip（本文主角） | skip.dev / github.com/skiptools | Swift/SwiftUI 跨平台框架：一份代码产出 iOS + Android 双原生应用 |
| SkipLabs Skip | github.com/SkipLabs/skip | 响应式后端服务框架，「React for the backend」，做响应式计算与同步引擎 |
| Skiplang 语言 | skiplang.com | SkipLabs 的研究型通用语言（带响应式失效的缓存与副作用追踪） |
搜索引擎里三者极易混出，本文全部内容只关于第一个——skip.dev 这个 Skip。后两个是另一家公司（SkipLabs）的东西，只是重名。
二、Skip 是什么：一份 Swift，两端原生
官网的口号非常直白：「One Swift Codebase. Two Native Platforms.」（一份 Swift 代码库，两个原生平台。）文档页进一步自称是「唯一能从单一 Swift 代码库在两个平台都交付真正原生应用的框架」。这里「真正原生」的定义值得抠一下字眼：
- iOS 侧：就是 SwiftUI，没有附加运行时、没有解释器、没有额外 GC——甚至可以开启 SkipZero 模式把所有 Skip 框架从 iOS 构建里剔除，让 iOS 产物「一点 Skip 的痕迹都没有」。官方 FAQ 给出的数字是：SkipZero 模式下 iOS 最小包体约 50 KB（Hello 样例可低至 25 KB）；入门示例常规构建约为 1 MB 的 ipa。
- Android 侧：产出的是真正的 Jetpack Compose（Google 当前主推的 Android 声明式 UI），不是自绘引擎逼近的「像素级模仿」，也不是 WebView。
这套定位背后有一笔清晰的市场账（官方对比页口径）：iOS 用户 ARPU（人均收入贡献）约 140 美元，约为 Android（约 69 美元）的两倍；而 Android 用户规模约 37 亿，远超 iOS 的约 14 亿。结论是「iOS 优先开发、Android 延后移植」的行业惯性其实两头都亏——而 Skip 的切入点正是让 iOS 团队几乎零成本地顺手拿下 Android。
与 Flutter、React Native 这类「写一份代码、两平台各自非原生」的方案相比，Skip 把跨平台的成本从「运行时/渲染层的妥协」挪到了「构建期的代码生成」上。这也是它最根本的技术分野：Skip 是编译器/构建工具，不是运行时。
三、两条技术路线：Lite 转译与 Fuse 原生编译
Skip 到 Android 有两条路线，且按 Swift 模块粒度选择，可以在同一个 App 里混用（官方推荐「业务逻辑用 Fuse、平台服务集成用 Lite」）。
3.1 Skip Lite：Swift→Kotlin 转译（默认模式）
Lite 模式把 Swift 源码转译为等价的 Kotlin 源码，再交给标准 Kotlin 编译器编译。官方架构文档披露的转译管线共七个阶段：
- Parse：用 SwiftSyntax 把 Swift 解析成语法树（多文件并发）；
- Decode：转换成 Skip 内部 AST；
- Gather：收集符号表（类型、扩展、顶层函数、别名）；
- Prepare：解析类型引用、合成隐式构造器、处理泛型；
- Translate：把 Swift AST 映射为 Kotlin 语法树（模块名按规则映射，如 SkipFoundation 对应 skip.foundation）；
- Transform：约 20 个有序的 Transformer 消化语义差异——struct 补复制语义与 willmutate/didmutate 变异追踪、enum 转密封类并合成 CaseAccessible、Error 转 Throwable、@Observable 适配 Compose 状态、XCTest 转 JUnit 等；
- Output：一个 .swift 对应生成一个 .kt，并记录字节级偏移的 OutputMap 源码映射，用于把 Kotlin 堆栈回映射到 Swift 的文件与行号。
语义映射的几个关键规则（也是坑的高发区）：
- Swift 的 64 位
Int映射为 Kotlin 的 32 位Int——官方文档自己点名这是静默溢出 bug 的来源； - 集合类型映射为 skip.lib.Array / skip.lib.Dictionary，以保留 Swift 的值语义；
Optional<T>对应T?；struct 变成带复制语义的 class。
Lite 最大的卖点官方称为 「Kotlish」方言——「语法上是 Swift，语义上是 Kotlin」。转译产物是人类可读、可以直接覆盖（override）的 Kotlin，甚至可以用 Skip 注释在 Swift 文件里内联字面 Kotlin 代码，在 Android Studio 里拿到完整堆栈逐步调试。这一点直接回应了「转译器黑箱」的历史偏见：出问题的时候你能打开生成物看。
3.2 Skip Fuse：Swift 原生编译（官方 Android SDK）
Fuse 是 2024 年底开始披露、2026 年 3 月随 Swift 6.3「转正」的路线：直接用官方 Swift SDK for Android 把 Swift 原生编译（swiftc 交叉编译为 .so 原生库），运行时不经过 JVM 字节码。此时转译器的角色从「翻译整个 App」缩小为「生成桥接层」：分析模块公开 API，生成走 JNI 调用 Swift 的 Kotlin 包装，以及暴露 Swift 符号给 JNI 的 _Bridge.swift 文件。桥接配置从粗到细支持模块级 bridging: true、类型级 @bridge / @bridgeMembers，还有名为 AnyDynamicObject 的反射逃生舱（编译期不检查，官方建议把 Apple 的 swift-java 作为强类型替代）。基础设施链条是：swift-jni → skip-android-bridge → skip-fuse → skip-fuse-ui → 应用。
两种模式的取舍（官方 Modes 页口径）：
| 维度 | Skip Lite（转译） | Skip Fuse（原生编译） |
|---|---|---|
| 产物 | 人类可读的 Kotlin 源码 | swiftc 交叉编译的 .so |
| 语言支持 | 受 Swift→Kotlin 映射能力限制 | 完整 Swift（泛型模式、运算符重载无限制） |
| 运行行为 | JVM 语义、GC、确定性释放无法复刻 | Swift 原生行为，含确定性释放 |
| 标准库 | SkipLib/SkipFoundation 部分重实现 | Apple 完整 stdlib 与 Foundation |
| 三方生态 | 可转译的三方库少 | 凡能在 Android 构建的 Swift 包都能用 |
| 包体 | 小（Android 最小约 5 MB，含 Compose） | 增加约 60 MB Swift 运行时库 |
| 调试 | Android Studio 断点调试生成 Kotlin | 调试受限，崩溃符号需 swift demangle |
| 可退出性 | 两端都有完整源码 | iOS 有，Android 侧无独立 Kotlin 代码库 |
有意思的细节：即使是全 Fuse 应用，SkipUI 这一层也永远是转译的（原生侧由 SkipFuseUI 桥接到转译出来的 Compose 代码）。「转译是 Skip 架构的基础部分，不会消失」——官方 FAQ 原话。
3.3 谁该用哪种
官方建议大多数 App 主用 Fuse（尤其是业务逻辑复杂、依赖三方 Swift 包的场景），Lite 适合需要与 Android 平台服务深度集成的库（官方自己的 Skip Keychain 就是 Lite 写的）。混用时通过每个模块的 Skip/skip.yml 里 mode: 'native' 或 'transpiled' 声明。
四、开发者体验：Xcode 里一次 ⌘R，两个模拟器同时跑
上手流程（官方 Getting Started）：
brew install skip # 安装 skip CLI（顺带装 Android SDK 与 Gradle）
skip checkup # 校验环境（示例输出：Xcode 26.2 / Swift 6.2.3 / Gradle 9.2.1）
skip create # 交互式向导：App 或 Library、Fuse 或 Lite、bundle ID 等
skip android emulator create && skip android emulator launch之后在 Xcode 里选 App scheme 点 ⌘R，iPhone 模拟器和 Android 模拟器会同时构建、同时启动——iOS 走 Xcode 常规构建，同时构建插件驱动 Gradle 生成 Kotlin 工程并打包安装 APK。构建行为由 SKIP_ACTION 控制（launch / build / none，不想等 Android 时可以关掉单独迭代 iOS）。
环境要求与硬性边界：
- macOS 15+、Xcode 16.4+、Swift 5.9+，另需 Android Studio；iOS 最低 16，Android 最低 API 28（Android 9）、目标 API 34；Fuse 需要 Swift 6+ 并通过
skip checkup --native校验； - Linux/Windows 只支持建工程、构建框架库和 CI，完整 App 构建必须 macOS（其实 iOS 开发本来就绕不开 Mac）；
- 官方推荐 32 GB 内存——HN 上被质疑后在帖子 里澄清：那是「同时跑 Xcode + Gradle + 两个模拟器」的建议，Skip 本身并不吃内存，分开构建完全没问题；
- 首次构建慢（框架库源码分发，Gradle Compose 缓存约 1 GB），官方强调 Android 性能必须以 Release 模式为准。
测试方面有个我很喜欢的设计——奇偶测试（parity testing）：skip test 把同一份 XCTest 同时转译为 JUnit 跑 Android（默认 Robolectric 跑 JVM，设置 ANDROID_SERIAL 则上真机/模拟器），两平台测试并行执行、失败通过源码映射回 Swift 位置报告。跨平台框架最怕「两端行为悄悄不一致」，把双端一致性做进默认测试流程是对症下药的。注意 Fuse 模式的原生测试要单独用 skip android test。
五、生态版图与版本现状（2026 年 9 月）
GitHub 主仓库 skiptools/skip 约 3.2k stars / 106 forks，MPL-2.0 协议。核心框架（「Skip Stack」）当前版本：
| 包 | 版本 | 发布日期 |
|---|---|---|
| skip（CLI / 构建插件） | 1.9.8 | 2026-08-29 |
| skipstone（转译引擎） | 1.9.8 | 2026-08-29 |
| skip-ui（SwiftUI→Compose） | 1.59.3 | 2026-09-03 |
| skip-fuse-ui | 1.18.2 | 2026-09-08 |
| skip-foundation | 1.4.4 | 2026-08-21 |
| skip-model（Observation） | 1.7.9 | 2026-08-20 |
| skip-fuse / skip-bridge / skip-lib | 1.0.3 / 0.17.3 / 1.4.1 | 2026-08 |
生态分三层：平台框架 17 个（SQLite、Keychain、WebView、传感器、NFC、推送、蓝牙、日历、联系人、FFI、二维码、ZIP 等），集成框架 10 个（Firebase、Supabase、Auth0、RevenueCat、Sentry、PostHog、Lottie、LiveKit/WebRTC、Socket.IO 等）——其中 sentry、auth0、revenue、nfc、socketio、livekit、calendar、contacts 八个都是 2026 年初新发的 0.1.0，扩张速度肉眼可见。文档站还有 60+ 个 SwiftUI 组件的跨端行为参考（相当于一份「SwiftUI 在 Compose 上的等价物词典」）。
两个生态数字值得记：Swift 6.3 官方 Android SDK 发布时，Swift Package Index 上已有超过 2200 个包能在 Android 构建；swift.org 更早的口径是 SPI 25% 以上的包已兼容 Android。另外官方还发布了 Claude Code / Cursor 的 agent skills（skiptools/skills）——把「让 AI 在 Xcode 工程里顺手把 Android 也写了」当成了正式支持场景，这个方向感和本博客一直关注的 AI 编码工作流高度重合。
六、历史线与商业模式：两位老将和一场开源豪赌
Skip 由 Abe White 和 Marc Prud’hommeaux 两人于 2023 年创立。这两位是合作了二十多年的老搭档：90 年代末一起做 Java ORM 工具 Kodo（公司 SolarMetric 2006 年被 Oracle 收购，技术开源成了 Apache OpenJPA）；iPhone 时代做出最早的电子书阅读器之一 Stanza（公司 Lexcycle 被 Amazon 收购，两人都参与过 Kindle 的 iOS/Android 应用开发）；之后 Abe 在 Twitter 做了约十年 iOS UI 框架技术负责人，Marc 经手过 NYT Cooking 和 Bose 的 App。可以说「iOS 原生 + 双平台移植的痛」是他们吃了几十年的饭。
时间线（据官方博客与 Swift 论坛）：
| 时间 | 事件 |
|---|---|
| 2023 | 发布 Skip Technology Preview（SwiftUI→Compose 转译路线亮相） |
| 2024-08 | Skip 1.0 发布（Xcode 插件工作流成型）；同年「Native Swift on Android」系列文章披露 Fuse 原生编译路线 |
| 2025-02 | 联合创建 Swift on Android 工作组（后成为 Swift 官方工作组） |
| 2025 | Skip 1.5 支持全原生跨平台 Swift；WWDC25 Liquid Glass 设计当日跟进适配 |
| 2026-01-21 | 完全免费开源：移除许可密钥、skipstone 引擎开源、协议转为 MPL-2.0、主站迁至 skip.dev（Skip 1.7） |
| 2026-03 | Swift 6.3 发布首个官方 Android SDK，Skip 1.8 全面切换（Skip Fuse「转正」） |
| 2026-06 | 官方博客《Android development is now Compose First》 |
商业模式的变化值得单独说：Skip 此前是商业订阅（HN 讨论中提到的档位从每月 10 美元到 5000 美元不等，开发者个人档另有每年 1000 美元的说法），2026 年 1 月起全部免费，公司保持 bootstrap（无外部融资），靠个人与企业赞助维持。Marc 在 HN 上说得非常坦率：Flutter 的黯淡前景让 Skip 关注度激增，「是我们开放平台、赶上这波浪潮的动因之一」。这不是财务充裕后的从容，更像是一次押注窗口期的进攻性决策——用免费换生态位。
七、同类框架横评：六条路线一张表
先把主流方案按技术路线摆到一张表上（状态截至 2026 年 9 月）：
| 框架 | 语言 | UI 方案 | 背靠 | 一句话现状 |
|---|---|---|---|---|
| Skip | Swift | 双端真原生（SwiftUI + Jetpack Compose） | 独立两人团队 | 站上 Swift 官方 Android SDK 东风，生态小而美 |
| Flutter | Dart | 自绘引擎（Impeller/Skia） | 用户量最大；2024 起经历裁员与设计体系解耦动荡，暂缓跟进 Liquid Glass | |
| React Native | JavaScript/TS | 原生控件 + JS 桥（New Architecture/JSI） | Meta | 主流依旧；性能与依赖维护是长期争议点 |
| KMP + Compose Multiplatform | Kotlin | Android 原生；iOS 上 CMP 走 Skia 自绘 | JetBrains/Google 背书 | KMP 稳定上升，CMP 于 2025-05 达成 iOS 稳定 |
| .NET MAUI | C# | 原生控件映射（Handler） | 微软 | 官方持续维护，社区对质量与修复速度有怨言 |
| Ionic / Capacitor | Web 技术 | 系统 WebView | 独立公司（Ionic） | Web 技术栈团队的最省力路线 |
| Tauri 2 | Rust + 前端 | 系统 WebView | 开源社区 | 2024-10 起支持移动端，桌面端起家的后起之秀 |
Skip 官方对比页（口径注意：以下数字与论点均来自 Skip 官网，天然有立场）对前三个对手的攻击点：
- vs Flutter：自绘引擎的「恐怖谷」问题（不是平台控件，永远慢半拍）；内存约 40 MB vs 原生约 20 MB（最小应用）；Flutter 已表态不做 iOS 26 Liquid Glass 的 Cupertino 实现（flutter/flutter#170310，Material/Cupertino 正解耦为独立包）；
- vs React Native：JS 桥是结构性瓶颈；内存约为原生 Swift 的 4.5 倍；引用 Shopify 迁移中出现的加载回归与 crash-free 率下降、以及「100% RN 是 anti-goal」的表态；NPM 生态弃养严重（某团队 42 个依赖 25 个无人维护）；
- vs Compose Multiplatform：CMP 在 iOS 上经 Skia/Metal 自绘、观感是 Material 而非 iOS 范式；iOS 包体 24.8 MB vs 原生 1.7 MB；Kotlin↔Swift 互操作要过 Objective-C 桥（泛型被剥、可空类型装箱）；ThoughtWorks 技术雷达把 KMP 放在 Trial 而非 Adopt。
反方证据也必须记录（主要来自 HN 同一批讨论）：Nubank 用 Flutter 服务 1 亿以上客户，是「大规模生产」的反例；有开发者指出 Flutter 在低端 Android 上的流畅度反而好于原生；Goodnotes 用 Swift 编译到 WASM 的路线覆盖 iOS/Android/Windows/Web，数千万 MAU——说明「非 Skip 路线的 Swift 跨平台」也存在。另外 Cash App 的 Redwood（Kotlin/Swift 共享 UI 树）据 HN 口径已在 2026 年初停止活跃开发——小众跨平台方案的生存率，本身就是这个赛道的风险注脚。
把视野再拉远一点：转译器路线在历史上并不新鲜——Java→ObjC 的 J2ObjC（Google）、Java→JS 的 GWT、多目标语言的 Haxe 都走过「能跑但不够优雅」的路。Skip 的差异化在于用现代编译器基础设施（SwiftSyntax 前端 + 语义 Transformer + 字节级 source map + 可覆盖的生成物）重做了这条老路，并且第一次让「源语言」和「目标语言」都是各自平台的第一公民（SwiftUI 与 Compose 恰好互为镜像，这是转译可行性的根基）。
八、社区真实声音：HN「开源帖」的赞誉与质疑
2026 年 1 月开源当天的 HN 帖子 是目前最好的社区样本。正面之外，几条批评非常集中：
- 「生产案例在哪？」——出现频率最高的质疑。 多位开发者表示技术路线认同，但「从未听说谁真的在生产用 Skip」，缺少公开的大型商用案例。社区里现有的公开实践多为官方样例（Showcase、Fireside、Block Blast 游戏复刻等）与中小型应用；
- 商业模式可持续性：两人团队靠赞助，「捐赠不是商业模式」的质疑不少，社区建议走 Expo/Next.js 式的支持服务、培训与商业组件路线；
- SwiftUI 自身的痛点被顺带吐槽：没有可靠的热重载（Inject 脆弱）、Preview Canvas 对 AI agent 不友好（这反而是 Skip 官方做 agent skills 想解决的点）；
- 关于 KMP 的正面交锋：有人问「为什么不选 KMP」，Marc 的回答值得原样引用——「CMP 在 Android 上是原生的、在 iOS 上是异类；Skip 在两个平台上都是原生的」，同时承认 KMP 的优势在 desktop/Web 目标和 Kotlin 生态，且 Skip 与 KMP 并不互斥（2024 年就有官方博客与 JetBrains 播客谈集成）。
也有让我印象深刻的正面细节：有盲人导航应用 Soundscape Community 的维护者在帖子里认真评估用 Skip 把 iOS 应用带到 Android——因为 Skip 产出真 Compose，TalkBack 等 Android 无障碍设施开箱即用，这是自绘引擎方案天然做不到的。
九、我的评估：适合谁，风险在哪
适合：iOS 原生团队（技能栈以 Swift/SwiftUI 为中心）想以增量方式吃下 Android；对「原生观感与无障碍」有硬要求的工具类、内容类应用；已经囤了大量 Swift 业务代码、想让这些代码「顺便」跑在 Android 上的团队。Fuse 模式对依赖三方 Swift 包的重逻辑应用尤其合适。
不适合：团队主力是 Kotlin/前端背景（选 KMP 或 RN 更顺）；需要 Web/桌面多端全覆盖（KMP、Flutter、Tauri 的目标矩阵更大）；对 Android 侧「可维护的原生代码资产」有强诉求（Lite 虽然产出可读 Kotlin，但那是生成物；Fuse 侧 Android 依赖生成桥接，退出后没有独立 Android 代码库——可退出性不对称是真实的）；追求成熟度和大规模验证的低风险偏好团队。
风险清单：两人团队 + 赞助制商业模式，Bus factor 极低；生产案例稀缺，文档虽完善但社区沉淀浅；Android 侧长期依赖生成物，「半退出」状态可能持续多年；Fuse 依赖的官方 Swift Android SDK 自身仍在快速演化（文档明言包体与构建速度问题「会随 SDK 成熟改善」）。对冲这些风险的是：MPL-2.0 开源 + iOS 侧 SkipZero 零锁定 + Swift 官方路线的顺风——最坏情况下降级为一个纯 iOS 项目，沉没成本可控。
十、总结
这次调研最大的收获不是 Skip 本身，而是它揭示的一个结构性变化：Swift 6.3 官方 Android SDK 落地之后，「Swift 单语言双原生」从怪谈变成了有官方地基的路线。Skip 的聪明之处在于没有发明新语言、新渲染引擎，而是老老实实做「SwiftUI 与 Compose 这对天然镜像之间的翻译层」，并把翻译质量做到可读、可调试、可退出。它的所有劣势——生态小、团队小、案例少——都是时间问题；而它的核心优势——双端真原生、零 iOS 足迹、搭上 Swift 官方路线——是结构性的。如果 2026-2027 年 Flutter 的动荡持续发酵，Skip 很可能成为「iOS 团队出逃」叙事里的最大受益者之一；即便不成，它也是观察「编译期跨平台」这条路线极限的最佳样本。
参考资料
- Skip 官方文档首页：What is Skip?
- Skip Getting Started ／ Lite 与 Fuse 模式 ／ FAQ
- Skip 内部架构文档（转译管线与 Fuse 工具链）
- Skip 官方框架对比页 ／ 官方博客 ／ 发布日志
- skiptools/skip GitHub 仓库 ／ Skip 团队介绍
- Swift 6.3 发布公告（含首个官方 Android SDK） ／ Swift SDK for Android 入门 ／ Swift Android 工作组公告
- HN：Skip is now free and open source（2026-01 社区讨论） ／ HN：Skip 单代码库双原生讨论
- Swift Forums：Skip 1.0 发布帖