看了下官方的适配 Duo 设计指引，苹果的指南还真有点东西，看的头皮发麻，比如 Duo 下，外屏和内屏最好不能是两套 UI ，应用应该做到支持持续适应当前拥有的空间界面效果。 外屏、内屏、半折、Spl

Riverpod 深度解析：从响应式本质到最小可运行闭环 一、为什么是 Riverpod？ 在 Flutter 状态管理的选型中，我们常常在 setState、Provider、Bloc 之间纠结。它

概述 总结一份目前公司在用的flutter结合gex开发的AI skill吧。 一、核心原则 视图与逻辑严格分离：View 只负责渲染和触发事件，不写业务逻辑，不实例化 Controller。 依赖注

近期，由小红书联合多伦多大学等高校的研究人员发布了 《SWE-Bench Mobile》（2602.09540） 论文，内容主要是评估 LLM 智能体在处理真实生产级移动端应用开发任务时的能力，并提出

一、iOS 27 的变化与坑点 这些年 Apple 一直在“劝”咱们用 UIScene 的生命周期管理模式。虽然之前出了很多版本都在报 warning，但咱们很多项目为了图省事，一直赖着旧的 AppD

前面写了关于uniapp中定义原生插件，这篇文章介在 Flutter 日常开发中，我们同样会遇到一个尴尬的局面：项目需要一个特定的原生能力，但 pub.dev 上要么没有现成的插件，要么已有的插件年久

引言 如果你最近升级了 Flutter 项目或 Xcode，可能已经遇到了与 UISceneDelegate 相关的警告或构建问题。 Apple 在 iOS 13 中引入了基于 Scene 的生命周期

MediaQuery.of(context) 为什么可能拖慢页面，以及该用什么替代。 打开聊天页面，点一下输入框，键盘从底部滑出来。看上去挺顺畅，对吧？结果测试同事提了个问题：“键盘弹出时聊天列表会卡

马上就是 Google I/O 了，而在这个时候，官方突然官宣，从下一个 Flutter 稳定版 3.44 开始，Swift Package Manager (SwiftPM) 将取代 CocoaPo

在今年的 WWDC25 上，Apple 发布 TN3187 文档，其中明确了要求：“在 iOS 26 之后的版本，任何使用最新 SDK 构建的 UIKit 应用都必须使用 UIScene 生命周期，否

这个话题的起因来自 2023 年 WWDC 之后苹果发布的「App Store 提交隐私更新」政策，政策主要提出了两点：第三方 SDK 隐私清单和签名和需要提供必要理由的 API 流程。 其实先简单总

最近看到一个很有意思的项目，它是一个由国外 Rork 团队推出的 AI 移动应用开发平台，宣称是“全球首个在浏览器中构建原生 Swift 应用的 AI 工具”，也就是，你可以不需要 Mac 和 Xco

有传言，闲鱼有新业务没采用 Flutter，这给很多人造成了闲鱼放弃 Flutter 的观念。辟谣来了！

2023 年底的时候，我就发过了 《Flutter 上了 Apple 第三方重大列表，2024 春季 iOS 的隐私清单究竟是什么？》 相关内容，如果你还对隐私清单等相关要求不了解，建议先看看前文。

最近 Swift 发布了 6.3 版本，而这个版本最特殊的地方在于：把 Android SDK 作为首个官方发布版本给加了进来，其实这个话题在去年的 《Swift 官方正式支持 Android》我们就

现如今，在跨平台方案上仍活跃于市场的，仅剩 RN 与 Flutter。让我们通过框架的设计初衷，架构，开发环境，代码风格，等多个层面看看它们的差异。看看哪一个更适合你。

业务层 业务层我采取的是借助MVVM（Model-View-ViewModel）模式 ，定义抽象类BaseViewModel帮我统一管理ViewModel，定义抽象类BaseWidgetPage帮我统

Flutter App 大型项目是如何进行分层设计的？每个分层组件都有自己的职责互不干扰，都支持单独的开发测试，尽可能的做到依赖于抽象而不是具体的实现。

美好的 2024 从「适配」开始，按照苹果的尿性，2024 春季开始大家将不得使用 Xcode15 来构建 App ，另外根据《2024 的 iOS 的隐私清单》 要求，使用 Flutter 的开发者