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?
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.