\n<\/p>\n
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\u2019s busy transitioning<\/a> from Perhaps that shouldn\u2019t come as a big surprise given that Apple made adopting the scene-based lifecycle a hard requirement with the 27 SDKs. But what\u2019s surprising is that I\u2019m sensing an air of excitement about this transition!<\/p>\n You see, scenes were introduced<\/a> 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 So if the transition felt like an afterthought back then, why the excitement now? Well, as you\u2019ve probably guessed already, it\u2019s the anticipated foldable iPhone<\/a>! 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!<\/p>\n So are scenes cool and important now? Well, we don\u2019t 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.<\/p>\n First, we aren\u2019t talking about a new niche deployment target like For what it\u2019s 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<\/a> to help kick off this process!<\/p>\n Alright, I\u2019ll see you all later (in line for the foldable iPhone, perhaps?). Enjoy the rest of this issue!<\/p>\n \u2013 Alex Ozun<\/p>\n You\u2019ve been learning iOS with Kodeco for 16 years. Now for your entire team.<\/a><\/p>\n Kodeco has been helping iOS developers learn since 2010, and as the landscape changes, we\u2019re moving with it\u2014helping you make the most of AI, without losing the craft that you love. Our Apple Foundation Models book<\/a> shipped in July, with an in-depth course on using AI as a development tool coming this autumn. All of Kodeco\u2019s content is included in Kodeco for Teams<\/a>, which comes out of a training budget rather than your pocket, and provides access for your whole team. We can show you round<\/a> in 20 minutes. Or take us to your leader.<\/p>\n Apple introduces M6 Mac mini and M5 Ultra Mac Studio<\/a><\/p>\n This week Apple introduced two new chips and two new Macs. M6, Apple\u2019s first 2nm process chip, in the new Mac mini<\/a>. And M5 Ultra, Apple\u2019s most powerful chip, in the new Mac Studio<\/a>.<\/p>\n 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.<\/p>\n Curiously, some customers who ordered an M4 Mac mini before the M6 announcement received a free M6 upgrade<\/a>. A great move by Apple!<\/p>\n Apple Vision Pro and Software Layoffs<\/a><\/p>\n It\u2019s hard to offer any meaningful commentary on matters that affect people\u2019s lives as much as layoffs do, and I appreciate Michael Tsai<\/a>\u2019s work documenting commentary from people directly affected by them.<\/p>\n In situations like this, first-hand accounts will say far more than my outside analysis ever could.<\/p>\n Embedded Swift Improvements Coming in Swift 6.4<\/a><\/p>\n I honestly consider Embedded Swift to be one of the most ambitious \u201cside quests\u201d 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.<\/p>\n Headless Xcode: From Prompt to Simulator with MCP<\/a><\/p>\n I like this punchline in Artem<\/a>\u2019s article: \u201cQuit Xcode. We\u2019re getting started.\u201d<\/p>\n I have to give it to the Xcode team. It\u2019s 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.<\/p>\n Don\u2019t 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\u2019re looking to take the good parts of Xcode with you while leaving the UI behind, Artem\u2019s article and the companion Xcode Tools Documentation<\/a> have you covered.<\/p>\n Protecting SwiftUI Views with Authentication<\/a><\/p>\n Mohammad<\/a> demonstrates a simple and elegant solution for protecting content that requires authentication using a generic 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.<\/p>\n In fact, when I wrote about a similar topic<\/a>, I took inspiration from the Rust community.<\/p>\n What\u2019s the takeaway here? I guess\u2026all communities, unite!<\/p>\n Dynamically Setting Accessibility Content in SwiftUI<\/a><\/p>\n When I see an accessibilty article from Bas<\/a>, I know it\u2019s gonna be a good one. This article is no different, it demonstrates a neat solution for a surprisingly tricky accessibility limitation in SwiftUI.<\/p>\n Apps often want to get their dynamic content from a backend. This can include accessibility content too, which means the number of SwiftUI\u2019s API doesn\u2019t make it obvious how to apply a dynamic list of SwiftTUI \u2014 a Terminal UI framework for Swift<\/a><\/p>\n Community Showcase<\/strong> is my favourite section of Swift Forums (perhaps because I\u2019m not smart enough for all the compiler discussions \ud83e\udee0). There\u2019s no shortage of impressive Swift projects announced by community members every other day.<\/p>\n One such announcement<\/a> that caught my eye was SwiftTUI<\/a>. 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.<\/p>\n Some things are never truly lost – How git recovered two weeks of deleted work<\/a><\/p>\nUIApplicationDelegate<\/code> to UISceneDelegate<\/code>.<\/p>\nUIApplicationDelegate<\/code> + UIScreen.main<\/code> combo, focusing only on full-screen experiences.<\/p>\nvisionOS<\/code>. 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.<\/p>\nNews<\/h2>\n
Code<\/h2>\n
RequiresAuthentication<\/code> SwiftUI container. I think the container approach fits particularly well with SwiftUI\u2019s declarative DSL.<\/p>\n.accessibilityCustomContent<\/code> modifiers may vary depending on the data.<\/p>\n.accessibilityCustomContent<\/code> modifiers, but Bas shows a clever workaround using .accessibilityAddTraits([])<\/code> as a no-op starting value and composing the modifiers from there. I wouldn\u2019t be surprised to see this addressed by a proper result-builder API one day.<\/p>\n