Dub Dub Daily: Day 5

This is it. Welcome to Dub Dub Daily, the final day of WWDC26. What a week it has been. We've got two more Group Labs this morning and they're good ones. As a reminder, all Group Labs will be available on demand, so you can come back and watch them whenever you like. Before we wrap though, there's one more conversation you need to hear. Swift has been a through line all week.

And Holly Borla is just the right person to close us out.

My colleague Jeff sat down with her earlier this week. Here they are.

Holly Borla, engineering manager on the SWIFT team. Lots going on for you this year. You say in so too this year with slides that I believe to be your actual Memoji, that Swift this year is designed to entirely to help developers get back to doing the most important thing, which is having fun. Tell me a little bit more about that. Yeah. And to me that means two things.

The first is writing really clear and beautiful code. Often times when I'm writing code in Swift, by the time I'm done, I'm really proud of the way that the code I've written reads. And then the other part of it is the confidence that the code you wrote is correct. And the compiler being there to help catch your mistakes is a really key piece of that.

So in order to write clear and beautiful code, one of our goals is to eliminate friction points that come up when you're writing code on a day-to-day basis. So a lot of the updates that you'll see in Swift 6.4 are removing things that are friction points so that those things are out of your way and you can really focus on expressing your ideas in a really clear and beautiful way.

What are some of the first things developers will notice this year? I actually think there are a lot of updates that developers might not notice until they're pointed out that they're no longer issues.

For example, there's a much more streamlined way to use some and any types in Swift together with optionals. Previously you had to write a little bit more syntax with parentheses, and now what people naturally try to write will just work. So it's something that smooths over that developer experience of writing Swift code, but it might not be something that you notice. But all these little things add up to really improve your your productivity when writing day-to-day Swift code. Same thing with in concurrent code, calling an async method in a defer block. Previously there was a limitation where the compiler would prevent you from doing that. And now that also just works in the way that you would expect, you can call async code in the same way that you can in the rest of that function body. And again, unless you knew that was a limitation before, it might not be something that you notice, it's just something that you're not prevented from doing. So the code you naturally write works, you move on, and it's not something that you have to to deal with. So addition by subtraction. Yeah! And the best thing when things just work and you didn't notice that they didn't work before. That's fantastic. Lot's going on this year for you that people can see. What's something maybe happening under the hood, something that's maybe not as readily apparent, but that you and your team are very proud of.

One of the areas of compiler development that really excites me that's not like a flashy new language feature is diagnostic improvements. So improving the error messages that come from the compiler. And I think this is a really important area because it's the main feedback that you get when you're writing Swift code. It helps you internalize the language features that you're working with, understand what works and what doesn't, and it can also be really frustrating if you get an error message that isn't easily understandable or doesn't make it immediately clear what you need to do in order to fix your code. So there's a lot of different kinds of diagnostic improvements this year in SWIFT 6.4. Some of them are more infrastructural to improve diagnostics both now and ongoing in the future. But there's also more ways to control diagnostics in your code. One of my favorite new features is the @Diagnose attribute, which lets you control behavior of warnings in your code, this lets you do things like suppress deprecations, but it also lets you do things like opt into strict memory safety or strict concurrency diagnostics on a more granular basis, which helps with, for example, the migration to the Swift 6 language mode. So there's a lot across the board that gives you more control and also just general diagnostic improvements. There's a fun little moment in SOTU, where you mentioned a specific issue that has been improved. Can you tell me about what that issue is? Yeah, the error message is the compiler is unable to type check this expression in reasonable time. So if you've written some, you know, significant Swift code before, you've surely seen this error message. It's a fallback in the compiler's type checker, so the thing that the subsystem that does things like type inference and overload resolution, it determines when you call a function, which function of the many overloads that might be available, you actually meant to call. And that has some performance thresholds, both with an approximation of time as well as memory that's used on your system. And if it goes over those thresholds, you'll get this fallback error message, which can be really frustrating because sometimes you're not even sure if the code was correct and the compiler timed out, or if you had a mistake somewhere in your code and the compiler timed out trying to provide you with a more precise diagnostic. So this is something that we've been continuously working on the developer experience of to try to mitigate the, you know, instances where you will see this error message in practice. This year we focused a lot on mitigating that error in nested closures and Swift UI view bodies, which is a really common place to see it. And there's still some more work to be done and you can follow along with that through the Open Source Swift project if you're interested, all of the work for that is done there and we post, you know, road maps and updates when we make progress. But we know that's a really important part of the developer experience to improve on because that is something that when you get that, it can be really difficult to determine what you need to do in order to fix it. Lots of things for people to try out this year. What are you excited for people to get their hands on? Yeah, I'm really excited for people to try out the new features for controlling the behavior of diagnostics in their code. I think this has the potential to lead to some more improved workflows, especially for migrating to enabling certain kinds of diagnostics like strict concurrency checking, which will help with, you know, migration strategies to the Swift 6 language mode. So I'm really excited to see how developers are making use of that in their migration. One of my favorite things to do is to read articles, blog posts or watch conference talks, where people are sharing different strategies for migration or making most effective use of language features in the context of their code base. That's really valuable for me to understand and I also love that people are sharing those tips with the broader community.

Thank you so much, Holly and Jeff. Really wonderful way to close out the week. And the learning doesn't stop here. Join us for WWDC recap activities all around the world to find out how all of these new announcements can benefit your apps and games. Visit developer.apple.com/events for the latest sessions, workshops, and labs both online and in person, including at our developer centers in Bengaluru, Cupertino, Shanghai, Singapore and soon in Berlin opening later this year. And follow Apple Developer for more details. Time to go check in on what my agent built in Xcode. Thank you for being a part of WWDC. We can't wait to see what you make next. See you out there.