探讨在 SwiftUI 中利用未公开 API avoidsOrphans 控制文本孤行；分享 Xcode 27 多状态预览、iOS 27 同心圆角等新特性；推荐 Gitwyn、VersionedDoc

WWDC26 为 SwiftUI Toolbar 补上关键旋钮：用优先级决定谁留下，用 overflow 主动折叠，用 pin 钉死必留按钮，滚动时可收起导航栏——系统自适应与显式控制终于能拧到顺手。

写 SwiftData 久了，大概都会碰到同一个别扭的地方。 @Query 很好用——挂在 View 上，列表自动刷新，过滤排序也都顺手。可一旦逻辑稍微复杂一点，比如要根据所有行程算地图镜头范围

Xcode 27 的 `#Preview(arguments:)` 把一组界面状态变成 Canvas 网格，可单独点开对照，告别重复声明和 VStack 堆叠。短标签命名，参数管状态、traits 管

我的项目一直在使用一个开源视频解码库 AetherEngine。最近在使用 Xcode 27 进行测试的时候，发现了一个 Swift Concurrency 相关的错误。

解析 iOS 26/27 下的 UIKit 适配陷阱；逆向剖析 LazyVStack 底层尺寸估算机制；利用 Swift 参数包打造 SwiftUI 版 useMemo；探讨复杂表单下的响应式“投影层

旧名称 638 处、资源前缀 366 处。重命名不是全局替换——桥接头、@objc、Storyboard、持久化、外部配置六条链路，漏一条就残留。

先说说OC里我们是怎么"装"私有 写OC的时候，大家都懂的，所谓的访问控制其实就是个"君子协定"。 说白了，OC的@private更多是编译层面的提示，运行时该访问还是能访问

COW 本质上是在值语义和性能之间做平衡。 这样既保证了值语义的安全性，又避免了每次赋值都立即复制带来的性能损耗。

chat_bottom_container 这个插件我发布也有段时间了，iOS 端一直只配了 CocoaPods，走的是「预编译 xcframework + podspec

Swift 真的被搞得乱七八糟了吗？写了几年之后说点实话 最近跟几个 iOS 同行聊天，不止一个人吐槽："Swift 这几年加的东西太多了，把一个好好的语言搞乱了"。翻社区也能看到类似的声音——有人说

这是适配 iOS 26 的笔记，并非介绍新功能和API。陆续更新，发现一个就写一个🤯🤯🤯🤯🤯🥸🤨😗🙃

很多 OC 开发者转 Swift 后，语法上手快，真正拉开差距的不是语法，而是派发模型：直接派发、vtable witness table 和 objc消息派发

探讨 AI 时代因“任务变大”带来的协作变革。本期技术推荐：Swift 6.2 绑定 Actor 优化蓝牙开发、GitHub Actions 降本实操，以及用 Rust 实现的 Swift 运行时

准备 Swift Concurrency 面试时，我用最小 Demo 验证发现：Task 不是不能取消，而是协作式取消。本文结合日志讲清取消为何“看似失效”及 `detached` 的坑。

本文深度拆解 Swift 并发核心 Task 与 MainActor。通过“账户存款”Demo 的三次演进，揭示 Actor Reentrancy（重入性）导致的逻辑失效坑点。强调内存安全不等于业务原

引言 在构建可复用的 SwiftUI 视图（例如设计系统中的组件库）时，我们面临的核心挑战是：如何让自定义视图的 API 尽可能接近 Apple 原生视图的 API？ 这缩小了自定义视图与原生视图之间

引子 在 WWDC26 中，SwiftData 新增了 @Attribute(.codable) 选项。它的任务很明确： 先纠正一个常见叫法：.codable 并不是 Swift 语言的“关键词”，而

这里每天分享一个 iOS 的新知识，快来关注我吧 前言 一说到 mac 上的抓包工具，大家自然而然的会想到 Charles，作为老牌抓包工具，它功能很全面，也很强大。但是随着系统的不断更新迭代，Cha