Issue 765

28^th August 2026

Written by Alex Ozun

Comment

I keep in touch with many folks in Apple Developer Community who maintain fairly old iOS apps. And a common topic these days seems to be that everyone’s busy transitioning from UIApplicationDelegate to UISceneDelegate.

Perhaps that shouldn’t come as a big surprise given that Apple made adopting the scene-based lifecycle a hard requirement with the 27 SDKs. But what’s surprising is that I’m sensing an air of excitement about this transition!

You see, scenes were introduced back in 2019 to enable split-screen iPad apps. As great as the new architecture was, not many developers rushed to adopt it straight away. Most conventional iOS apps could safely ignore scenes and carry on with the UIApplicationDelegate + UIScreen.main combo, focusing only on full-screen experiences.

So if the transition felt like an afterthought back then, why the excitement now? Well, as you’ve probably guessed already, it’s the anticipated foldable iPhone! Not only is it expected to have an iPad-shaped main screen that screams to be split in two (quite literally), but also an additional screen altogether!

So are scenes cool and important now? Well, we don’t know how successful the foldable iPhone is going to be, or to what extent iOS apps will be expected to support split/multi-screen experiences. But I think the pressure to support these experiences in earnest might be stronger than some might expect.

First, we aren’t talking about a new niche deployment target like visionOS. Whatever expectations are placed on iOS apps will be felt immediately. Second, phones are real daily drivers, not supplementary devices like iPads or headsets, so user expectations will be higher, and however small the cohort of foldable iPhone users turns out to be, it will be harder to ignore.

For what it’s worth, I share the excitement, and think this presents an opportunity for developers to advocate for a proper uplift of their iOS apps. Luckily, Xcode 27 comes with an agentic skill to help kick off this process!

Alright, I’ll see you all later (in line for the foldable iPhone, perhaps?). Enjoy the rest of this issue!

– Alex Ozun

Sponsored Link

Kodeco has been helping iOS developers learn since 2010, and as the landscape changes, we’re moving with it—helping you make the most of AI, without losing the craft that you love. Our Apple Foundation Models book shipped in July, with an in-depth course on using AI as a development tool coming this autumn. All of Kodeco’s content is included in Kodeco for Teams, which comes out of a training budget rather than your pocket, and provides access for your whole team. We can show you round in 20 minutes. Or take us to your leader.

News

This week Apple introduced two new chips and two new Macs. M6, Apple’s first 2nm process chip, in the new Mac mini. And M5 Ultra, Apple’s most powerful chip, in the new Mac Studio.

As expected, both devices come with higher prices than the previous generations. M6 Mac mini now starts at $899, compared with the $699 launch price of M4 Mac mini, which was later bumped to $799.

Curiously, some customers who ordered an M4 Mac mini before the M6 announcement received a free M6 upgrade. A great move by Apple!

It’s hard to offer any meaningful commentary on matters that affect people’s lives as much as layoffs do, and I appreciate Michael Tsai’s work documenting commentary from people directly affected by them.

In situations like this, first-hand accounts will say far more than my outside analysis ever could.

Code

I honestly consider Embedded Swift to be one of the most ambitious “side quests” of Swift language proper. Bringing an expressive high-level language to the extremely constrained environment of embedded systems is no mean task. In this context, these improvements, which bring dynamic features like existential types, untyped throws, and metatypes, are very impressive indeed.

I like this punchline in Artem’s article: “Quit Xcode. We’re getting started.”

I have to give it to the Xcode team. It’s a pretty bold move to release a headless Xcode MCP, effectively inviting developers, many of whom have already moved their agentic workflows away from the IDE, to quit Xcode once and for all.

Don’t get me wrong, I still enjoy programming in Xcode, and I think opening up parts of the toolchain will only benefit it in the long run (an improved Xcode plug-in architecture next?). That said, if you’re looking to take the good parts of Xcode with you while leaving the UI behind, Artem’s article and the companion Xcode Tools Documentation have you covered.

Mohammad demonstrates a simple and elegant solution for protecting content that requires authentication using a generic RequiresAuthentication SwiftUI container. I think the container approach fits particularly well with SwiftUI’s declarative DSL.

When looking for a solution, Mohammad took inspiration from the React community, which I think is a very smart strategy that Apple developers sometimes overlook. We can forget that communities outside Swift and SwiftUI have been dealing with similar challenges for years and may already have good ideas to borrow.

In fact, when I wrote about a similar topic, I took inspiration from the Rust community.

What’s the takeaway here? I guess…all communities, unite!

When I see an accessibilty article from Bas, I know it’s gonna be a good one. This article is no different, it demonstrates a neat solution for a surprisingly tricky accessibility limitation in SwiftUI.

Apps often want to get their dynamic content from a backend. This can include accessibility content too, which means the number of .accessibilityCustomContent modifiers may vary depending on the data.

SwiftUI’s API doesn’t make it obvious how to apply a dynamic list of .accessibilityCustomContent modifiers, but Bas shows a clever workaround using .accessibilityAddTraits([]) as a no-op starting value and composing the modifiers from there. I wouldn’t be surprised to see this addressed by a proper result-builder API one day.

Tools

Community Showcase is my favourite section of Swift Forums (perhaps because I’m not smart enough for all the compiler discussions 🫠). There’s no shortage of impressive Swift projects announced by community members every other day.

One such announcement that caught my eye was SwiftTUI. Terminal UIs are the new hotness, so it was only a matter of time before someone decided to bring a SwiftUI-like DSL into the terminal.

Daniel Saidi takes us on a short, but nerve-wracking, journey of committing two weeks of valuable Swift Concurrency work to git, losing it all, and then recovering it with the help of AI.

I think this is not only an interesting lesson in how Git stores history, but also a strong use case for AI as a powerful troubleshooting tool. Of course, in situations like this, you could always read the git man page or ask for advice online. But having someone (or rather something) actually inspect your git history for you is what makes AI assistants particularly useful here.

And finally...

Very bad news for Swift! It’s falling out of orbit 🌠