\n<\/p>\n
To celebrate the launch of iPhone Duo, we have an editorial Duo today: Juan and Alex.<\/p>\n
Wednesday\u2019s keynote was John Ternus\u2019s first since taking over from Tim Cook, and it was a hardware engineer\u2019s keynote. Hinges with a hundred parts, a vapour chamber three times the size of last year\u2019s, a heart sensor validated on a thousand people. I found that oddly reassuring. It\u2019s been a while since an Apple event spent that long on how a thing is made.<\/p>\n
The trouble with beautiful devices is that they arrive with homework, and the homework is always ours. We\u2019ve been through this four times now. The iPhone 5 got taller, and a year\u2019s 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.<\/p>\n
iPhone Duo<\/a> 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.<\/p>\n Louie Mantia<\/a> 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<\/a> shares a similar sentiment: this feels like a whole new platform with barely a month\u2019s lead time. The SDK you\u2019d build against is still in beta and isn\u2019t 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.<\/p>\n I\u2019ve spent years telling teams that \u2013 Juan Marin<\/p>\n Two weeks ago, in Issue #765<\/a>, I shared my thoughts on the adoption of the scene-based lifecycle leading up to the foldable iPhone launch.<\/p>\n I wondered then to what extent iOS apps would be expected to support split- and multi-screen experiences. Well, we don\u2019t have to wonder anymore, as new Tech Talks<\/a> have dropped, covering iPhone Duo\u2019s design language. Prepare your app for iPhone Duo<\/a> directly answers my question. The good news is that even legacy iOS apps will continue to work on Duo, but they\u2019ll be presented inside a phone-sized window, similar to the compatibility mode we\u2019ve seen with iPhone-only apps running on iPad.<\/p>\n Continuing with Juan\u2019s \u201chomework\u201d 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 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\u2019t regress.<\/p>\n 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.<\/p>\n Xcode 27.1 is coming with a new Despite all these challenges, I couldn\u2019t be more excited about this opportunity to uplift our iPhone apps and get them even closer to iPadOS and macOS compatibility.<\/p>\n So, as kids say these days, it\u2019s time to lock in!<\/p>\n \u2013 Alex Ozun<\/p>\n swiftCon’s Last-Minute Regular Pricing Discount (exclusive)<\/a><\/p>\n The swiftCon<\/a> agenda is live. 75 sessions, 70 speakers, 3 stages<\/strong> \u2014 three days of deep Swift talks, hands-on workshops, and real-world insights from the community.<\/p>\n Only 72 Hours left for regular pricing.<\/strong> Grab your exclusive 25% off<\/strong> with code Native is now the future of mobile at Shopify<\/a><\/p>\n Six years after going all in on React Native, Shopify is rebuilding every mobile app in Swift and Kotlin, and Mustafa Ali<\/a> is careful to say why without trashing the thing he\u2019s 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>, a greenfield rewrite rather than a brownfield crawl, and the numbers they\u2019re publishing are startup 23% faster on iOS, crash sessions down tenfold, and an iOS binary one megabyte larger than before.<\/p>\n The part worth studying is the process. Agents don\u2019t 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\u2019re pointing agents at a port of any kind, that\u2019s the shape to copy.<\/p>\n iPhone Duo for Developers: The 1.42 Problem and the SDK Gap<\/a><\/p>\n The talks give the rules; nobody had given the numbers. Blake Crosley<\/a> worked them out from App Store Connect\u2019s 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\u2019s the shape paper was invented for.<\/p>\n He\u2019s 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\u2019s 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.<\/p>\n In-House Over-the-Air Localizations in a Modular iOS App<\/a><\/p>\n The insight that makes this work is that The engineering is in what surrounds it. Per-module archives swapped in with New Hashable conformances in Swift 6.4<\/a><\/p>\n I have written None of this is dramatic and that\u2019s rather the point. The post is good on the reasoning, especially why Teaching Siri to talk about your favorite walks in Walk Mate<\/a><\/p>\n Siri AI arrives on Monday, and this is the most useful App Intents post I\u2019ve read for it because it\u2019s written from a shipping app rather than the docs. Emre Degirmenci<\/a> takes Walk Mate from \u201cSpotlight can find a favourite\u201d to \u201cSiri can open it by voice\u201d, and the steps are the ones you\u2019ll actually need: The two decisions I\u2019d copy are the smaller ones. He exports a Claude Code rules, hooks and skills, and how I set mine up<\/a><\/p>\n I\u2019ve been through the same arc Roland describes: a Read the hooks section twice. The macOS Tahoe silently sabotaged the login keychain<\/a><\/p>\n 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<\/a> 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\u2019t announce the change.<\/p>\n 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\u2019t 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.<\/p>\nUIScreen.main.bounds<\/code> 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.<\/p>\nUISceneDelegate<\/code>. 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:<\/p>\n\n
app-resizability<\/code> 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<\/a> next week.<\/p>\nLASTCALL_IOSDEVWEEKLY<\/code> at the next.app devCon home page<\/a> or use this registration link<\/a>. Don\u2019t wait \u2014 prices go up soon.<\/p>\nNews<\/h2>\n
Code<\/h2>\n
Bundle<\/code> already does the hard part. Locale fallback, region variants, stringsdict<\/code> plurals: all of it comes free if you download a directory shaped like a resource bundle and pass it to NSLocalizedString<\/code> instead of the embedded one. Alberto De Bortoli<\/a> built exactly that for the Just Eat Takeaway app, and the integration is one line per module with ??<\/code> doing the entire fallback.<\/p>\nreplaceItemAt<\/code>, so a crash mid-download never leaves half a bundle on disk. A manifest that\u2019s only persisted when every module succeeded, which makes retry free. Fetch on foreground, apply on cold launch, because strings changing under someone\u2019s thumb is a bug, not a feature. And one sharp edge stated plainly: a key must never be reused with a different meaning.<\/p>\nSet(dictionary.keys)<\/code> more times than I\u2019d 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<\/a> has a short, precise tour of the new Hashable<\/code> conformances: Dictionary.Keys<\/code>, CollectionOfOne<\/code> and EmptyCollection<\/code> from SE-0514, and UnownedTaskExecutor<\/code> from SE-0523.<\/p>\nDictionary.Values<\/code> 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\u2019t keep the executor alive, and the owner still has to clean up.<\/p>\n@Property<\/code> so Siri may read the name aloud, an EntityStringQuery<\/code> for type-ahead in Shortcuts, IndexedEntityQuery<\/code> so iOS 27 can ask you to reindex, and updateAppShortcutParameters()<\/code> after every rename so the phrases stay true.<\/p>\nPlaceDescriptor<\/code> 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.<\/p>\nCLAUDE.md<\/code> that started as principles and grew into a dumping ground for every bad afternoon. Roland Leth<\/a> got out of it by sorting things into rules, skills and hooks by what they\u2019re for, and the piece is the clearest explanation I\u2019ve read of where each belongs. Rules load per directory. Skills are for sequences you keep re-explaining. Hooks are for the things you can\u2019t afford to have forgotten.<\/p>\ngit commit -F<\/code> 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\u2019re constraining. His hook denies it, and if the hook itself errors, the tool asks rather than proceeds.<\/p>\nmacOS Development<\/h2>\n
And finally…<\/h2>\n