Over the past few days, I’ve been reflecting on the evolution of Swift, SwiftUI, and SwiftData throughout this year. My overall impression is that while there weren’t many “flashy” surprises, a palpable sense of maturity has quietly emerged.
Undoubtedly, the centerpiece of Swift this year was the continued refinement of the concurrency programming experience. Although the influx of new options and keywords caused its fair share of teething troubles for developers in the short term, after months of debate and practice, the community is finally beginning to consolidate best practices for this new paradigm. I don’t expect the full establishment and widespread adoption of this paradigm to be a simple or swift process. However, in a year or two, the community’s focus will likely shift from concurrency to cross-platform development, marking a brand-new phase for the language.
For SwiftUI, the focus this year was largely centered on adapting to Liquid Glass. Due to initial implementation hurdles at the system level, the visual results were somewhat underwhelming at first. However, since the release of iOS 26.2, both performance and stability have seen significant improvements. To be honest, I am actually quite pleased that SwiftUI didn’t introduce more “revolutionary” features this year. This has given both the framework team and the developers some much-needed breathing room to truly digest the existing framework. At this stage, resolving legacy issues and optimizing performance is far more meaningful than blindly piling on new features.
The trend of “subtle evolution” is most evident in SwiftData. That said, I believe SwiftData’s performance this year is highly commendable—particularly the fact that many improvements and new features were back-ported to earlier OS versions. I only wish it had been in this state when it was first released three years ago. While SwiftData still lacks some key functionalities, it is now more than capable of handling a significant proportion of projects. With this solid foundation, I look forward to its growth in performance and capability over the coming years.
Personally, I am satisfied with the “report card” delivered by the Swift trio in 2025. I wonder, how do you feel about it?
This is the final issue of the year. I want to express my heartfelt gratitude to all of you for your support and readership throughout the year.
Wishing you all a Happy New Year! Happy Coding!
Event
iOS Conf SG 2026
Next month (January 21–23), iOS Conf SG will take place in Singapore. I’ll be there in person and will be speaking on the topic “Using SwiftUI as a Language”—a talk not just about code, but about a shift in mindset.
If you’ll be nearby or are planning to attend, feel free to come say hi! The organizers have also provided a special discount for my readers: Fatbobman reader-exclusive 10% off link
Recent Recommendations
My Eight Years with CloudKit: From Open Source IceCream to Commercial Apps
I’ve always believed that the so-called Apple ecosystem is shaped by a combination of hardware, software, services, culture, and overall sensibility. Within that ecosystem, CloudKit is undoubtedly a crucial piece. For developers, using CloudKit well not only leads to better user experiences, but also enables innovation at a relatively low cost.
Cai Yue, the creator of IceCream, shares his eight-year journey with CloudKit—from open-sourcing IceCream in 2017 and gaining official recognition from Apple, to applying CloudKit in real-world commercial products such as Music Mate and Setlists. The article takes a deep dive into CloudKit’s core strengths, key limitations, and more advanced usage patterns.
What’s new in Swift: December 2025 Edition
This is a year-end wrap-up article for the Swift community, written by Tim Sneath and Dave Lester. It systematically reviews the major developments across the Swift ecosystem in 2025, spanning language features, platform expansion, and community growth.
The article not only summarizes how Swift 6.2 lowers the barrier to entry for concurrency through more approachable defaults—while continuing to advance C++ interoperability and memory safety—but also highlights sustained investments across Android, WASM, Windows, BSD, embedded systems, and AWS. Together, these efforts reinforce a clear signal: Swift is no longer a language focused solely on Apple platforms.
You may not agree with every change, but in the first year after entering its second decade, Swift has undeniably delivered a solid and substantial body of work.
My PM insisted we switch to SwiftUI for a massive legacy app rewrite. The result is exactly what you’d expect
I came across this post on Reddit a few days ago. The author complains about their PM’s decision to adopt SwiftUI too casually, arguing that it is ill-suited for rewriting a seven-year-old app. I don’t fully agree or disagree with that take—but what really surprised me was the direction of the comments. The overwhelming majority firmly sided with SwiftUI.
Many developers argued that:
- SwiftUI itself is already mature enough; the real issues lie in how it’s implemented
- Migration should be incremental, not a big-bang rewrite
- SwiftUI’s weak spots can be avoided—for example, by keeping UIKit navigation and migrating only the view layer
- Multiple large-scale projects (with over 10 years of history) have already completed successful migrations
This discussion highlights a reality I didn’t quite expect: SwiftUI adoption in production environments is far more widespread than many assume, and developer confidence in SwiftUI is clearly established. By the end of 2025, the claim that “SwiftUI isn’t ready for serious work” may no longer hold up.
As a strong advocate of SwiftUI, I both enjoy working with the framework and remain fully aware that it still has a long road ahead. If you’re still unsure whether SwiftUI is worth investing in, you might want to check out an article I wrote last year, “Common Misconceptions About SwiftUI”. Many of the misconceptions discussed there were echoed—and challenged—in this Reddit discussion.
Non-Sendable First Design
With the arrival of the Swift 6 era, many developers have developed a habit: either make types conform to Sendable, or wrap them in @MainActor or an actor. In this article, Matt Massicotte proposes a highly thought-provoking philosophy: “Non-Sendable First Design.”
The key idea lies in rethinking “isolation.” Isolation is, at its core, a constraint. When a type is marked as @MainActor, it effectively loses the freedom to be accessed synchronously outside of UI contexts. By contrast, a non-isolated, non-Sendable plain type can be far more flexible—it can be owned by any actor and accessed synchronously within that context, while also conforming easily to basic protocols like Equatable, without the complexity of crossing isolation boundaries.
With the introduction of NonisolatedNonsendingByDefault in Swift, this “non-Sendable first” approach is no longer awkward or cumbersome. Instead, its advantages are becoming increasingly apparent: clearer semantics and lower architectural overhead achieved with less isolation. While it won’t fit every scenario, in Swift 6 and beyond it’s a “subtractive” design approach well worth serious consideration.
Resolving Swift Packages faster With Registry from Tuist
Traditional Swift Package Manager dependency resolution is based on Git URLs. Xcode needs to clone entire repositories to retrieve version information and source code, which can be extremely time-consuming for projects with many dependencies (such as Firebase). Registry, on the other hand, is an alternative specification defined by Apple: it downloads archived artifacts for specific versions directly via package identifiers (IDs), bypassing the heavy Git operations.
Tuist recently announced that its Swift Package Registry is now open to all developers. The biggest change is that you no longer need to log in or create a Tuist account to use it.
Lee Young-jun tested the feature and found that dependency resolution (installation) time was reduced to about 35% of the original. However, project generation and build phases didn’t see the same gains, and in some cases even became slightly slower. In GitHub Actions, when combined with caching, dependency installation time for subsequent builds dropped from 53 seconds to 11 seconds—showing that the primary benefits are in CI environments.
Overall, Tuist Registry isn’t a “full pipeline accelerator,” but rather a targeted optimization focused on dependency resolution and cache friendliness. If your project has many dependencies and high CI costs, it’s well worth trying.
iOS Timer vs DispatchSourceTimer｜Safe Usage with Finite State Machine & Design Patterns
For many developers, the most frustrating aspect of working with DispatchSourceTimer is its “fragile” state model: even a slight mistake in call order can lead to crashes. In this article, ZhgChgLi proposes an engineering-focused solution to this highly sensitive state management problem. The article carefully outlines five common crash scenarios (such as calling resume repeatedly or releasing a timer while it’s suspended), and demonstrates how to use a finite state machine (FSM) to encapsulate operations, blocking illegal calls at the logic level while ensuring thread safety through a private serial queue.
This is a hands-on case study that guides readers from “writing code” to “designing systems.” It not only explains how to correctly use GCD timers, but also shows how design patterns can turn a “dangerous” low-level API into a clear, safe, and maintainable industrial-grade component. In an era where Swift Concurrency is becoming the norm, understanding—and elegantly wrapping—these low-level GCD tools remains a core skill for senior iOS developers.
Tools
ml-sharp: Turn Photos into 3D Scenes in Seconds
Apple open-sourced SHARP (Sharp Monocular View Synthesis) last week—an AI model capable of converting a single 2D photo into a 3D scene in under one second (model size: 2.8 GB). Compared to previous state-of-the-art models, it improves visual quality by 25–34% and achieves a 1000× speedup.
The community widely believes SHARP could power future spatial photo features. Today, Spatial Scenes in iOS 26 rely on the Neural Engine for depth reconstruction, whereas SHARP uses the more advanced 3D Gaussian Splatting technique, resulting in significantly higher quality.
The model supports CPU, CUDA, and MPS execution, and developers have already successfully run it on M1, M2, and M3 Macs. The output .ply files are compatible with various 3DGS viewers, and Vision Pro users can view the results directly via Metal Splatter (demo).
While Apple may not always stand out in general-purpose language models, its vertically focused AI models—deeply integrated with hardware and driven by clear application scenarios—continue to demonstrate strong competitiveness.
MaterialView: Breaking the Limits of NSVisualEffectView
Oskar Groth (creator of Sensei) has open-sourced MaterialView, a highly customizable material blur view that goes beyond the limitations of NSVisualEffectView. By reverse-engineering the implementation behind Control Center, Oskar achieved full control over blur radius, saturation, brightness, and tint, and documented the process in a detailed technical article.
Unlike system materials, which only allow you to “pick a type,” MaterialView fully parameterizes the blur effect. Developers can precisely control blur radius, saturation, brightness, tint color, and blend modes, while also supporting active / inactive / emphasized / accessibility states. This makes it an excellent fit for sidebars, floating panels, and utility windows where visual consistency is critical.
The library supports both SwiftUI and AppKit, and includes a demo app with real-time parameter tuning to quickly explore different material configurations.
Note: MaterialView relies on some undocumented Core Animation capabilities (such as
CABackdropLayerandCAFilter). While these APIs have been stable for years, there is still a potential risk of change in future macOS releases.
