Issue 767

11^th September 2026

Written by Juan Marin and Alex Ozun

Comment

To celebrate the launch of iPhone Duo, we have an editorial Duo today: Juan and Alex.

Wednesday’s keynote was John Ternus’s first since taking over from Tim Cook, and it was a hardware engineer’s keynote. Hinges with a hundred parts, a vapour chamber three times the size of last year’s, a heart sensor validated on a thousand people. I found that oddly reassuring. It’s been a while since an Apple event spent that long on how a thing is made.

The trouble with beautiful devices is that they arrive with homework, and the homework is always ours. We’ve been through this four times now. The iPhone 5 got taller, and a year’s worth of apps had black bars. Then the iPhone 6 and 6 Plus arrived with wider screens, exposing every layout that assumed an iPhone was 320 points wide. iPad got Split View, then Stage Manager, and apps that had treated the screen as a fixed rectangle had to adapt all over again. Each time, Apple had told us years ahead what to do to prepare. Each time, most of us did it afterwards.

iPhone Duo is the fifth homework assignment like that, and the biggest one yet. Ternus saved it for the end: $1,999, October 23rd, and an inner display that is regular in both size classes while still calling itself a phone.

Louie Mantia asked a fair question on Wednesday: Vision Pro was opt-in, so why is this being forced on every iPhone app? Because the work was never optional. Apple has been asking us to use size classes instead of screen bounds since 2014, and a folding phone is simply the first device that collects on that debt. Steve Troughton-Smith shares a similar sentiment: this feels like a whole new platform with barely a month’s lead time. The SDK you’d build against is still in beta and isn’t due until later this month. The deadline seems tight, but the work was always owed. Apple under Ternus wants to be judged on devices again. Good. That only works if our side does the homework.

I’ve spent years telling teams that UIScreen.main.bounds is a bug waiting for a device, and the device has finally turned up. Alex has been watching the same thing arrive from the scene side, and has the homework sheet below.

– Juan Marin

Two weeks ago, in Issue #765, I shared my thoughts on the adoption of the scene-based lifecycle leading up to the foldable iPhone launch.

I wondered then to what extent iOS apps would be expected to support split- and multi-screen experiences. Well, we don’t have to wonder anymore, as new Tech Talks have dropped, covering iPhone Duo’s design language. Prepare your app for iPhone Duo directly answers my question. The good news is that even legacy iOS apps will continue to work on Duo, but they’ll be presented inside a phone-sized window, similar to the compatibility mode we’ve seen with iPhone-only apps running on iPad.

Continuing with Juan’s “homework” analogy, to get a passing grade, developers simply need to rebuild their apps under the 27.0 or 27.1 SDKs, which implies they have at least adopted UISceneDelegate. This allows apps to present content across all iPhone Duo screens in their native aspect ratios. To get the top grades, however, developers will have to put in a lot more work. My takeaway from the Tech Talks is that there are two main areas for improvement:

1. Audit your bars. Toolbars, tab bars, and status bars can now compete for vertical space within a shared bar region, so we need to decide how elements are grouped and which should take priority when the shared space runs out.
2. Handle reserved regions. Apple designers talk about adopting Displacement Patterns, where content and controls are repositioned to avoid areas around the folding hinge and under-screen cameras.

This roughly summarises the upfront effort required to support iPhone Duo, but I can also see how ongoing maintenance and testing could get more involved. Many teams rely on techniques like snapshot testing to make sure their UIs don’t regress.

iPhone Duo brings multiple new poses, with vertical bars appearing on either side of the content and reserved regions becoming active and inactive depending on the pose. Can these poses be programmatically simulated during snapshot testing? Does that mean developers need to test all these variations? The community will have to figure this out over the coming weeks.

Xcode 27.1 is coming with a new app-resizability skill, which should help smooth the adoption journey. But given how many of these decisions revolve around look-and-feel rather than mechanical API adoption, I still see a lot of human involvement being required. I recommend joining iPhone Duo Group Lab next week.

Despite all these challenges, I couldn’t be more excited about this opportunity to uplift our iPhone apps and get them even closer to iPadOS and macOS compatibility.

So, as kids say these days, it’s time to lock in!

– Alex Ozun

Sponsored Link

The swiftCon agenda is live. 75 sessions, 70 speakers, 3 stages — three days of deep Swift talks, hands-on workshops, and real-world insights from the community.

Only 72 Hours left for regular pricing. Grab your exclusive 25% off with code LASTCALL_IOSDEVWEEKLY at the next.app devCon home page or use this registration link. Don’t wait — prices go up soon.

News

