Hi folks,
This week has a very “dualistic” feel to it. Xcode project files are changing shape, Swift concurrency is still finding sharp edges in old Objective-C callback APIs, and iPhone Duo keeps turning familiar SwiftUI layouts sideways - sometimes literally.
The thread is control, really. Small moves. Less drama. Better apps.
Have fun!
Articles
Swift
Swift 6 Gave Me Zero Warnings, but Two Objective-C Callbacks Still Crashed at Runtime
Swift 6 strict concurrency can still leave a nasty hole when Objective-C APIs take plain callback blocks and run them on queues the Swift type system cannot see. The crashes here come from BGTaskScheduler and PhotoKit callbacks created inside @MainActor code, then invoked off the main actor before the Task { @MainActor in ... } body even gets a chance to run. That is the kind of bug that looks “obviously handled” in review, which is why the concrete grep targets and testing advice are useful. If our apps bridge into older Apple frameworks — and of course they do — this is worth reading with crash logs open.
Xcode
From pbxproj to xcproj: Xcode Project Configuration Gets a JSON Format
Xcode 27.2’s new project.xcproj format is one of those boring-looking changes that could save real pain in our codebase. The old pbxproj file has always been a merge-conflict magnet, full of flat object tables and IDs nobody wants to review. JSON alone is not the win here; the nicer part is that Apple reshaped the project graph so file membership and build settings read closer to what we actually changed. Not a revolution, no, but for teams still touching .xcodeproj directly — and for coding agents trying not to mangle it — this feels like overdue cleanup.
UI/UX
Configuring SwiftUI toolbars on iPhone Duo
SwiftUI’s iPhone Duo toolbar story is getting more specific now: vertical bars, item axis behavior, compression priorities, and an escape hatch when the vertical layout makes a screen worse. The useful bit is not “new modifiers exist”, it is the judgment around when to let the system adapt and when to pin an item to horizontal space. axisBehavior(_:), toolbarVerticalEdge, and toolbarVerticalCompressionBehavior(_:) give us just enough control without turning every toolbar into a custom layout project. I like this because it keeps our apps in the system’s lane, but still lets us say, “no, that slider really should not be crammed into the side bar.”
Sheets and fold avoidance on iPhone Duo
Sheets on iPhone Duo mostly do the right thing, but “mostly” is where the product polish lives. Across closed, open, and partially folded poses, the system moves sheet controls, centers presentations, or slides UI away from the fold so actions do not land in awkward places. The practical takeaway is simple: start with standard sheets and system components, then disable vertical toolbar behavior for the cases where one lonely Close button steals too much width. It is a good reminder that Duo adaptation is less about inventing a new layout religion and more about checking the weird poses before our users do.
ArrangementView, Toolbar Behaviors and more! Code Snippet + Demo Video!
A quick tour through the iOS 27.1 Duo APIs, with code you can paste into a small demo instead of just staring at documentation. The toolbar pieces line up with Apple’s new vertical bar model — per-item axis behavior, whole-presentation vertical behavior, compression choices, and the toolbarVerticalEdge environment value. The extra wrinkle is ArrangementView, which gives SwiftUI a native way to juggle primary and secondary content through split, overlay, and custom styles. Some of it still feels like we need real devices and real apps to develop taste, but that is exactly why small demos like this help.
Backporting SwiftUI APIs
New SwiftUI APIs arriving in iOS 27.1 are nice, but bumping the whole deployment target just to use toolbarVerticalBehavior is rarely how our apps work. The backport pattern here is intentionally small: wrap the new modifier behind availability checks, either under a .backport namespace or with a ported prefix that deprecates itself once the real API is safe to require. I prefer the deprecation approach because it leaves breadcrumbs for future cleanup, and future cleanup is where these little compatibility shims usually go to die. Use the new Duo behavior now, keep older OS support, and make the compiler remind you when the shim has outlived its usefulness.
AI / ML
Jev for Apple Foundation Models
jev-foundation-models plugs TypeSafe AI’s Jev decision model into Apple’s Foundation Models APIs, which is an interesting fit for cases where we need typed decisions, not another paragraph of generated text. The package maps @Generable structs and enums into fast boolean, choice, and score evaluations, then feeds the result back through LanguageModelSession with confidence metadata. I’m especially glad the README leads with the mobile API-key warning, because shipping secrets in an app binary is still not a clever shortcut, it is just a future incident. For triage, routing, deduping, and other “make a call from structured state” jobs, this is a neat bridge to watch.
Website
iPhone Duo SwiftUI layouts
A visual gallery for iPhone Duo layouts is exactly the kind of reference that saves time when your mental model starts lying to you. Instead of guessing how a NavigationSplitView behaves across portrait, landscape, closed, partially open, and fully open states, you can scan screenshots and compare the variants directly. It is not trying to be a deep essay, and that is fine — sometimes our apps need a quick “what does SwiftUI actually do here?” check before we start adding custom logic. Keep this one nearby when reviewing Duo layout changes.