Easy-to-use animation has always been one of SwiftUI's defining features. But the nature of a declarative framework is a double-edged sword: once an animation misbehaves, tracking down the cause is often trickier than in an imperative framework. This post records two SwiftUI animation bugs I ran into over the past two weeks, along with how I tracked each of them down.
Starting with WWDC 26, when an iPhone app is mirrored to a Mac through iPhone Mirroring, its window can be freely resized. At the same time, iPhone-only apps running on iPad will also enter a resizable environment. Even without updating a physical device to a beta system, developers can already experience this change through Xcode 27 previews or the iOS 27 simulation environment in Device Hub.
The introduction of the Observation framework has refined SwiftUI’s state reactivity from the object level down to the property level, significantly reducing many unnecessary view computations caused by coarse-grained observation. I recently explored and implemented Observation support in Core Data Evolution, giving `NSManagedObject` property-level precise observation capabilities. This article discusses the motivation behind this feature, how to use it, its implementation approach, the engineering challenges involved, and some of the trade-offs made during development.
The declarative expression of animation is one of SwiftUI's core strengths. But in some scenarios the result isn't always as smooth as we'd hope. A typical example: when the content height inside a `List` row changes dynamically — a subtitle going from empty to non-empty, or text changing its line count after an update — the system's built-in layout engine often fails to produce a continuous transition. Instead we get visible height jumps, flicker, or even clipping anomalies. This article starts from that phenomenon, peels back the causes layer by layer, and gives a solution built entirely on SwiftUI's native primitives. Along the way it revisits a few key constraints in SwiftUI's layout machinery.
In my previous article, I discussed the current reality of Core Data in today's projects: it hasn't disappeared, and it still has unique value, but the disconnect between it and modern Swift projects is becoming increasingly apparent. In this article, I will introduce my experimental project Core Data Evolution, exploring whether we can make Core Data continue to exist in modern Swift projects in a more natural way?
Core Data remains widely used in 2026, but its mismatch with modern Swift concurrency, type safety, and code expression is growing. This article outlines the three core pain points and explores what modernization might look like without abandoning Core Data.
This post documents a recent debugging journey: starting from a test failure, tracing all the way down to the Core Data SDK interface, and ultimately discovering that the key change had nothing to do with the Swift compiler itself — it was how NSManagedObjectContext is imported into Swift that had changed.
Unexpectedly, Apple has directly provided support for Claude Code/Codex in Xcode 26.3. With this update, developers can finally use native AI Agents elegantly within Xcode. Over the past two days, I’ve conducted a series of experiments with this new version, including configuring MCP and writing an adaptive `CLAUDE.md`. This article uses Claude Code as an example to share some tips that go beyond the official documentation.