
For This Journey, and for My Future Self
In the blink of an eye, this newsletter has reached its 100th issue. Looking back to the first issue in October 2023, I wasn't sure I could keep this going for so long. Yet over these two years, through consistent creation, I've gained so much.
Beyond the readers' attention and encouragement, the greatest reward from writing this newsletter has been reading each article more carefully and understanding the Apple development ecosystem more systematically. Even as AI programming assistants become increasingly prevalent, understanding new frameworks, APIs, and proven solutions remains irreplaceable. While AI models are powerful, they often lack context and systematic knowledge; whether we can provide quality information often determines if AI can "write the right code." Even if we can't remember every detail, having an impression of excellent content often proves invaluable at critical moments.
As AI rapidly advances in content curation, I've questioned whether this manually crafted, selective recommendation format still meets readers' needs. But I quickly remembered that my original intention was to cultivate my own reading and organizing habits, with myself as the primary beneficiary. I believe no tool, however powerful, can replace the value of personal perspective and subjective judgment. Once I understood this, my doubts disappeared.
Issue #100 isn't the end, nor do I intend to set unreachable goals. As long as my energy permits, I'll continue updating the newsletter while maintaining its quality.
Moving forward, I may reduce my blog posting frequency to focus on deep research into specific topics, attempting to share insights in book form—another journey "from 0 to 1".
Thank you to every reader for your attention and companionship. Your encouragement drives me forward.
Previous Issue|Newsletter Archive
If you appreciate my work and want to promote your product to the Swift and iOS developer community, sponsoring my blog & newsletter could be an excellent opportunity for you.
Recent Recommendations
The Cupertino Ghost in the Machine: An Analysis of Xcode’s New AI Assistant
While the AI assistant in Xcode 26 may not match the feature completeness of competitors like Cursor or Windsurf, its deep integration with Apple’s ecosystem gives it a distinct edge. In this article, WeZZard dives into the internal workings of the IDEIntelligenceChat.framework, revealing the assistant’s “personality.” It’s not just a coding tool—it’s almost a messenger of Apple’s development philosophy: persistently encouraging developers to adopt Swift Testing, embrace Swift Concurrency, and prioritize Apple-native technologies. Interestingly, despite its seemingly opinionated nature, the framework remains flexible, with externalized prompt templates and dynamic tool registration mechanisms offering plenty of room for developer exploration.
Building a Design System at Genius Scan
As app codebases grow, maintaining UI consistency and improving component reusability becomes a common challenge for dev teams. John Sundell shares his experience helping Genius Scan build a design system. The key philosophy? Don’t aim for a perfect overhaul—refactor gradually. The team began by addressing repetitive code in list views, creating composable base components like Row, and using SwiftUI’s environment system for flexible configuration. This progressive strategy reduced refactoring costs while allowing the design system to evolve alongside real-world business needs.
@ViewBuilder Usage Explained with Code Examples
One of the reasons SwiftUI view declarations are so concise and readable is thanks to @ViewBuilder, a powerful result builder. In this post, Antoine van der Lee demonstrates three typical use cases for @ViewBuilder: building container views in initializers, simplifying layout logic via view properties, and handling conditional views within methods. A standout example involves a VHStack that adapts to screen size. A deeper understanding of @ViewBuilder’s mechanics and use cases can help developers write cleaner SwiftUI code and design more powerful APIs and components.
Discussion on SwiftData’s ModelActor
The ModelActor macro in SwiftData aims to solve Core Data’s long-standing concurrency issues by wrapping data operations in thread-safe actors. However, as highlighted in this community discussion compiled by Michael Tsai, its behavior is more complex than expected. The biggest concern is that the execution context (main or background thread) is implicitly determined at the time of actor creation—without any clues in the type system or compiler warnings—making its behavior difficult to predict.
While ModelActor still has room for improvement, I appreciate the underlying design. You can explore its internals in my article Concurrent Programming in SwiftData. For those still using Core Data, I’ve also implemented a Core Data version of ModelActor: CoreDataEvolution, which helps you write safer concurrent code.
Creating Amazing Loading Animations with SF Symbols
Creating custom loading animations in SwiftUI—without relying on ProgressView—often involves a fair bit of boilerplate. Daniel Saidi shares a simple but powerful trick: starting with iOS 17, SF Symbols support .symbolEffect(.variableColor). With just a single line like Image(systemName: "ellipsis"), you can create smooth, animated loading indicators. Even better, combining modifiers like .iterative and .hideInactiveLayers lets you fine-tune the style and rhythm. While the example uses the ellipsis, this technique works with any SF Symbol that supports variable color.
Forcing a View Reload in SwiftUI
SwiftUI typically identifies views based on their type, which works well in most cases. But occasionally, you may need to completely rebuild a view without altering the view tree structure. Artem Mirzabekian demonstrates how using the .id(_:) modifier with a UUID can force a full refresh. When the ID changes, SwiftUI destroys the old view and creates a brand new instance—particularly useful in recovery or retry scenarios. That said, the author also warns about the potential downsides, including performance costs and loss of local state. It’s best seen as an “escape hatch,” not a standard solution.
Adapting Toolbar Elements to the Liquid Glass Design System
Apple’s Liquid Glass design system introduces a new two-layer interface hierarchy: the top Liquid Glass layer (for elements like tab bars, toolbars, and menus) and the underlying content layer. The former features semi-transparent, symbol-first visual design, while the latter hosts core content. Matteo Altobello walks through how to build Liquid Glass-style toolbars in SwiftUI and explains new APIs like ToolbarItemGroup and ToolbarSpacer. Notably, the placement parameter for ToolbarItem now not only defines positioning but also automatically applies relevant visual styles.
Tools
SBSObservation: A Swift Observation Framework Compatible with iOS 12
Apple’s Observation framework brings native property-level observation to Swift, significantly improving performance by reducing unnecessary SwiftUI view updates. However, it’s only available on iOS 17 and later. Simon B. Støvring created SBSObservation, a macro-powered reimplementation that works all the way back to iOS 12, bringing modern reactive programming capabilities to UIKit-based apps as well.
The OpenSwiftUI project has also recently released a similar implementation, giving developers more options to bring modern reactivity to older systems.
写给这段旅程,也写给未来的自己
一转眼,周报已经来到了第 100 期。回想 2023 年 10 月第一期时,我并没有把握自己能坚持这么久。但过去两年,通过持续创作,我收获了许多。
除了读者的关注与鼓励,撰写周报最大的收获,是让我更认真地阅读每篇文章,更系统地理解苹果开发生态的变化与脉络。即便在 AI 编程助手日益普及的今天,对新框架、新 API、成熟案例的了解依然不可替代。AI 模型虽强,却常缺乏上下文与系统性;能否提供足够优质的信息,往往决定了 AI 能否“写出对的代码”。哪怕记不清所有细节,只要对优秀内容有印象,也常能在关键时刻派上用场。
随着 AI 在资讯整理领域的快速发展,我也曾质疑:这种手工撰写、数量不多的推荐形式是否还能满足读者需求?但我很快想起,当初写周报的初衷,是培养自己的阅读与整理习惯,而最大的受益人,一直是我自己。我相信,再强大的工具,也无法替代个人视角与主观判断所带来的价值。想明白这一点后,我就不再纠结。
第 100 期不是终点,我也不打算设定遥不可及的目标。在精力允许的范围内,我会继续更新周报,并尽力保持它的质量。
接下来,我可能会降低博客的更新频率,转而围绕某个特定主题做深入研究,并尝试以书籍的形式分享——这是另一个“从 0 到 1”的新挑战。
感谢每一位读者的关注与陪伴。你们的鼓励,是我继续前行的动力。
如果您发现这份周报或我的博客对您有所帮助,可以考虑通过 爱发电,Buy Me a Coffee 支持我的创作。
近期推荐
Xcode AI 助手深度剖析:藏在机器中的苹果之魂 (The Cupertino Ghost in the Machine: An Analysis of Xcode's New AI Assistant)
Xcode 26 的 AI 助手功能虽然在功能全面性上可能不及 Cursor、Windsurf 等竞品,但作为苹果官方打造的开发伙伴,它与苹果生态的深度整合构成了独特优势。WeZZard 在本文中深入剖析了 IDEIntelligenceChat.framework 的内部实现,揭示了这位 AI 助手的“个性”——它不仅是一个编码工具,更像是苹果开发理念的“传道者”:会坚持不懈地建议你升级到 Swift Testing、采用 Swift Concurrency、优先使用苹果技术栈。有趣的是,尽管表现得如此“固执”,但其架构却保留了相当的灵活性——外部化的提示模板与动态工具注册机制,为有探索欲的开发者留出了可操作空间。
SwiftUI 设计系统构建实践 (Building a Design System at Genius Scan)
随着应用代码规模的增长,保持 UI 一致性与提高组件复用性逐渐成为开发团队的共同挑战。John Sundell 分享了他在 Genius Scan 协助构建设计系统的实践经验,核心理念是:无需一步到位,重构可以渐进式完成。团队从解决列表视图中的重复代码入手,构建了可组合的基础组件(如 Row),并通过 SwiftUI 的环境变量实现灵活配置,从而逐步建立起完整的设计系统。这种策略不仅降低了重构成本,也让系统得以在真实业务中不断演进与完善。
深入理解 @ViewBuilder 的使用技巧 (@ViewBuilder Usage Explained with Code Examples)
SwiftUI 视图声明之所以能如此简洁易读,@ViewBuilder
这个 Result Builder 功不可没。Antoine van der Lee 在文中通过实例演示了 @ViewBuilder
的三种典型用法:在初始化器中创建容器视图、作为属性简化布局代码、在方法中实现条件视图逻辑。其中 VHStack 的示例展示了如何利用 @ViewBuilder
构建根据屏幕尺寸自适应的布局组件。深入理解 @ViewBuilder
的机制与应用场景,不仅有助于写出更简洁优雅的 SwiftUI 代码,也能为组件封装与 API 设计带来更多可能性。
关于 SwiftData ModelActor 的讨论
SwiftData 的 ModelActor
宏旨在解决 Core Data 长期存在的并发编程难题,通过将数据操作封装在线程安全的 Actor 中来确保正确性。然而,正如 Michael Tsai 整理的这场社区讨论所揭示的那样,它的实际表现却远比预期复杂。最核心的问题是它会根据创建时的执行上下文隐式决定运行线程(主线程或后台线程),而这点既不会在类型系统中体现,也不会发出编译器警告,导致开发者很难预判其行为。
尽管
ModelActor
的设计仍有改进空间,但我依然欣赏这个宏的实现思路。你可以在《SwiftData 中的并发编程》一文中了解其具体实现机制。对于仍在使用 Core Data 的开发者,我也提供了一个ModelActor
的 Core Data 版本实现:CoreDataEvolution,帮助你编写更安全的并发代码。
用 SF Symbols 创建优雅的加载动画 (Creating amazing loading animations with SF Symbols)
如果不使用 ProgressView
,在 SwiftUI 中实现自定义加载动画通常需要不少样板代码。Daniel Saidi 分享了一个简单而强大的技巧:在 iOS 17+ 系统下,利用 SF Symbols 的 .symbolEffect(.variableColor)
,我们只需一行 Image(systemName: "ellipsis")
的声明,即可创建平滑流畅的加载动画。更妙的是,通过组合 .iterative
、.hideInactiveLayers
等修饰符,还可以灵活创建各种样式与节奏的动画效果。这个技巧不仅适用于省略号图标,也适用于所有支持 variable color 的 SF 符号。
SwiftUI 中的强制视图刷新技巧 (Forcing a View Reload in SwiftUI)
SwiftUI 通常采用基于类型的方式来标识视图,在大多数场景中这运作良好。但有时我们需要在不改变视图树结构的情况下“彻底重建”某个视图。Artem Mirzabekian 介绍了使用 .id(_:)
修饰符配合 UUID 实现强制刷新的技巧。当 id 值改变时,SwiftUI 会销毁旧视图并创建全新实例,这在错误恢复或重试场景中特别有用。不过作者也提醒,这种方法会带来性能开销和状态丢失,应将其视为"逃生舱"而非常规方案。
适配 Liquid Glass 设计系统的工具栏实践 (Adapting Toolbar Elements to the Liquid Glass Design System)
在 Liquid Glass 设计系统中,界面被分为两个层级:顶部浮层(Liquid Glass layer)与底部内容层(underlying content)。前者包含了 tab bars、toolbars、menus 等控制元素,呈现出半透明的玻璃质感并强调符号优先的设计理念,而后者用于承载主要内容。Matteo Altobello 展示了如何在 SwiftUI 中构建符合 Liquid Glass 风格的工具栏,并介绍了 ToolbarItemGroup
、ToolbarSpacer
等新 API。特别值得注意的是,ToolbarItem 的 placement 参数现在不仅决定位置,还会自动应用相应的视觉样式。
工具
SBSObservation:兼容 iOS 12 的观察框架
Observation 框架为 Swift 带来了原生的属性级别观察能力,大幅减少了 SwiftUI 视图的非必要重新计算,提升了应用性能。但其最低要求 iOS 17,限制了许多应用的采用。Simon B. Støvring 开发的 SBSObservation 通过 Swift 宏技术重新实现了这一功能,最大亮点是向下兼容至 iOS 12,让 UIKit 应用也能享受到类似的观察机制。
OpenSwiftUI 项目近期也提供了类似的实现,为开发者提供了更多选择。
求贤
寻找 SwiftUI 工程师(上海,不用996)
你厌倦了 996 的窒息节奏?你渴望把最新 SwiftUI 的奇思妙想真正落地?你想在产品里留下“这行代码是我写的”的骄傲签名? 那么,欢迎来和我们一起做几款“叫好又叫座”的 App。
一、我们要做的事:
全新 iOS / macOS 原生应用,100% SwiftUI 架构
本地数据持久化:Core Data + SwiftData 双轨并行
云端同步:CloudKit + 自建轻量后端(Vapor & AWS)
复杂离线场景、增量同步、数据加密、冲突解决——全套挑战,一次集齐
产品已验证 POC,落地与否不需要担心,只缺一位“灵魂架构师”
二、我们对你的期待
5年以上 Swift/SwiftUI 实战经验,能独立交付完整模块 深入理解 Combine/async-await,熟悉 MVVM、Clean Architecture 熟悉 Core Data 或 Realm,做过真实场景的冲突处理 & 数据迁移,了解 CloudKit、AWS Amplify、Firebase 等任意一种云同步方案,英文文档阅读无障碍,人在上海,可线下咖啡碰头,不用 996 的陆家嘴
三、我们提供的“松弛感”
时间灵活:核心沟通时段 10:00-16:00,其余时间自由安排
压力不大:拒绝倒排需求,拒绝深夜上线,拒绝 PUA
预算友好:(可谈)
如何加入:
把 GitHub / GitLab / 博客链接丢给我们(附上一段你最得意的 SwiftUI 动画代码)
简历不用花哨,PDF 两页以内即可
邮件标题:【SwiftUI 灵魂架构师】+ 你的名字
投递邮箱:novolei@gmail.com
That’s a great achievement!
Congrats 🎉! Posting quality content is hard and it's all starts from learning it yourself and then convert it into shareable format. This polishing never stops.
P.S. For a second converted 0100 from binary to 4 in Substack app )