Issue 757

3^rd July 2026

Written by Alex Ozun

Comment

Hello, iOS Dev Weekly readers 👋

Since I’m a new face in your inbox, I’ll start this issue by introducing myself.

I’m Alex Ozun, a Staff iOS Engineer at American Express, based in London.

Some of you may already know me from my articles and conference talks, where I usually explore lesser-known parts of Swift that let us express ideas more precisely, often by going back to first principles.

I’m excited to be a small part of this legendary newsletter, and I hope I can bring my voice to the mix by featuring the kind of articles I’m naturally drawn to: ones that start by exploring a new API, release note, bug, or implementation detail, then use it to reveal a broader insight.

Conveniently, the week after WWDC is full of exactly that kind of material.

The big WWDC announcements are behind us, but the more interesting part is what happens next: Swift 6.3.3 shipped, Swift 6.4 and the v27 SDKs are in people’s hands through the Xcode 27 betas, and library maintainers are already working through compatibility fixes.

I always like observing this part of the cycle, when toolchains meet real projects and the community starts adapting to what changed.

This week also showed that Apple has to adapt, too, though in a less welcome way: Apple hardware is getting more expensive as memory costs rise. That matters to developers in a very direct way, especially as more of us experiment with local models and start looking at high-RAM Macs as daily drivers.

Now, enjoy the rest of the issue 🫡

– Alex Ozun

Sponsored Link

SwiftCon is coming to Berlin as part of next.app devCon, the largest gathering of mobile app developers. We’re extending the CFP until Sunday and are welcoming iOS builders who go beyond tutorials: SwiftUI in production, architecture decisions, performance wins, and hard trade-offs. If it shipped, it belongs here. Submit your talk today.

News

EveryMac is 30 years old, which feels worth noting for more than nostalgia. Apple hardware history is full of awkward model names, quiet revisions, confusing identifiers, and support edge cases, and EveryMac has remained one of the best places to untangle them. Not many web resources survive for three decades and still feel useful.

Code

I’ve always found that the best way to learn how something works is by rebuilding it yourself, and Mihaela takes this approach a long way with a from-scratch SwiftUI engine re-implementation. And while it’s not the first time I’ve seen someone replicate a SwiftUI engine, the new and fascinating part for me is the Oracle technique demonstrated in this article: proving the replica is accurate by comparing it against real SwiftUI with a battery of differential tests.

I appreciate articles that turn small findings into deeper insights, and this one from Fatbobman does exactly that. It looks into two SwiftUI animation bugs where the fix was less about a neat API trick and more about understanding how SwiftUI sees your view tree. One case moves animation closer to the view with .animation(_:value:) and an Animatable completion observer. The other is a reminder that even changing ?: to if/else can matter when structural identity, List, and OS-specific behaviour collide.

For the longest time, SwiftUI drag-to-reorder meant reaching for List or custom gesture code. Sagar Unagar looks at iOS 27’s new .reorderable() and .reorderContainer(for:) modifiers, which bring native reordering to stacks, lazy stacks, grids, and custom layouts. The new API keeps state changes in your hands via a ReorderDifference, making it useful for components like dashboards, photo grids, and Shortcuts-style interfaces.

Building a design system always presents interesting challenges, but things get especially interesting in mature projects where UIKit and SwiftUI need to coexist. Anton looks at one deceptively simple use case: dynamic colors. Unlike fonts, colors often need to react to trait changes like light and dark mode, and the way UIKit and SwiftUI resolve them is different enough to trip up a shared design system. A useful reminder that migration work is not just about replacing views, but about making the primitives underneath them behave correctly everywhere.

Tools

Joe starts with the challenges he hit while using a coding agent to solve a year-old subscription bug, then makes a practical case for better app logging. Broadcast is the result: a Swift logging library shaped around the idea that agents are far more useful when they can inspect what actually happened at runtime, not just reason over source code.

And finally...

It turns out the answer to “Can it run Swift?” can be “Yes (kinda)”, even if “it” is a 1 MHz Apple II from 1977 🤯.