fatbobman

Weekly Newsletter Progress and Blog Updates | Fatbobman's Swift Weekly #067

• Advanced Navigation
• Git Revision in App
• Text Animation Issue
• Buildable Folders
• Backend with Vapor
• SwiftUI Lists
• Quick Tips of SwiftUI

Integrating AI into the Daily Workflow | Fatbobman's Swift Weekly #066

• Preview Under the Hood
• Adopting Swift 6
• Enums Codable
• Typed Throws
• Debounced Search
• SwiftData CRUD
• Sync with CKSyncEngine
• Swift Runtime

Fatbobman's Swift Weekly #065 | Perspective Shift: Viewing the Developer's Dual Identity Through the Airport Debate

• _VariadicView
• Copilot and SwiftUI
• Keep Menu Bar Alive
• retroactive Keyword
• Reentrancy and Logical Race
• MongoDB in Swift

Fatbobman's Swift Weekly #64 | Happy New Year 2025

• State Issue in Swift 6
• TabView Advancements
• Genmoji in Non-Rich Text
• Dissolve Effect
• Write Swift Like Apple
• Widgets, AppIntents, Siri Shortcuts and WatchKit

In Xcode 16, to improve SwiftUI’s performance under Swift 6 mode, Apple made several adjustments to the SwiftUI framework’s APIs to meet stricter concurrency checks. The most notable change is the comprehensive annotation of the View protocol with @MainActor. While these optimizations generally enhance the developer experience in Swift 6 mode, they also introduce some seemingly anomalous compile-time errors in specific scenarios. This article delves into why certain view modifiers cannot directly use @State properties and provides corresponding solutions.

Fatbobman's Swift Weekly #063 | Breakthroughs in Xenotransplantation of Kidneys

• onAppear Issues
• Validation Patterns in SwiftUI
• SwiftUI Data Flow
• Xcode Library Customization
• Noncopyable
• Sending vs Sendable
• LinkText

onAppear is an extremely crucial lifecycle method in SwiftUI, used to inject key logic when a view is presented. Since view instances may be created and rebuilt frequently, developers often choose to prepare data and perform initialization operations within these methods. In theory, the timing of these lifecycle method calls should be predictable and consistent. However, in certain specific scenarios, onAppear may be called unexpectedly and unnecessarily. This not only can lead to performance overhead but also may cause uncontrollable changes in the application’s state. This article will uncover this easily overlooked SwiftUI behavior trap and provide temporary countermeasures.

Fatbobman's Swift Weekly #062 | Making Swift Stronger, Keeping It Simple

• Model Inheritance in Core Data
• Use of Swift and SwiftUI in iOS 18
• SF Symbol
• Mocking Network Connection in Testing
• Image Playground
• Swift Macro
• MLX Swift

Model inheritance in Core Data is a powerful mechanism.

Dive into this article to uncover the magic of parent, child, and abstract entities, and master class inheritance techniques. This article will also be helpful for SwiftData users.

Fatbobman's Swift Weekly #061 | Two Hours Without a Smartphone

• Concurrency Step-by-Step
• Eight Fun SwiftUI Details
• What Happens When Move File in Git
• any and some
• Simple State Sharing and Persistence in Swift

Fatbobman's Swift Weekly #060 ｜ Older or Outer? Reminiscing About the Pre-Smart Era

• The Anomaly of onChange
• Using AppKit in Catalyst
• Calling Hidden Swift Functions
• Natural Language Framework
• macOS Threading
• Dev Conversations
• Debugging Layouts

SwiftUI provides the onChange modifier, allowing developers to listen for changes in specific values within a view and execute corresponding actions when those values change. Intuitively, as long as a view is part of the currently visible branch of the view tree (active), the corresponding closure should be triggered when the observed value changes. However, in certain navigation scenarios, the onChange modifier seems to become “selectively deaf,” inexplicably remaining silent even when the observed value changes. Is this a carefully designed feature by Apple, or a long-hidden code defect? This article aims to unveil this phenomenon and provide necessary caution to developers.