# 100 - For This Journey, and for My Future Self

Published on

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.

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.

Weekly Swift & SwiftUI highlights!