Recently, the temperatures in my city have been breaking historical records. Since the end of July, we’ve been stuck in a stretch of scorching weather lasting more than ten days, with temperatures consistently above 30°C. While that may not sound particularly extreme on its own, paired with humidity exceeding 80%, it leaves behind a lingering sense of heat that never quite goes away—even after spending the entire day in an air-conditioned room set to 25°C.
I’ve found myself turning to tea and coffee to improve how I feel. Interestingly, only a cup of hot tea gives me the satisfying sensation of heat escaping with perspiration, while only an iced coffee brings an immediate, refreshing coolness. I suspect this isn’t simply a matter of physics. More likely, it’s a psychological association shaped by years of habit.
There’s an old Chinese saying: “A calm mind brings a cool body.” I can’t claim to have reached that level of serenity. For now, I still rely on these simple drinks to help me find a bit of balance between warmth and coolness.
Hopefully, this hot and humid summer will return to normal sooner rather than later.
Recent Recommendations
Liquid Glass: A Field Guide to UIKit Compatibility Pitfalls
While Liquid Glass introduces a fresh interaction experience, it also makes UIKit compatibility significantly more complex. The same UI can behave very differently across iOS 18, iOS 26, and iOS 27, while different API combinations and implementation approaches may introduce their own compatibility pitfalls. Drawing from real-world project experience, Megabits summarizes common issues involving Sheets, Navigation, Popovers, Toolbars, and other UIKit components, while also explaining lower-level behaviors such as UIBarButtonItem, CABackdropLayer, and the Scroll Edge Effect, complete with practical solutions and runnable demos.
The Map, Drawn Twice
Apple’s UI rendering stack spans Core Graphics, Core Text, Core Image, Core Animation, and SwiftUI. Although developers work with these frameworks regularly, many never fully understand the distinct responsibility of each layer. In the inaugural issue of Apple UI Insider, Mihaela Mihaljević Jakić presents a conceptual map that traces the journey from Swift code to the final pixels on screen.
Mihaela adopts a fascinating validation approach: every illustration is rendered twice from the exact same scene description—once by a custom clean-room rendering engine, and once by Apple’s Core Graphics—before being compared pixel by pixel. Although nearly half of the pixels differ, the average pixel difference is only around 0.1%, making the two images visually almost indistinguishable. This methodology of understanding system behavior through independent implementations, reproducible experiments, and quantitative measurements is arguably even more compelling than the article itself, and makes the rest of the series especially worth looking forward to.
Finally found a use case for .fixedSize
.fixedSize is one of SwiftUI’s most overlooked modifiers. Many developers associate it only with niche use cases such as preventing text wrapping. Starting from a common layout requirement—making every card inside a horizontal ScrollView match the height of the tallest one—Omar Elsayed demonstrates how .fixedSize provides an elegant solution.
Perhaps
.fixedSizehas never become widely adopted because its name is rather abstract. What exactly is being “fixed”? And what does “size” actually refer to? If you’d like to better understand why it changes layout behavior, you may find my previous series, SwiftUI Layout: The Mystery of Size, helpful. It recreatesfixedSizefrom scratch and breaks down the layout negotiation mechanism behind it.
Two Interesting Explorations of LazyVStack’s Layout Mechanism
On the Apple Developer Forums, alextar04 published two in-depth analyses of LazyVStack. One investigates blank screens and truncated cells during fast scrolling, while the other examines why GeometryReader reports multiple different sizes when used inside a LazyVStack (Thread 2). Beyond providing minimal reproducible examples, the author combines insights from the WWDC 26 Lazy Stack session, SwiftUI logging, and experimental observations to reconstruct how SwiftUICore—including symbol resolution and CA::Transaction validation—might estimate sizes and validate layouts, using these hypotheses to explain the observed behavior.
These two posts also highlight the design differences between
ListandLazyVStackfrom another perspective. The author suggests that, in order to support lazy layout,LazyVStackrelies on size estimation under certain circumstances, which naturally leads to behavior different fromList. This further illustrates why neither container is universally better—their strengths simply apply to different scenarios.
Swift on Windows: A Year of Refinement
A year ago, Swift on Windows had already proven itself capable of supporting real production applications. But being “functional” is not the same as being predictable. Over the past year, The Browser Company, together with Apple and the Swift community, has focused on strengthening the platform’s foundations: rebuilding the runtime build system with modern CMake, introducing the Experimental Swift SDK, formalizing both static and dynamic linking models, and improving runtime selection and distribution across multi-toolchain environments.
What truly advances the maturity of a cross-platform ecosystem is often not a headline-grabbing feature, but the engineering details that are easy to overlook: whether build configurations are reproducible and auditable, whether runtimes can be bound deterministically, whether tools can be distributed independently, and whether CI and developer environments behave consistently. This article offers an excellent overview of how Swift on Windows has evolved over the past year—not through flashy new capabilities, but through continuous refinement of its engineering foundations.
Memo Property: Reusing More Stateful Business Logic for SwiftUI Views
In TaskProperty, Rick Van Voorden demonstrated how custom DynamicProperty types can extract stateful business logic from SwiftUI views while remaining aligned with the view lifecycle. Building on that idea, this article leverages Swift’s latest Parameter Packs (Variadic Generics) to implement a React-like useMemo mechanism for SwiftUI: filtering, sorting, and other expensive computations are recomputed only when explicitly declared dependencies change, while cached results are reused for unrelated view updates.
One Model Object, Multiple Editing Flows: The Missing Layer Between Model and UI
Since the introduction of Observation, many developers have assumed that Combine is gradually becoming less relevant in SwiftUI. In this article, Sergey Tristan presents a different perspective. When multiple independent editing flows share the same model object, with each flow interested in only part of its state, Observation excels at efficiently detecting changes, while Combine is better suited for composing, transforming, and continuously synchronizing data. Rather than replacing one another, the two complement each other.
The article introduces a Projection layer between the model and the UI that transforms one or more continuously changing data sources into reactive representations tailored for different consumers. Whether or not you adopt this architecture, it raises an interesting question: as applications evolve to include increasingly independent yet interconnected editing flows, do we need an abstraction beyond DTOs, ViewModels, and Observation to organize these continuously evolving data flows?
Tools
Apple External Display Support Lookup
External display support across Apple devices can be surprisingly complicated. Capabilities vary by chip generation, hardware model, and even operating system version. Created by Parish Khan, RetinaDesk provides a convenient online lookup tool that lets you quickly check how many external displays a Mac, iPad, or iPhone supports, along with maximum resolution, refresh rate, extended display support, mirroring capabilities, and more.
For developers working with multi-display setups, Stage Manager, or external display features, this is a handy reference that makes it much easier to verify device capabilities without digging through Apple’s technical specifications.
Agent Island
Agent Island is an open-source local monitoring tool created by Tristan Tang. It continuously monitors the local session files generated by Claude Code and Codex, determines their current state in real time, and displays intuitive status updates and notifications through a Dynamic Island-style menu bar interface, so you no longer need to keep watching your terminal. It can also automatically execute predefined follow-up actions once your AI model usage window resets, helping long-running tasks resume seamlessly.
The project follows a local-first design, requiring no cloud services and uploading no conversation data. It also provides token usage statistics, quota reset countdowns, and weekly/monthly usage reports.