Fatbobman's Swift Weekly #086
Arc, Dia, TCA and SwiftUI
Arc, Dia, TCA and SwiftUI
A few days ago, Josh Miller, CEO of The Browser Company, published an open letter to Arc users, sharing content that the community has been widely interested in, including why the team is transitioning from Arc to Dia, the lessons learned from the Arc project, Dia's design philosophy, why Dia's features weren't integrated into Arc, and Arc's future development plans.
One statement in the letter: "Specifically, sunsetting our use of TCA and SwiftUI to make Dia lightweight, snappy, and responsive," sparked widespread discussion in the Swift developer community. Although a subsequent tweet clarified that Arc used an early, specialized branch of TCA that differed significantly from the officially released version, this topic still deserves deeper consideration from developers.
Arc, as a cross-platform browser developed using Swift, garnered considerable attention when it first launched. While it didn't achieve the expected success in the highly competitive browser market, The Browser Company's contributions to better Swift support for the Windows platform remain commendable. Interestingly, when Arc initially debuted, the official team emphasized that TCA significantly reduced the complexity of cross-platform development, but just a few months later, the team made noticeable changes in their technology choices.
From a technical perspective, Arc's minimum system requirement is macOS Ventura. The choice to use SwiftUI in such a large-scale project is indeed intriguing. After all, SwiftUI only showed notable improvements on the macOS platform in the last two versions, and these improvements were mainly focused on API richness rather than performance enhancements, which still have obvious shortcomings. Objectively speaking, the performance gap between SwiftUI and AppKit on macOS is more pronounced than the gap between SwiftUI and UIKit on iOS. Additionally, since Arc is built on Chromium, it makes one even more curious about the specific performance impact of the SwiftUI and TCA combination.
It's worth noting that SwiftUI and AppKit/UIKit are not in competition, but rather complement each other. For a considerable period, these frameworks will each have their suitable application scenarios. Developers can flexibly choose technical solutions based on specific needs, continuing to use AppKit/UIKit in areas where SwiftUI is not yet mature (such as complex navigation, text editing, high-performance lists, etc.). Reactive frameworks, due to their underlying mechanisms, inevitably have certain performance gaps compared to imperative frameworks. However, with continuous framework optimization and ongoing hardware performance improvements, this difference will gradually be overlooked by both developers and users.
With WWDC 2025 approaching, SwiftUI is about to enter its seventh year. Looking back, compared to UIKit at the same stage of development, SwiftUI still has considerable room for growth in terms of feature completeness, stability, and developer acceptance. Apple officially needs to further use SwiftUI in more first-party applications, validating the feasibility and advantages of this framework as the future mainstream UI technology through actual product performance. Only when we see more of Apple's core applications successfully migrate to SwiftUI and demonstrate excellent performance and user experience will the entire developer community have more confidence to fully embrace this framework.
The Arc team's technology choice changes also remind us that technical decisions should always be based on specific project requirements and constraints. There are no absolutely perfect technical solutions, only the most suitable choices for specific scenarios. For Swift developers, maintaining an open and pragmatic attitude—actively exploring the potential of new technologies while rationally evaluating their maturity, seeking the best balance between functional requirements, development efficiency, and performance—is perhaps the most important approach.
What SwiftUI improvements are you most looking forward to at WWDC 2025?
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
Swift 6 Refactoring in a Camera App - SLIT_STUDIO Development Log
Although Swift 6 has been out for a while, many of Apple’s first-party frameworks are still not fully adapted, which can create hurdles for developers relying on them. Megabits faced such challenges while developing the SLIT_STUDIO camera app — but instead of backing down, he embraced the transition. In this article, he shares how he leveraged actor, GlobalActor, and clearly separated components like Recorder and CaptureManageObject to handle Swift 6's stricter thread safety model, work around AVFoundation’s concurrency issues, and improve both structure and safety without relying on temporary workarounds like @preconcurrency or nonisolated.
Making Your iOS App More Accessible with Dynamic Type
Dynamic Type is a core part of Apple’s accessibility ecosystem, but implementing it well in real-world projects can be trickier than expected. In fact, blindly enabling Dynamic Type everywhere might even harm usability. Shaun explores the common pitfalls (like unscrollable content or constrained horizontal space) and presents practical SwiftUI-based solutions — including clever use of ScrollViewIfNeeded, ViewThatFits, and dynamicTypeSize. He also introduces HOrVStack, a layout helper that reduces repetitive code during adaptation. His key advice: “Support it early,” “Keep it simple,” and “Be pragmatic, not perfectionist.”
Forming an Opinion on SwiftUI Forms
As the name suggests, Form is SwiftUI’s go-to container for building forms — but it’s not always the perfect fit. Danny Bolella breaks down what makes Form great, where it falls short, and when to use alternatives. He compares FormStyle and custom containers through real code examples, summarizing the key trade-offs: native consistency, built-in accessibility, and design auto-updates vs. style limitations, cross-platform inconsistencies, and customization hurdles. His suggestion? Use Form where system consistency matters, and roll your own when brand identity or pixel-level control is a priority.
Microapps Architecture in Swift: Scaling
As modularity becomes more widespread, it’s now common to split large Swift projects into multiple targets using Swift Package Manager. But as the number of modules grows, bundling everything into a single package can lead to maintenance issues — bloated Package.swift files, messy dependencies, and slower builds. In this fifth entry in the Microapps Architecture in Swift series, Majid Jabrayilov suggests adopting a “one feature per package” strategy, breaking each feature into internal modules like Domain, UI, and Service. The result? Clearer architecture and faster builds at scale.
Tips and Tricks for When Using SwiftUI’s ViewBuilder
@ViewBuilder is one of SwiftUI’s foundational tools — yet we often underestimate its power. In this article, John Sundell dives into its hidden potential, showing how it can be used to build flexible APIs for custom components like containers. Learn how to use ViewBuilder for multi-view declarations, layout control, and building SwiftUI-friendly APIs that feel just right.
Swift Enums vs Structs - Picking the Best Tool for the Job
Value types are widely preferred in Swift, especially struct and enum. But when modeling state or configurations, how should you choose? Daniel Saidi compares both types through real-world examples, showing how enums excel at modeling finite, mutually exclusive states with compile-time safety, while structs shine in extensible configurations thanks to defaults, extensions, and dependency injection. A clear, balanced comparison for when you’re stuck deciding between the two.
Billing Grace Period Explained: How It Works and Why It Matters
Have you ever lost access to an app subscription due to a failed payment? Your users might, too. That’s why Apple offers the Billing Grace Period, which lets users temporarily retain premium access while Apple retries their payment. But — it’s not enabled by default. Antoine van der Lee explains how this feature works, how it helps reduce churn, and the exact steps to enable it in App Store Connect.
Swift Static Secrets
In Swift, static is often seen as a way to define class-level constants or utilities — but that’s just the beginning. In this deep-dive, Koti Avula explores lesser-known capabilities of static, including locking behavior in classes, adding shared data to enums, defining type-level requirements in protocols, building caching mechanisms, simplifying test setups, and reducing string-based bugs with static constants for UserDefaults or API paths. A compact guide to getting more out of one small keyword.
Tools
SkyLightWindow – Keep Your View Always on Top
Developed by Lakr, SkyLightWindow is a macOS framework that lets you display any view above all system windows — even fullscreen apps or the lock screen. With SwiftUI support via a simple .moveToSky() modifier, the framework offers transparent backgrounds, multi-display support, and advanced styling. Ideal for building system-level UIs like HUDs, floating toolbars, or developer panels.
⚠️ Note: This library uses private APIs. While it works in the Mac App Store without special entitlements, it may break on future macOS versions.
CIMetalCompilerPlugin – Core Image Metal Shaders in Swift Packages
If you’re writing Core Image filters using Metal, you may find that Swift Package Manager doesn’t support the necessary compile flags. That’s where Weichao Deng’s plugin, CIMetalCompilerPlugin, comes in. It:
✅ Automatically compiles
.metalfiles in yourShadersfolder✅ Bundles them into a usable
metallibfile✅ Lets you load them via
Bundle.modulejust like regular resources✅ Requires no extra frameworks or Xcode setup
In short, this plugin makes it possible to use Core Image + Metal shaders directly within Swift Packages — hassle-free.
Arc、Dia、TCA 与 SwiftUI
几天前，The Browser Company 的 CEO Josh Miller 发表了一封致 Arc 用户的公开信，分享了一些社区广泛关注的内容，包括团队为何从 Arc 转向 Dia、从 Arc 项目中获得的经验教训、Dia 的设计理念、为何未将 Dia 功能整合进 Arc，以及 Arc 的未来发展规划等。
信中一句话：“Specifically, sunsetting our use of TCA and SwiftUI to make Dia lightweight, snappy, and responsive”，在 Swift 开发者社区引起了广泛讨论。尽管随后一条推文澄清 Arc 使用的 TCA 是一个早期的特殊分支，与正式发布的版本存在较大差异，但这个话题仍然值得开发者深入思考。
Arc 作为一款使用 Swift 开发的跨平台浏览器，在推出初期便获得了不少关注。虽然在激烈的浏览器市场竞争中未能取得预期的成功，但 The Browser Company 在推动 Swift 更好地支持 Windows 平台方面的贡献依然值得肯定。有意思的是，在 Arc 最初亮相时，官方曾强调 TCA 显著降低了跨平台开发的复杂度，但仅仅几个月之后，团队在技术选型方面就发生了明显的变化。
从技术角度来看，Arc 的最低系统要求是 macOS Ventura。在这样一个大型项目中选择 SwiftUI 确实令人好奇。毕竟 SwiftUI 直到最近两个版本才在 macOS 平台有较明显的进步，且这些进步主要集中在 API 的丰富程度上，而性能表现仍存在明显短板。客观而言，SwiftUI 与 AppKit 在 macOS 上的性能差距，要比 SwiftUI 与 UIKit 在 iOS 上的差距更为明显。此外，Arc 基于 Chromium 开发，这也让人对 SwiftUI 与 TCA 的组合对性能的具体影响更加感兴趣。
值得一提的是，SwiftUI 与 AppKit/UIKit 并非竞争关系，而更多的是互补关系。在相当长一段时间内，这些框架都会拥有各自适合的应用场景。开发者可以根据具体的需求灵活地选择技术方案，在 SwiftUI 尚未成熟的领域（如复杂导航、文本编辑、高性能列表等）继续使用 AppKit/UIKit。响应式框架受限于其底层机制，相较于命令式框架必然存在一定的性能差距，不过随着框架持续优化和硬件性能不断提升，这种差异会逐渐被开发者和使用者所忽略。
随着 WWDC 2025 的临近，SwiftUI 已即将步入第七个年头。回顾过去，与 UIKit 在相同发展阶段相比，SwiftUI 在功能完整性、稳定性以及开发者接受程度方面依然有不少成长空间。苹果官方有必要在更多第一方应用中进一步使用 SwiftUI，通过实际产品表现来验证这一框架作为未来主流 UI 技术的可行性和优势。只有看到更多苹果核心应用成功迁移到 SwiftUI，并展现出色的性能和用户体验，整个开发者社区才能更有信心地全面拥抱这一框架。
Arc 团队的技术选型变化也提醒我们，技术决策应该始终基于具体的项目需求和约束条件。没有绝对完美的技术方案，只有在特定场景下最适合的选择。对 Swift 开发者而言，保持开放且务实的态度，既积极探索新技术的潜力，也理性评估其成熟度，寻求功能需求、开发效率与性能表现之间的最佳平衡，或许才是最重要的。
WWDC 2025 上，你最期待的 SwiftUI 改进是什么呢？
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
近期推荐
相机类 App Swift 6 重构实战 - SLIT_STUDIO 开发日志
尽管 Swift 6 已发布一段时间，但不少苹果第一方框架仍未完成适配，导致部分依赖这些框架的开发者在迁移过程中遇到阻碍。Megabits 在开发 SLIT_STUDIO 相机 App 时也面临类似挑战，但他选择迎难而上。在本文中他将分享如何通过引入 actor、GlobalActor 以及职责清晰的组件（如 Recorder 和 CaptureManageObject），应对 Swift 6 的线程安全变更，解决 AVFoundation 与 Swift Concurrency 的兼容性问题，同时提升代码结构与安全性，避免依赖 @preconcurrency 和 nonisolated 等临时方案。
让你的 iOS App 更好地支持动态字体 (Making Your iOS App More Accessible with Dynamic Type)
动态字体（Dynamic Type）是苹果生态中辅助功能的核心组成，但在实际项目中对其进行良好支持并没有想象中那样简单。简单粗暴地“全量支持”反而可能让应用的可用性变差。Shaun 深入探讨了动态字体引发的典型问题（如内容无法滚动、水平空间不足等），并给出了 SwiftUI 下的实用解决方案，包括 ScrollViewIfNeeded、ViewThatFits 与 dynamicTypeSize 的巧妙使用。他还封装了一个通用布局组件 HOrVStack，有效避免了动态字体适配中常见的代码重复问题。Shaun 总结了三条极具价值的建议：“尽早支持”、“保持代码简洁”以及“实用优先于完美”。
🪜 如何正确使用 SwiftUI 的 Form (Forming an Opinion on SwiftUI Forms)
顾名思义，Form 是 SwiftUI 中处理表单场景的首选容器，但它并不总能满足所有需求。Danny Bolella 在本文中系统性地拆解了 Form 的特性、局限与适用场景，并通过实际代码对比展示了 FormStyle 与自定义容器在开发体验上的异同。Danny 清晰总结了使用 Form 的优势（如系统一致性、无障碍支持、设计更新“自动跟进”）与潜在问题（如样式限制、跨平台差异、定制难度），并提出了一条实用的中间路径：在追求原生一致性的界面中使用 Form，而在强调品牌风格与像素级控制的界面中，则建议自建容器。
Swift 微应用架构的扩展实践 (Microapps Architecture in Swift: Scaling)
随着越来越多开发者体会到 SPM 带来的模块化优势，项目中将不同功能封装为单独 Target 已成为常态。但当模块数量快速增长时，将所有内容集中在一个 Swift Package 中会逐渐暴露出问题——如 Package.swift 文件臃肿、依赖关系难以管理、Xcode 构建效率下降等。在本文中，Majid Jabrayilov 建议转向“每个功能一个 Package”的策略，每个功能内部再细分为 Domain、UI、Service 等模块，从而实现更清晰的依赖关系与更好的构建性能。本文是其 Microapps Architecture in Swift 系列的第五篇，聚焦如何让这种架构模式在大型项目中顺利扩展。
SwiftUI 中 ViewBuilder 的实用技巧 (Tips and Tricks for When Using SwiftUI’s ViewBuilder)
@ViewBuilder 是 SwiftUI 中至关重要的构建机制之一，但我们在日常开发中往往低估了它的灵活性和潜力。本文中，John Sundell 深入讲解了 ViewBuilder 的实际能力与最佳实践，尤其是在构建自定义组件（如 Container）时，如何通过它实现多视图声明、灵活控制布局，并打造符合 SwiftUI 风格的清晰 API。
Enum vs Struct：Swift 中的类型选择指南 (Swift Enums vs Structs - Picking the Best Tool for the Job)
在 Swift 生态中，值类型通常是开发者的首选，而其中最常用的莫过于 struct 与 enum。在建模应用状态或构建配置系统时，该如何选择？Daniel Saidi 在本文中通过具体示例，深入比较了两者在有限状态管理与可扩展配置表达中的适用场景，并清晰总结了各自的优势与局限。Daniel 指出：枚举适用于有限且互斥的状态建模，具备模式匹配和编译期穷举校验的优势；而结构体则更适合处理风格、样式等可扩展需求，可通过默认值、扩展方法或环境注入实现灵活配置。
详解订阅宽限期：机制与启用理由 (Billing Grace Period Explained: How It Works and Why It Matters)
你是否遇到过因支付失败而导致 App Store 订阅突然中断的情况？想象一下，如果你的应用用户也遇到类似问题，可能就此流失。为此，苹果提供了“Billing Grace Period（宽限期）”机制，允许用户在支付失败后继续享受高级功能，同时后台自动重试付款流程。但这个功能并不会默认启用。在本文中，Antoine van der Lee 详细介绍了 Billing Grace Period 的运作方式、为何它有助于降低用户流失，以及如何在 App Store Connect 中正确配置该功能。
🪜 你可能忽略的 Swift static 技巧 (Swift Static Secrets)
在 Swift 中，static 常被视为“类级别的工具方法或常量”的代名词，但它的能力远不止于此。在这篇文章中，Koti Avula 通过多个实际例子，深入挖掘了 static 在不同上下文中的用途与优势。你将看到它如何用于锁定类行为（与 class 的可重写性对比）、为枚举添加共享配置、在协议中定义类型级别的契约、实现一次性加载和类型缓存、在单元测试中复用测试数据，以及通过静态常量替代“魔法字符串”来增强自动补全与代码安全性。
工具
SkyLightWindow – 让你的视图一键置顶
由 Lakr 开发的 SkyLightWindow 是一款 macOS 框架，可将视图显示在系统所有窗口之上，甚至覆盖全屏应用、浮动窗口甚至锁屏界面，为持久置顶类 UI 提供解决方案。该框架支持 SwiftUI，只需使用 .moveToSky() 修饰符，即可将任意视图移动至系统最顶层空间。它还支持透明背景、多屏适配、自定义样式和手动窗口委托，非常适合用于构建 HUD、悬浮工具栏、辅助调试面板等系统级功能。
⚠️ 注意：该库基于私有 API 实现，不需要特殊沙箱权限，可用于 Mac App Store，但仍存在系统兼容性风险。
CIMetalCompilerPlugin - 用 Swift Package Plugin 构建 Core Image Metal Shaders
如果你在用 Core Image 编写图片处理效果，并希望用 Metal 写自定义着色器，可能会发现一个问题：Swift Package 并不能直接编译这些 Metal 文件，因为它不支持设置必要的编译参数。为了解决这个问题，Weichao Deng 创建了这个插件 —— CIMetalCompilerPlugin。它的作用是：
✅ 自动帮你编译放在
Shaders文件夹里的.metal文件✅ 把它们打包成可以在代码中使用的
metallib文件✅ 你只需要像平时加载资源一样，用
Bundle.module拿到它就能用了✅ 不需要额外建 framework 或手动配置 Xcode，非常适合用 Swift Package 管理项目
简单来说，这个插件让你能在 Swift Package 里安心用 Core Image + Metal 写自定义滤镜，不用再为构建流程发愁。
求贤
寻找 iOS 工程师
Dasein Studio 的所有产品均面向海外市场，现招聘 iOS 工程师，可 100% 远程，时区灵活。
我们希望你具备独立完成 App 的能力，熟悉 Swift / SwiftUI / Combine，或对 ARKit、RealityKit、Metal 等前沿技术有热情并能快速落地。如果拥有全栈背景，会是加分项。欢迎附上 2–3 个作品（上线或 Demo 均可），并提供 GitHub、TestFlight、App Store 或演示链接。
当前项目在实时互动、动画表现和可扩展性方面有较高技术挑战（技术深度不低于 Snapchat / BeReal），适合热爱打磨细节、具备视觉还原力的开发者。你将与有技术背景的创始人并肩推进产品与探索。初期可先试合作两个月，薪资 ≥ 20K RMB/月（全职），具体面议。
📧 联系邮箱：julian.ding@getcha.fm
📄 查看更多信息