Weekly note ✏️
The iPhone Duo simulator landed in Xcode 27.1 beta, and suddenly a lot of familiar SwiftUI layout assumptions are getting tested in the same week.
The interesting one? Centered doesn’t always mean centered anymore.
Have you opened the Duo simulator yet, or are you waiting to see whether this actually becomes a real device?
Your Centered Layout Was Never as Stable as You Thought
with Divya Ravi, Technical Editor
Four people picked up the same beta this week and came at it from completely different directions.
Blake Crosley looked at what actually shipped in Xcode 27.1, the two-display simulator, the new Duo APIs, and the things that still aren’t there. Antoine van der Lee put a real SwiftUI layout through the simulator. Mick MacCallum went deep on ArrangementView, including its split and overlay modes. And Xiangyu Sun wrote the piece that stuck with me most: centered layouts, the kind we’ve been shipping for years without thinking twice, stop being centered the moment the device folds.
That’s the interesting part. Not the device itself.
A foldable phone isn’t conceptually that far from an iPad in Split View. Content gets squeezed, resized, or divided into separate regions. We’ve been dealing with versions of this problem for years.
The difference with Duo is that the failure becomes painfully literal.
On an iPad, a bad assumption about available width might leave you with an ugly but usable layout. On Duo, a bad assumption about “the center of the screen” can put a button across a physical seam or leave a modal split between two panels.
That’s not a subtle bug. It’s the kind of thing a designer can spot walking past your desk before QA even files the ticket.
What I keep coming back to after reading all four pieces is that they’re really describing the same discipline from different angles.
Crosley’s piece is about reading a beta carefully, understanding what you can actually test instead of assuming feature parity because an API exists.
Van der Lee’s is about treating new platform APIs as an enhancement to resilient layout code, not a substitute for it.
MacCallum’s is about making split and overlay behavior explicit instead of hoping GeometryReader will somehow figure it out.
And Sun’s piece gets to the underlying problem: “reserved regions” is essentially Apple’s way of acknowledging that a single content plane was always a convenient simplification. Now there’s a name for the places where that simplification breaks down.
None of this is really about foldables.
“The screen” was never actually one thing. It’s just an abstraction we’ve gotten comfortable with.
iPad multitasking chipped away at it. Dynamic Island chipped away at it again. Stage Manager did the same. Duo just makes the boundary physical.
And every time a new form factor arrives, the same two kinds of codebases show up.
There are the ones built around constraints and adaptive containers, where supporting the new shape is mostly a matter of wiring things up.
Then there are the ones where the assumption of a fixed rectangle is buried so deeply that “support the new screen” turns into rewriting half the view hierarchy under a deadline.
You don’t need a Duo roadmap item this quarter to take something from this.
The more useful question is much smaller:
Where in your codebase do you assume there is exactly one visible region, one center point, one continuous canvas?
Not because Duo will necessarily expose it.
It might never.
But the assumption was already fragile. Every new form factor Apple ships is just another way of finding out where we’ve made that assumption.
Hit reply and tell me: have you actually opened the Duo simulator yet, or are you in the “let’s see if this becomes a real SKU first” camp?
I’m genuinely curious which way you’re leaning, especially this close to launch.
Related reading on this week's theme 📚
Four people picked up the same beta this week and came at it from completely different directions.
Xcode 27.1 Beta: Your App in the iPhone Duo Simulator
Blake Crosley walks through what actually shipped in the 27.1 beta, the two-display simulator (466×678 outer, 669×951 inner), the new Duo APIs, and what’s still missing, including StandBy simulation.
📍Level: Intermediate
iPhone Duo Simulator: Testing and optimizing your SwiftUI app
Antoine van der Lee puts ArrangementView and reserved regions through a practical SwiftUI walkthrough. The key takeaway: make your layout resilient first, then treat Duo-specific APIs as an enhancement.
📍Level: Intermediate
Building Fold-Aware Layouts with ArrangementView in SwiftUI
Mick MacCallum goes deeper into ArrangementView’s split and overlay styles, sizing and axis configuration, along with its UIKit counterpart, UIArrangementViewController.
📍Level: Intermediate
iPhone Duo Breaks Centered Layouts: Reserved Regions, Displacement and ArrangementView
Xiangyu Sun looks at what happens when the Duo is folded and a layout’s idea of “center” no longer matches the physical screen. His discussion of reserved regions is a useful way to think about layouts that were built around a single continuous surface.
📍Level: Intermediate
This Week in Those Who Swift 🗞️
The latest across Swift, Apple, AI, and the community.
Swift Around the Web 🌐
Using Swift's 'some' keyword beyond SwiftUI
John Sundell looks past the SwiftUI use case to show how `some` simplifies function parameters, avoids type erasure, and builds cleaner genericAPIs, all while keeping compile-time type resolution.
📍Level: Intermediate
Deployment Target Conditional Compilation
A new Swift Evolution proposal, now in review, that lets code adapt directly to the minimum deployment target instead of relying on runtime #avialable checks alone, a cleaner path for apps supporting multiple OS versions.
📍Level: Advanced
Task Identity
A proposal for a stable `Task.ID` type, so concurrent tasks can be correlated across logs and tracing tools without the overhead of wrapping them just to get an identifier, currently in review, with real debate over misuse-as-a-side-channel concerns.
📍Level: Advanced
Coding 👨💻
Stop Sleeping: Deterministic Tests for Concurrent Swift Code
Michal Raška shows how to use a “test spy” to make unstructured concurrent Swift code deterministic without sprinkling sleep() through your tests. A practical solution to a very real Swift 6 testing problem.
📍Level: Advanced
What minimumScaleFactor trades away in SwiftUI
Mike Salari runs 500 measurements across 100 conditions to show how minimumScaleFactor can quietly undermine visual hierarchy when neighboring labels scale independently.
📍Level: Advanced
Real-World iOS Development
Avi Tsadok's new book (Apress/Springer) on the practices real teams actually use in production, architecture and design patterns, testing, CI/CD, navigation, data persistence, team workflows, and a closing chapter on adapting to the AI era.
📍Level: Intermediate
Apple 🍏
Build for iPhone Duo with new resources
Apple’s official Duo resources, covering the Xcode 27.1 beta, design kits, and optimization workshops, the primary source behind much of this week’s Duo coverage.
AI & Tooling 🤖
Making Xcode and agents share incremental builds
Serg Dort tackles a surprisingly annoying workflow problem: switching between Xcode and AI coding agents can throw away incremental build work. This shows how to get both workflows sharing the same build outputs.
📍Level: Advanced
This Week in Swift x AI
Natasha The Robot rounds up recent Swift and iOS AI developments, from SwiftFairy’s launch and JEV decision models to what “in-app computer use on iPhone Duo” could mean for developers
📍Level: Intermediate
Design 🎨
McKinley: The SF Symbols Editor Apple Never Built
Lou Plummer gives McKinley, a new Mac app for generating and previewing SF Symbols weights and scales, a hands-on test using Apple’s own rendering engine. The review covers both what works and where the app still falls short.
📍Level: Beginner
Tutorials📒
Swipe Actions Beyond Lists in SwiftUI
Gabriel Theodoropoulos walks through swipeActionsContainer, showing how to bring swipe actions to grid layouts rather than limiting them to lists. Clear, practical, and a welcome return after a long rest.
📍Level: Intermediate
SwiftUI Charts: Dynamic Masking
Anton Gubarenko builds a TradingView-style chart where the selected range stays at full opacity while the rest fades back, using layered Swift Charts masking instead of rebuilding the dataset.
📍Level: Intermediate
Video 🎥
This Filename Breaks iOS, And That's Boring Now
Bryce Bostwick digs into a real iOS rendering bug involving filenames such as “highjump.png” and Apple’s IBHashImageName function, then turns it into a broader question: what happens to deep technical writeups when an LLM can solve the bug for you?
📍Level: Intermediate
Community 🤝
Little Memory 2.0: Moving 15 years of memories off my servers
Ivan Tse rebuilt his decade-old journaling app around offline-first storage and iCloud sync, moving sensitive diary data off his own servers. A thoughtful indie-dev story about architecture, privacy, and what happens when you rethink an old product.
📍Level: Intermediate
Shipaton at Week Six: Buildhorn Has Officially Been Submitted to Apple
The latest entry in Darryl Bayliss’s Shipaton devlog follows Buildhorn through App Store submission, including a performance issue caused by AI-generated code in widget syncing.
📍Level: Beginner
Thanks for reading Those Who Swift!
Subscribe for free to receive new posts. 👇