Six years after going all in on React Native, Shopify is rebuilding every mobile app in Swift and Kotlin, and Mustafa Ali is careful to say why without trashing the thing he’s leaving. The apps were fast. The framework was fine. What changed is that coding agents made building a feature twice cheap enough that the case for sharing one implementation stopped winning. The Shop app went first: six engineers, twelve weeks, a greenfield rewrite rather than a brownfield crawl, and the numbers they’re publishing are startup 23% faster on iOS, crash sessions down tenfold, and an iOS binary one megabyte larger than before.

The part worth studying is the process. Agents don’t one-shot a screen; a checkpoint loop makes each slice prove itself with tests, a visual match and two adversarial reviewers before a human commits it. If you’re pointing agents at a port of any kind, that’s the shape to copy.

The talks give the rules; nobody had given the numbers. Blake Crosley worked them out from App Store Connect’s screenshot specifications and the result reframes the device. The inner display is 669 by 951 points, an aspect ratio of 1.42, within half a percent of root two, the ratio of A-series paper. Fold it and you get two panels of the same shape. For 16:9 video that costs a fifth of the screen to letterboxing. For documents, feeds and two-pane layouts it’s the shape paper was invented for.

He’s also the first to lay the calendar out plainly: iOS 27 on Monday, iPhone 18 Pro on the 18th, the 27.1 beta later this month, the Duo on the 23rd of October. It’s a 6,000-word post with an FAQ bolted on, so skim the scaffolding. The arithmetic and the six-week list are the parts that earn it.

Code

The insight that makes this work is that Bundle already does the hard part. Locale fallback, region variants, stringsdict plurals: all of it comes free if you download a directory shaped like a resource bundle and pass it to NSLocalizedString instead of the embedded one. Alberto De Bortoli built exactly that for the Just Eat Takeaway app, and the integration is one line per module with ?? doing the entire fallback.

The engineering is in what surrounds it. Per-module archives swapped in with replaceItemAt, so a crash mid-download never leaves half a bundle on disk. A manifest that’s only persisted when every module succeeded, which makes retry free. Fetch on foreground, apply on cold launch, because strings changing under someone’s thumb is a bug, not a feature. And one sharp edge stated plainly: a key must never be reused with a different meaning.

I have written Set(dictionary.keys) more times than I’d like to count, usually to check whether two payloads have the same shape, and every time it felt like a workaround. In Swift 6.4 it is one. Artem has a short, precise tour of the new Hashable conformances: Dictionary.Keys, CollectionOfOne and EmptyCollection from SE-0514, and UnownedTaskExecutor from SE-0523.

None of this is dramatic and that’s rather the point. The post is good on the reasoning, especially why Dictionary.Values was left out, and it closes with the one warning that matters if you do use an executor as a key: the reference is unowned, so the dictionary won’t keep the executor alive, and the owner still has to clean up.

Siri AI arrives on Monday, and this is the most useful App Intents post I’ve read for it because it’s written from a shipping app rather than the docs. Emre Degirmenci takes Walk Mate from “Spotlight can find a favourite” to “Siri can open it by voice”, and the steps are the ones you’ll actually need: @Property so Siri may read the name aloud, an EntityStringQuery for type-ahead in Shortcuts, IndexedEntityQuery so iOS 27 can ask you to reindex, and updateAppShortcutParameters() after every rename so the phrases stay true.

The two decisions I’d copy are the smaller ones. He exports a PlaceDescriptor for the trailhead instead of pretending a private loop is a Maps place, and he donates the open intent after it succeeds rather than on every list render.

Tools

I’ve been through the same arc Roland describes: a CLAUDE.md that started as principles and grew into a dumping ground for every bad afternoon. Roland Leth got out of it by sorting things into rules, skills and hooks by what they’re for, and the piece is the clearest explanation I’ve read of where each belongs. Rules load per directory. Skills are for sequences you keep re-explaining. Hooks are for the things you can’t afford to have forgotten.

Read the hooks section twice. The git commit -F trick, where an exempted command can read a signing key the sandbox otherwise denies, is the kind of hole you only find by thinking like the thing you’re constraining. His hook denies it, and if the hook itself errors, the tool asks rather than proceeds.

macOS Development

On macOS Tahoe and Golden Gate, the login keychain is encrypted with a key that lives in the Secure Enclave, which means the file cannot be unlocked on any other Mac, even with your password. Jeff Johnson picked this up from Rich Trouton, tested it across Sequoia, Tahoe and Golden Gate volumes, and puts the consequence plainly: you no longer have a backup of your login keychain, and Apple didn’t announce the change.

Time Machine restores to the same Mac still work. Custom keychains created in Keychain Access are unaffected and can move between machines, which is his workaround. Before you decide it doesn’t apply to you, open Keychain Access and look: Chrome passwords, mail accounts and, if Xcode put it there, your Developer ID signing certificate are all in the login keychain.

And finally...

Somewhere in the middle of the keynote, Greg Pierce summed up every SwiftUI developer’s afternoon in one line of code: ToolbarItem(placement: .somewhereDepends).