第三篇文章收尾时，我们说迁移完成后的日常是"新功能默认 KMP-first"。这句话没错，但它隐藏了一个前提：共享层代码在两端的运行环境并不对等——同样的代码，在 Android 上是一次可捕获的异常，在 iOS 上可能是整个进程的直接死亡。

第二篇文章的结尾，我们给出的方案是"KMP ViewModel + SKIE + 一个 50 行的 StateHolder"，当时我们说：这个成本很低，一个 ViewModel 的桥接通常不到 50 行。

opencodex 是一个本地代理，把 Codex 的 Responses API 翻译成任意 LLM provider 的协议。你可以在 Codex CLI、Codex App、SDK 里用 Claude、Gemini、DeepSeek、Grok、GLM、Qwen 甚至本地 Ollama 模型——也能在 Claude Code 里同样用任意模型——不需要等任何人添加官方支持。

上一篇文章记录了轻糖将数据层从 Supabase Swift SDK 下沉到 KMP shared/ 模块的过程。但当时我们留了一个尾巴——ViewModels 原封不动地留在 iOS 侧用 @Observable，承诺"暂不迁移"。

SugarLite 最初是一个纯 iOS 应用，技术栈是 SwiftUI + MVVM + Supabase Swift SDK。随着 Android 版本的需求提上日程，如果简单地把业务逻辑复制一份到 Kotlin，后续的维护成本会成倍增长——网络层、数据模型、业务规则都要双端维护。所以我们选择了 Kotlin Multiplatform，让 shared/ 模块承载所有跨平台业务逻辑，iOS 侧只保留 SwiftUI 和系统框架调用。

前面聊过 cc switch 的基础用法，今天单独说一下 CC Switch 里 Claude Desktop 面板的配置。在 3.15.0 中加入的功能，专门用来给 Claude Desktop 这个官方桌面客户端接入第三方供应商。

CC Switch 中的「Claude」和「Claude Desktop」是两个不同的面板，分别对应 Claude Code（CLI）和 Claude Desktop（桌面客户端）。区别在于 Claude Desktop 用的是自己的 3P profile 配置，而不是 ~/.claude/settings.json，两个面板在图标右下角会有小标记区分。