苹果审核又卡我三天，逼得我搞出了这套“非法AI原生应用”前端架构

晚上11 点半了，盯着 App Store Connect 那个该死的黄色圆点——"Waiting for Review"，我手里这杯冰美式突然就不香了。

这是本周第三次被拒。理由很可笑：元数据违规。其实就是 AI 生成的新文案里带了个敏感词，改过来也就几秒钟的事。但为了这几秒钟的改动，我得重新打包、上传、然后跪求苹果审核团队的大爷们心情好点，别让我再等上 48 小时。

老板在群里艾特我：“竞品那边的 AI 助手已经能画 K 线图了，我们的还得等发版？”

我看着屏幕，只想砸键盘。兄弟，这样的经历，你应该也有过吧。

做原生开发的兄弟都懂这种憋屈。现在的 AI 迭代速度是按“秒”算的，今天出个新模型，明天加个新能力。但我们的 App 发版速度呢？按“周”算都谢天谢地了。

用周更的 App 去承载秒更的 AI，这本身就是个 bug。

以前碰到这种情况，我们通常会捏着鼻子用 WebView。把变动频繁的页面做成 H5，虽然能动态更新，但那个体验……说实话，挺恶心的。滑动时的那种粘滞感，加载时的白屏，还有跟原生组件格格不入的交互，用户手指头又不瞎，一摸就知道你偷懒了。

我就在想，有没有一种路子，既能像 Web 那样随时热更新，又能跑出 Flutter 的原生性能？

最近，我就在思考哦这个问题，折腾了一圈，还真让我摸索出一套有点“邪修法门”但极其好用的组合拳：json-render + WebF。

先说结论：这可能是目前搞 AI 原生应用（AI-Native App）最野、但也最有效的架构。

json-render：

json-render

json-render

json-render ，你一看就懂，AI->JSON->RENDER->UI ，直观的了解就是 AI来生成界面，但是中间是通过让 Ai 输出 json 二不是dom 叔或者 React 或者 Vue 那么一大坨。而且这货最为突出的是。

渐渐式

渐渐式

这就意味着，用户不需要的等待界面完全渲染完毕才能看到整个界面，解决了等待焦虑的感觉。

他的玩法也不是很难，大概的流程就是三步

第一部定义组件类目，第二部开始你的表演，第三部就用这套框架可以看到渲染界面。

webf

webf

webf

webf 这个库也是很简单就说明白了，他就是可以把web 页用原生的方法在 flutter 上渲染，怎么做到的，他其实就是基于 quick.js ,转换为语法树在通过构建 flutter 的 renderTree 来渲染，这就好玩了，flutter 以他极好的双端一致性和渲染性能而为跨端框架的翘楚。在结合 quickjs 这种黑科技，突然就有了动态化，这就意味着，你能够不用走那个烦人呢的 App Store 就可以更新一些特性（当然不要做功能性变更，一样会被拒或下架处理）。

这里，你肯定要想，为啥，我们不直接用 webf，要 jsonRender 干啥，诶，我来告诉你。

为什么 AI 根本不想要你的 UI 代码？

大家有个误区，觉得 AI 编程就是让 LLM 给你写 Flutter 代码或者 React 组件。

别逗了。你敢把 GPT-5 生成的代码直接在客户端跑起来？且不说各种 import 错误和幻觉，光是安全性就够你喝一壶的。万一它抽风写了个死循环，你的 App 直接白屏或者 crash。

AI 这玩意儿，最擅长的其实是输出 JSON。everything is markdown。

这就是 json-render 的逻辑。别让 AI 写 UI，让 AI 填空。比如用户问：“上季度的销售咋样？”AI 只需要吐出一句：{"type": "chart", "data": [100, 200, ...]}。

然后你的端侧得有个“翻译官”，把这串 JSON 变成界面。这在 Web 上早就玩烂了（Vercel 家的 v0 就是这路数），但在 App 上一直没火起来。

为啥？因为在 Flutter 里手写一个通用的 JSON 渲染器太累了。而且最致命的是，如果你想加个新组件——比如突然要支持一个“雷达图”，你还是得改原生代码，还是得发版。死循环。

WebF：那个被误解的“私生子”

这时候，WebF (Web on Flutter) 进场了。

很多老得掉牙的教程还在说它叫 Kraken，说它就是个阿里的 KPI 项目。我得帮它说句公道话：现在的 WebF，真不是当年的吴下阿蒙了。

它和 WebView 有本质区别。WebView 是在你的 App 里开个微型浏览器，画在另一层上，内存吃得凶，通信还慢得要死。而 WebF，它本质上是一个跑在 Flutter 里的 JS 引擎。

这一层区别太关键了。WebF 解析完 HTML/CSS 之后，是直接调用的 Flutter 底层（RenderObject）来绘制的。

这就意味着：

1. 1. 它画出来的就是原生组件。没有中间商赚差价。
2. 2. 通信极快。它用了 Dart FFI，JS 调原生能力不需要序列化，快得跟调本地函数一样。
3. 3. 手感统一。它的滚动逻辑就是 Flutter 的滚动逻辑，丝般顺滑。

当这两货凑到一起……

现在，把 json-render 和 WebF 拼在一起，你会发现打开了新世界的大门。

场景是这样的：

1. 用户跟 AI 说：“给我看看昨天的用户画像。”
2. AI 吐出一坨 JSON，指定要用 UserProfileCard 这个组件。
3. App 检查本地：坏了，本地包里没有这个组件的渲染逻辑。
4. 高潮来了：WebF 默默地从你的 CDN 上拉取了一个 5KB 的 JS 文件（就是个 React 组件）。
5. WebF 把这个 React 组件跑起来，直接用 Flutter 的渲染管线画在了屏幕上。

全过程用户毫无感知。没有 App Store 的审核。没有全量发版。甚至不需要用户重启 App。

这在苹果的规则里是合规的，因为你下发的是脚本（Script），不是可执行二进制代码。只要你不把整个 App 变成一个浏览器壳子，苹果通常睁一只眼闭一只眼。

别做技术洁癖

我知道，肯定有兄弟要喷：“在 Flutter 里跑 JS？这架构太重了吧！”“性能肯定不如纯 Dart！”

兄弟，都 2026 年了。现在的手机性能都快赶上笔电了，Flutter 的 Impeller 引擎也早就解决了卡顿问题。我们现在的瓶颈根本不是那几毫秒的渲染时间，而是交付效率。

当竞品每天都在上新功能，而你还在跟审核团队扯皮的时候，你的技术架构再完美也是废的。

WebF 这种方案，实际上是借了 Web 生态的力（你有现成的 React 组件库吧？直接拿来用啊！），去解 Flutter 动态化的题。

这感觉就像是你开着一辆特斯拉，但是给它装了个核电池。违和吗？有点。爽吗？真爽。

如果你的老板也整天逼着你搞“即时 AI 反馈”，别硬扛了。试试这套路子，把那些该死的审核时间省下来，早点下班陪陪家人，不香吗？