基于现有 Web 能力，评估移动端解决方案的可行性与性价比，为 AI 问答平台（RAG + 多模态）选择合适的实施路径
Circuit 是一个 AI 问答平台，核心能力包括 RAG（检索增强生成）和多模态交互（文本、图片、文档等）。目前已有生产环境的 Web 应用，现需进一步支持 iOS 和 Android 移动端平台。
本次评估的核心是：在已有 Web 能力的基础上，评估移动端方案的可行性与性价比，选择适合 Circuit 的实施路径。
鉴于 Web 应用已经存在，移动端的核心问题是：跨平台 vs. 原生开发，以及如何在性能、成本、效率之间取得最佳平衡。
移动端技术路线大体可分为三类：Web 应用、跨平台、原生开发。
基于 HTML / CSS / JS 构建，同一套代码适配桌面和移动端，用户通过浏览器访问
编写一套主代码同时覆盖 iOS 和 Android，通过框架映射到平台原生能力
针对各平台分别开发，代码直接运行在原生操作系统环境中
由于 Circuit 已有 Web 应用，Web 方案已提供了基线能力。因此本次评估重点比较跨平台与原生，Web 应用作为参照。
| 评估维度 | Web 应用 | 跨平台 | 原生开发 |
|---|---|---|---|
| 性能表现 | ★★★★★ | ★★★★★ | ★★★★★ |
| 开发效率 | ★★★★★ | ★★★★★ | ★★★★★ |
| 综合成本 | ★★★★★ | ★★★★★ | ★★★★★ |
| 人才招聘 | ★★★★★ | ★★★★★ | ★★★★★ |
Web 应用在开发速度、低成本和复用已有 Web 能力方面优势明显，但在性能和系统级能力方面上限最低。
原生开发性能最强、用户体验最佳、系统集成最深，但开发成本最高，通常需要分别维护 iOS 和 Android 两套实现。
跨平台处于两者之间，在性能、效率和成本之间取得了较好的平衡。
结合 Circuit 的业务特点（AI 问答、多模态上传 / 回放等场景），产品对图形性能没有极高要求，大多数场景下跨平台方案已足够支撑核心业务需求。
当前主流跨平台方案包括 React Native、Flutter、Ionic 和 Kotlin Multiplatform。
Circuit 目前的移动端方案基于 Ionic，即通过一个 App 外壳嵌入 WebView，在内部加载 Web 应用。本质上仍是 Web 应用运行在 WebView 中，性能和原生体验上限较低。
| 方案 | 性能表现 | 生态系统 | 人才招聘 | 可维护性 |
|---|---|---|---|---|
| React Native | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ |
| Flutter | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ |
| Ionic | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ |
| Kotlin Multiplatform | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ |
综合最均衡的方案。在性能、生态、招聘和长期可维护性方面都表现良好，对前端团队最友好，迁移成本相对最低。Web 前端开发者可快速上手，社区活跃且第三方库丰富。
性能强劲、UI 一致性高，但需要引入 Dart 语言和完整的 Flutter 技术栈。团队学习曲线和招聘门槛都高于 React Native。更适合愿意重建技术栈、追求更强 UI 控制力的团队。
如果目标是在当前 WebView 包壳方案上继续迭代、最大程度复用已有 Web 资产，Ionic 是最省力的选择。但本质上仍是 WebView 中运行的 Web 应用，性能和原生体验的上限最低。
更适合原生团队希望共享业务逻辑的场景，不是典型的前端跨平台 UI 方案。在当前团队结构下，采纳门槛较高，短期性价比不突出。
综合排名
综合 Circuit 当前团队能力、已有 Web 基础和未来双端支持成本，React Native 是现阶段最均衡的跨平台方案。Flutter 更适合愿意重建技术栈的团队；Ionic 更适合继续走低成本短期策略；Kotlin Multiplatform 暂不推荐作为主选。
如果选择原生路线，iOS 主要使用 Swift，Android 主要使用 Kotlin。在实际落地中，如果资源有限，团队通常优先建设 iOS 端，再评估 Android 投入节奏。
| 语言 | 性能表现 | 生态系统 | 人才招聘 | 可维护性 |
|---|---|---|---|---|
| Swift (iOS) | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ |
| Kotlin (Android) | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ |
虽然跨平台框架可以接近 iOS 风格，但在默认组件体系、交互细节和整体平台一致性上仍存在差异。Swift 更容易实现完全原生的 iOS 体验。
以下系统级、性能敏感的能力，由原生代码处理通常效果更好：
承载核心业务流程
AI 对话、文档查看、搜索等
覆盖大部分业务页面和交互
承载平台级能力
App Shell、推送、相机、生物认证
性能监控、崩溃处理等底层模块
主要业务页面和交互用跨平台方案构建，App 外壳和关键系统级能力由原生处理。
避免继续以纯 WebView 包壳作为长期方案。
参考豆包、元宝等头部 AI 应用的普遍做法，行业主流方案并非纯 WebView 路线，而是：
对于 Circuit 这样的产品，这种方案通常能提供更好的性价比：
Ionic 本质上是在原生 App 壳中运行 WebView，性能和交互体验上限较低。随着业务复杂度提升，纯 WebView 路线会越来越难以满足用户对流畅度和原生体验的期望。短期可以维持，但不适合作为长期主路径。
原生应作为补充（承载 Shell 和关键能力），而非将全部产品重建为两套独立原生应用。这样做成本过高、人力投入大，且对 AI 问答类产品而言收益不成正比。
综合考虑业务场景、现有技术基础、开发效率、成本控制和长期扩展性，最适合 Circuit 的方案是：
这一方案在性能、用户体验、开发效率和团队可行性之间取得了良好的平衡，
适合作为 Circuit 移动端开发的主路径。
跨平台为主（React Native），原生兜底（Swift / Kotlin），不建议继续 WebView 包壳路线。