Nil Coalescing Newsletter – May 2026

Hi there,

WWDC is just around the corner! This year, I'm not entirely sure what to expect, but both Matt and I are hoping for a less buggy Xcode, more polished Liquid Glass APIs, and better SwiftUI support on macOS.

We won’t be traveling to Cupertino and will instead be following along from New Zealand. If you are attending in person, enjoy! I'm sure it will be a great week. If not, make sure to register for the online events, including group labs. I already registered for a few and was pleasantly surprised to see several options that work well in the New Zealand time zone, meaning I won't need to wake up at 5am every day during WWDC week.

As usual, I'll be following the SwiftUI additions closely and writing about them on the Nil Coalescing blog. I'll also be speaking at /dev/world on tour in Sydney in July, where I'll be covering the new SwiftUI APIs introduced at WWDC. I'm really looking forward to that!

Apple community recognition

In case you haven't seen yet, Apple published a new community recognition page this month featuring developers, content creators, and community leaders from around the world. You can find it on the Apple Developer website.

I'm really happy and honored to be included. As far as I know, this is the first time Apple has highlighted community members in this way. It meant a lot to be featured alongside so many people whose work I admire.

I'm very grateful for this recognition, and it's a great motivation for me to continue writing, sharing, and contributing to the Swift community.

App development with AI

AI-assisted development continues to improve, and I've been using it more in my own work as well. I've been building a macOS tool for myself and using both Claude and Codex to help me. I've been particularly impressed with Codex recently.

It can speed up development a lot, but it still requires steering, review, and manual adjustments. And sometimes it's still faster to make smaller changes manually rather than trying to explain them to AI.

It has also been interesting to notice some recurring patterns in the mistakes AI coding agents make.

One common issue is hardcoding values for spacing, padding, sizing, and layout. That can be fine for a quick prototype, but it often doesn't scale well across devices and accessibility settings.

In SwiftUI, it's usually better to rely on implicit defaults where possible. Containers such as VStack, HStack, and others come with adaptive default spacing, while modifiers like padding() automatically adjust to context. When values do need to scale dynamically, APIs like ScaledMetric are usually a better fit than hardcoded constants:

struct DetailView: View {
    @ScaledMetric private var spacing = 22

    var body: some View {
        ScrollView {
            VStack(alignment: .leading, spacing: spacing) {
                // subviews
            }
        }
    }
}

I've noticed something similar with SF Symbols as well. AI coding agents often hardcode symbol variants like .fill directly in the image name instead of using the symbolVariant(_:) modifier, or simply letting SwiftUI choose the appropriate variant automatically.

symbolVariant(_:) makes it easier to apply variants dynamically, and if a symbol doesn't support a requested variant, SwiftUI will fall back to the closest available version instead of failing to display a symbol altogether:

Image(systemName: "heart")
    .symbolVariant(isFavorite ? .fill : .none)

I've also noticed a tendency to overuse AppStorage and try to persist everything there. It's worth paying attention to whether the chosen persistence mechanism actually matches the type of data being stored, whether that's files on disk, scene-scoped state, app preferences, or something else.

For my macOS project, it also frequently falls back to AppKit and custom implementations even when SwiftUI already provides APIs for what it's trying to achieve. I've seen this with things like window sizing, toolbar behavior, and other macOS-specific customizations. Sometimes it helps to explicitly point it toward the SwiftUI approach first.

Overall though, the tools are improving quickly. They can be genuinely useful, but still work best when paired with a good understanding of the frameworks involved so we can review, guide, and correct the output when needed.

I've been getting quite a bit of feedback from readers of The SwiftUI Way that it helped them better understand why certain approaches are recommended in SwiftUI, and that they now feel more confident spotting things that don't look quite right. This becomes especially important with AI-assisted development, since coding agents still often suggest implementations that technically work, but don't necessarily align with how SwiftUI is designed to be used.

Blog

Refreshing and animating views using TimelineView in SwiftUI

Build SwiftUI views that update periodically or continuously, without relying on explicit state changes, to create dynamic interfaces and visual effects.

Modern SwiftUI APIs for programmatic scrolling

Master programmatic scroll control in SwiftUI using defaultScrollAnchor(_:), scrollPosition(_:anchor:), and ScrollPosition to configure, drive, and read scroll position in your apps.

A guide to macOS window toolbar styles in SwiftUI

Customize the appearance of the macOS window toolbar in SwiftUI using scene and view modifiers to control its layout, title visibility, and background.

Scheduling and handling background app refresh in SwiftUI

Configure a SwiftUI app to schedule and handle a background fetch task using the Background Tasks framework and the backgroundTask(_:action:) SwiftUI modifier.

Discounts

Every month, I share exclusive, limited-time offers on my books with email newsletter subscribers. Sign up so you don’t miss future newsletter issues and can take advantage of upcoming discounts!