对于 iOS 用户来说，最近或多或少都会看到与 Coruna、DarkSword 有关的高危漏洞消息。两个攻击链均采用水坑攻击的方式，攻击者无需受害者进行任何交互，仅需访问一个被植入恶意 iframe 的合法网站或加载恶意广告，即可触发完整的攻击链，在窃取资料后自动清理攻击痕迹。由于工具链利用的漏洞存在于 iOS 13 至 18.7 的绝大多数版本中，截至目前，已有上亿用户受到影响。
Coruna 主要针对 iOS 13 至 iOS 17 的设备，在过去几个月间，苹果已为这些系统推送了多次安全更新。DarkSword 则主要针对 iOS 18.4 至 18.7 的设备。尽管这部分设备均具备升级至 iOS 26 的硬件条件，但由于种种原因，仍有不少 iOS 18 用户选择按兵不动。
在很长一段时间里，苹果用户对于系统更新的态度都相当积极，这也是苹果生态的一大特色。但这一趋势在去年出现了变化——Liquid Glass 带来的巨大视觉冲击，让苹果用户中第一次出现了相当比例主动拒绝升级到 iOS 26 的现象。与此同时，为遵守英国《网络安全法》（Online Safety Act）的要求，苹果在 iOS 26.4 中为英国用户引入了强制年龄验证机制，由于验证条件严苛，不少成年用户甚至被系统强行锁入‘儿童模式’，进一步推动了英国用户停留在 iOS 18 或 iOS 26.3 的风潮。而拒绝安装新版本，意味着这部分用户同时放弃了后续所有安全补丁，让设备进一步暴露在潜在风险之下。
面对这一局面，苹果承受了明显的舆论压力与品牌风险。特别是在 3 月下旬，DarkSword 的完整攻击代码被泄露到了 GitHub 上，让这一国家级黑客工具瞬间平民化，直接迫使苹果必须采取紧急行动。最终，苹果罕见地为 iOS 18 单独推出了安全补丁 iOS 18.7.7，将原本仅用于 iOS 26 的防护机制回移植到旧系统。至此，苹果完成了针对本次高危漏洞的全部官方安全响应。
无论是苹果还是生态中的开发者，大多希望用户能积极跟进系统更新——既能减少多版本适配的维护负担，也能让用户尽快享受到新 API 带来的便利。但现实是，始终有一部分用户出于性能、续航、使用习惯乃至隐私等方面的考量，有意将设备锁定在某个版本。
本次事件或许会带来两个方向上的变化：苹果在压力下调整了长期坚守的更新策略，为刻意留守旧系统的用户做出了妥协；而事件本身的广泛传播，也可能促使更多用户从安全角度重新审视“能不更新就不更新”的惯性，回到积极更新的轨道。这种双向的改变，或许正是这场风波意料之外的收获。
近期推荐
通过 Animatable 深入 SwiftUI 动画 (Animatable in SwiftUI Explained - Complete Guide with Examples & Deep Dive)
网络上并不缺少探讨 SwiftUI 动画机制的文章，但 Sagar Unagar的这篇仍然提供了一个颇具启发性的切入点。他没有从隐式或显式动画入手，而是围绕 Animatable 协议做了一次系统梳理：从 animatableData 的作用，到 AnimatablePair 如何承载多个插值参数，再到通过自定义 VectorArithmetic 让更复杂的数据结构参与动画。文章最值得注意的一点在于其核心视角：SwiftUI 实际上是在“动画数据”，而非直接对视图进行动画处理。
在 Swift Package 中共享本地化资源 (Localization in Swift Packages)
Xcode 能为 .xcstrings 文件自动生成类型安全的 Swift 符号，但这些符号仅在资源所在的 module 内可见——一旦将本地化资源抽离为独立的 Localization 包，其他 feature 包便无法享受编译期检查的优势。Khan Winter 的解决方案相当直接：通过一个 bash 脚本解析 .xcstrings 的 JSON 结构，生成 public extension LocalizedStringResource 扩展，使所有模块都能以 .l10n.helloWorld 的形式访问翻译键。
其中一个颇具参考价值的细节是 Debug 模式下的 @dynamicMemberLookup 设计——访问不存在的键时仅记录日志而不崩溃，而在 Release 构建中仍保留完整的编译期校验。相比基于 Swift 可执行文件的方案，这种实现更加轻量，复制脚本即可使用。
Coordinator 全局导航模式 (SwiftUI Coordinator Pattern: Navigation Without NavigationLink)
尽管 SwiftUI 一直在丰富基于状态驱动的导航 API，但管理全局导航一直是 SwiftUI 中的一个“痛点”。Wesley Matlock 以一个五 Tab 的音乐收藏应用为例，展示了如何通过 Coordinator 模式将导航决策从 View 中抽离：用一个 Route 枚举统一描述所有目的地，由单一的 Coordinator 对象持有导航状态并执行跳转，View 只需声明“去哪”而无需关心“怎么去”。文章没有回避 NavigationPath 不透明、路由携带模型对象导致的 Hashable 困境等实际问题。对于大多数中等规模的 SwiftUI 应用来说，这是一个务实且易于落地的导航治理方案。
把 Hacking with Swift 的编程风格写进 AI (Teach your AI to write Swift the Hacking with Swift way)
Paul Hudson 和他的 Hacking with Swift 让很多开发者走上了 Swift 与 SwiftUI 的学习之路。在 AI 时代，Paul 不仅推出了面向苹果开发生态的各类专业 Skill，也开始尝试在与 AI 的协作中注入更具个人特质的编程风格。
在本文中，他分享了一份极具辨识度（且充满他标志性幽默）的 AGENTS.md 配置。这套规则不仅约束了 AI 的技术选型，还为 AI 注入了 Paul 的灵魂：强调先展示结果再解释原理、偏好清晰而非炫技、甚至包括在代码写得漂亮时适时地喊出一句 “Boom!”。与其说这是一份用于 AI 的“系统提示词”，不如说是在为 AI 定义一种编码哲学——某种程度上，这种方式正在将冷冰冰的“代码生成”推向带有人情味的“风格迁移”。
AI Agent 的道与术
在刚过去的 Let’s Vision 2026 中，王巍（Onevcat） 发表了关于在大型开发团队中应用 AI Agent 的演讲。整场分享讨论的重点，并不是某个具体工具有多强，而是当代码实现成本被迅速压低后，团队该如何重新组织开发流程，以及工程师的价值该如何重新定位。
作为 LINE 应用开发团队的一员，Onevcat 在过去几个月中的工作重心也已明显发生变化。用他自己的话说，他正在逐步从传统意义上的 iOS 工程师，转向探索如何将 AI 应用于服务大型产品研发团队的实践者。这种角色上的变化，也让这场分享比一般的工具介绍更有说服力。
演讲围绕三个关键问题展开：如何控制上下文污染，如何把个人经验沉淀为团队可复用的 memory 与 skill，以及如何让协作模式从“人指挥多个 Agent”逐步走向更自动化的闭环。里面有不少相当接地气的实践建议，例如将 AGENTS.md 控制在精简范围内、为 Agent 提供模块定位与架构速查脚本、鼓励 Claude Code、Codex、OpenCode 等多种 harness 并存，以及通过 webhook、cron、pipeline 和自动验收机制让 Agent 真正进入团队流程。
演讲稿仓库 中不仅包含完整的 Slidev 源码，也保留了不少演讲配套材料，包括原始资料收集和与 AI 协作的完整 trace，值得一并阅读。
从零开始：用 AI 开发一个 iOS 原生 APP 完整指南
我经常会在社交媒体上看到一些零基础的“开发者”通过 AI 构建了自己的产品或服务。尽管我使用 AI 的时间也不短，但我仍然比较困惑：这条路径真的像大家描述的那样有效吗？Zachary Zhang 分享了他完全借助 AI 工具，从零构建并上架一款纯原生 iOS 应用（SwiftUI + Cloudflare 后端）的实战全过程。这篇文章最让我印象深刻的，是他严谨的“工程化管线”：在让 AI 写代码前，必须先生成结构化的 PRD 和 HTML 格式的视觉参考；而在工具选择上，他在项目“从 0 到 1”的冷启动阶段，极力推荐 Claude Code 等终端工具，以便更好地统览全局，一次性构建出合理的多文件项目架构。
或许你和我一样，对于 100% 基于 AI 的开发方式仍存疑惑。但在代码生成越来越廉价的今天，开发者的核心壁垒，正在加速向“需求精准拆解”、“系统架构把控”以及“面向报错的全局调度能力”转移。
工具
Slots：提高自定义 SwiftUI 组件设计效率的宏
将多个视图组合封装成可复用组件，是 SwiftUI 开发中的常见需求，对团队内部开发者或第三方库作者来说更是如此。但当组件包 title、icon、image、action 等多个泛型 View 插槽后，初始化器的组合数量往往会迅速膨胀。Kyle Bashour 创建的 Slots 宏，正是为了解决这类多 slot 组件的样板代码问题。
开发者只需声明组件的 slot 属性，宏便会按组合自动生成所需的初始化器，无需手写大量 init 重载。对于需要支持文本便捷写法的 slot，还可以通过 @Slot(.text) 自动获得 LocalizedStringKey 和 String 版本的初始化方式。 Slots 很适合用于构建设计系统中的 Card、Row、Banner、Toolbar 这类既要支持简单调用、又要保留高度定制能力的组件。
Explore SwiftUI：纯原生组件与修饰符的视觉速查图库
尽管 Apple 官方文档的质量在逐年改善，但对于以声明式和视觉驱动为主的 SwiftUI 来说，官方文档中依然缺乏足够直观的代码与 UI 效果对照，尤其是同一组件在 iOS、macOS 和 visionOS 等多平台上的表现差异。很多时候，开发者为了实现某个特定的 UI 细节，往往会去求助于复杂的第三方库或手写冗长的自定义视图，却忽略了 SwiftUI 本身可能已经提供了绝佳的原生解决方案。Florian 建立的 Explore SwiftUI 站点，正是一个为了解决这一痛点而生的“视觉速查字典”。它摒弃了任何第三方封装，纯粹以展示 Apple 官方内置组件的原生能力为核心。所有的代码示例都被剥离了无关的业务逻辑，保持极简，配以高质量的视觉预览，开发者只需“复制、粘贴、运行”即可直接验证效果。
书籍
SwiftUI Architecture: Patterns and Practices for Building Scalable Applications
这是一本 Mohammad Azam 在不久前出版的新书。它不是一本教你如何使用 VStack 或编写动画的入门书，而是一本纯粹探讨 SwiftUI 应用架构、数据流和现代工程化实践的进阶读物。
书中提供了大量直击生产环境痛点的解决方案，例如：如何构建全局的 Sheets 和 Toasts、如何利用 NavigationPath 设计解耦的多 Tab 编程式路由、以及如何使用 Property Wrapper 编写优雅的表单验证。尤为重要的是，作者并不是要向你灌输某种死板的架构模式，而是旨在帮助你建立真正的声明式心智模型。
或许有人觉得，在 AI 辅助编程盛行的时代，这类探讨架构的书籍还重要吗？借用 Mohammad Azam 在书中的观点：AI 让代码生成变得廉价，但也正因如此，系统架构的设计（边界的划分和状态所有权的明确）变得比以往任何时候都更加重要。