Those Who Swift - Issue 285
Weekly note ✏️Swift 6.4 shipped this week, but the release itself wasn’t what caught my attention. Three completely unrelated posts showed up in my feed within a few days of each other. One was about Swift’s debug information, another about figuring out where all those extra MB in your app actually went, and another about tracking down mysterious SwiftUI performance problems. Different problems. Same frustration: Something is wrong, but you can’t see what’s happening. So this week’s issue is about debuggability — and why it deserves more attention than it usually gets. I’d love to hear from you, too: what’s the last bug that took way longer than it should have because you couldn’t see what was actually happening? Hit reply and tell me.
Debuggability Is a Feature, Not an Afterthoughtwith Divya Ravi — Technical Editor Three things landed in my feed within about a week of each other, and the authors weren’t connected. Swift 6.4 brought some quieter improvements to how debug information keeps track of where code actually came from. Jacob Bartlett built a browser-based tool that can open up an Different problems. Different tools. But all three have the same basic idea: You can’t fix what you can’t see. That sounds obvious. In practice, it’s one of those things that gets pushed aside surprisingly easily. Nobody puts “better debugging information” on the roadmap when there’s a feature to ship. Nobody gets excited about spending a sprint figuring out why a binary grew by 40 MB. And “let’s make this performance problem easier to diagnose” rarely beats a customer-facing feature in a planning meeting. Usually, someone just gets annoyed enough to investigate it. That’s what happened with these pieces. Someone got tired of guessing, found a way to make the problem visible, and then shared it. I think about this a lot when working in an older codebase. When you’re new to a system, the hardest part usually isn’t understanding the business logic. It’s figuring out why the system behaves the way it does. Why is this build so slow? Why did the binary suddenly get bigger? Why is this view rendering again? Which module did this code actually come from? Why did changing something three layers away suddenly fix the problem? The answers might all be there. The problem is that the system doesn’t always make them easy to see. That’s why I think good debugging tools are a form of documentation. Normal documentation tells you how the system is supposed to work. Good debugging information tells you what the system is actually doing. And unlike a wiki page, that information can stay pretty close to reality because it’s coming directly from the system. There’s another reason this feels especially relevant right now. We’re generating more code than ever with AI. Agents can write functions, refactor code, add tests, work across branches, and make surprisingly large changes very quickly. But when something goes wrong, we still need to understand why. Is the generated code slower? Did it make the binary larger? Did it introduce an unexpected rendering path? Did an agent change something three layers down? The more code we produce, the more important it becomes to have good ways of looking inside that code. And none of the interesting examples this week needed an AI agent or a shiny new framework. They started with a much simpler idea: If you can’t see the problem, make it visible. So here’s something I’m going to keep in mind when planning engineering work. If there’s one thing that has made us guess over and over again — build performance, a recurring crash, view rendering, binary size, whatever it is — maybe “make this easier to understand” deserves to be an actual engineering task. Not something we keep saying we’ll get to later. Because sometimes the fastest way to fix the next problem is to make the current one easier to see. And if you have a debugging mystery that has eaten way too much of your time, hit reply and tell me about it. I’m collecting stories for a future issue. I have a feeling we’re all dealing with at least one. Related reading on this week's theme 📚Four pieces, all published within the same eight-day window, looking at the same problem from different parts of the stack: the compiler, the build artifact, and the view tree. Swift 6.4 ReleasedThe big release of the week. Swift Build becomes the default SwiftPM backend, Subprocess reaches 1.0, and Swift’s interop story gets deeper across C++, Java, and WebAssembly. There’s also a quieter debugging improvement in here that makes the next article particularly interesting. 📍Level: Intermediate Module Tracking in Swift Debug InfoEver had a debugging session where you know the code is there, but you’re not quite sure which module it actually came from? Adrian Prantl explains the new A small change, but the kind of thing you appreciate when you’re deep in a complicated debugging session. 📍Level: Advanced Diagnosing ForEach performance issues in SwiftUI lazy containers
Natalia Panferova shows how the If you’ve ever stared at a SwiftUI view wondering why it keeps doing more work than it should, this is worth a look. 📍Level: Intermediate This Week in Those Who Swift 🗞️The latest across Swift, Apple, AI, and the community. Swift Around the Web 🌐Connecting two iOS simulators over BLETwo iOS Simulators talking to each other over Bluetooth LE. Yes, really. Kyle Browning shows how to connect two simulator instances so you can test things like pairing, proximity, and handoff without needing two physical devices sitting on your desk. A clever trick for a problem that usually means reaching for another phone. 📍Level: Advanced Coding 👨💻From pbxproj to xcproj: Xcode Project Configuration Gets a JSON FormatThe familiar The obvious benefit is fewer merge conflicts and easier parsing. The more interesting question is what this means for tooling — especially now that AI agents are increasingly reading and modifying project configuration directly. 📍Level: Intermediate Build Siri experiences across apps, Part 1: Onscreen AwarenessSiri understanding “this” or “that” sounds simple until you think about what the system actually needs to know. Sarun walks through Siri’s onscreen awareness and how views can be connected to App Entities using This is the first part of a larger series, so there’s more to come. 📍Level: Intermediate isPictureInPicturePossible was true and PiP still wouldn’t startHere’s a familiar kind of iOS bug: The API says everything is fine. It still doesn’t work. McMizzle walks through the Picture-in-Picture issue from the initial symptom to the actual cause, including the repro and fix. These are some of my favorite debugging posts because the final answer is usually something you would never guess from the original symptom. 📍Level: Advanced Backporting SwiftUI APIsA new SwiftUI API looks great. Your deployment target says, “Not so fast.” Majid Jabrayilov walks through two clean ways to backport newer SwiftUI APIs: a dedicated The second approach has a particularly nice property: you can grep for the old code later and know exactly what can go. 📍Level: Intermediate Apple 🍏Hello Developer: September 2026Apple’s September roundup is here, with the latest Apple Event recap, new App Store Connect analytics videos, the Apple Intelligence Group Lab from WWDC26, Cupertino developer events, and documentation updates across Core Spotlight, Safari, SwiftUI, and Metal. A good monthly skim if you want to know what’s changed without digging through everything yourself. AI & Tooling 🤖Fun with AISarah Reichelt writes about using Claude during a major web-development redesign — but the interesting part isn’t just what AI helped with. It’s where she drew the line. She was happy to use AI for parts of the technical work, while keeping her actual writing firmly human. That feels increasingly relevant as AI gets better at touching more parts of our work. Not everything needs to be automated just because it can be. 📍Level: Beginner My terminal-native setup for parallel coding agentsRunning several coding agents at once sounds great. Until you have three terminals open and no idea which agent changed what. Igor Kulman shares the tmux + worktree setup he uses to run multiple agents without losing track of them. It fits nicely with this week’s theme too: parallel agents are useful, but only if you can still see what’s going on. 📍Level: Intermediate Design 🎨How Klemens Strasser prioritized inclusivity with Art of FaunaKlemens Strasser’s Apple Design Award-winning puzzle game Art of Fauna was built around vintage animal illustrations, but there’s more to the story than the visual design. The game was designed with accessibility in mind and tested with Screen Curtain for blind and low-vision players. Even better, 20% of the proceeds goes toward wildlife conservation. It’s a nice example of accessibility being part of the product itself rather than something added at the end. 📍Level: Intermediate Tutorials📒Parameterized tests and test organization with Swift TestingIf your tests are starting to look like the same test copied five times with different inputs, parameterized tests are probably worth a look. Natascha Fadeeva walks through Simple idea. Much less test duplication. 📍Level: Intermediate Compressing images and PDFs from the Finder context menuA tiny automation, but a useful one. Daniel Saidi shows how to add an Automator workflow to Finder so you can compress images and PDFs directly from the right-click menu. Not everything needs to be a massive automation project. Sometimes the best ones are the little things you use every week. 📍Level: Beginner Thanks for reading Those Who Swift! Subscribe for free to receive new posts. 👇
|
