ATP Interview: Holly Borla & Ben Cohen

23:09But what actually happens is that in some of these techniques, you find out in the wild when your program is crashing and you do not exactly know why. I'm always amused by people who make these jokes on Mastodon or Twitter where they say like, they make a joke about concurrency where they jumble up the words. And that's cute, but that is again, the best case scenario is jumbled up words That's very benign. What's worse is you crash, you corrupt user data, this is no good. And so that's why a lot of people have these really great practices in the old world of dispatch, where they will insert these assertions saying, I want you to stop me if I'm not running on the main queue.

23:51So I think the long-term goal is that we need to lift these kind of disinformation out of documentation. We want to take it out of documentation and put it actually in the definition of the API. It's not in the definition now, so you don't have to lift it up. Wow. So the benefit of putting it there so that the compiler actually enforces it is that you can't not have that information. By definition, your code does encapsulate the information about where you are running and how it's running. Yeah, because one of the things I do when flailing is like there's a callback and I'm like, can I just annotate the callback as main actor?

24:29And the answer is no, can't. And then it's like, why? Is it already on, always on the main thread? I figure what the error is, I'm sure. Just wait for the framework to be updated with async calls. Yeah, well, you don't have all the time in the world to wait. What it comes down to, like you mentioned queues, right? So one of my apps has concurrency. I'm sorry if it does. And I use queues. And in one situation, I wrote a little class, and I use locks, the old style locks. And I'm pretty sure it's probably okay. But I look at that, and I'm like, I would like to use Swift concurrency, because then I would feel more sure.

25:02But there's nothing you can do to sort of annotate or mark up dispatch queues or locks other than the reassurance of just telling the compiler, I'm pretty sure that I'm right. I would rather just like pull that out and re-implement it with actors and so on. And that sometimes just seems daunting. So another thing that there's a ton of Swift code out there and Swift code that interoperates with C-based languages like Objective-C and C++. Plus, we're at the start of this transition to start to integrate Swift's native safer concurrency primitives into these like vast code bases that are using older, you know, library based concurrency primitives like dispatch queues.

25:41The system is designed for incremental migration. So in the case, if you have like a class backed by a dispatch queue, there is a technique that you can use to turn that class into an actor that's backed by a dispatch queue. It uses a fancy feature called custom actor executors. But the way to do it, it's only like four or five lines of code that you actually have to write in your own code. And what that lets you do is from your Swift code, it lets you use the static actor isolation and not have to mess with the dispatch queue. But when you're interacting with APIs that are based on dispatch queues, you can still pass the dispatch queue there.

26:16And then you can bridge between like the dynamic isolation in the static world with tools like assume isolated. That brings us another question of incremental adoption. I know this Swift 6 just came out, and in the old 5 world, we had the little setting to set it on complete concurrency or whatever. I know there's a whole bunch of features in Swift 6 and new things for setting ability and everything that make it easier. But what is the mechanism in your project of saying, is it per module? Is it per file to saying, I want the Swift 6 language features, but this file is not ready for strict concurrency?

26:48What does that look like? So the setting is per module. So in your Xcode build settings, there's a language version setting. Or if you're in a Swift package manifest, there's an API for setting it per target. And many people currently have that set to something, whether it's for 4.2 or 5. So you would change that to 6 for the specific module that you're looking to migrate to Swift 6. And then if you have a particular file that violates some of the rules in ways that are really difficult for you to change, there are ways to opt out of checking in specific areas in your project using things like pre-concurrency import statements if the issue is in an API that you're using.

27:30Or tools like non-isolated unsafe if you have, for example, like a global variable that you're manually guarding with a lock or a queue at the point when you access it, you can use non-isolated unsafe to opt out of the compilers checking there. So there are a variety of tools like that to let you opt out of the checking in narrow situations in your code. And then those are also things like handles that you can audit for later to actually take a look at the opt-outs that you're using in your code and try to use those as refactoring opportunities to rewrite some of that code to use something safer.

28:02So you're picking the Swift 6 as the language, and that includes everything having to do with Swift 6. No. No? No. So Swift 6, the language mode, where you go into the Xcode settings and you say language mode of Swift 6 that purely governs the strict concurrency checking. So the Swift 6 compiler that you get with the latest Xcode, that has all of the new features. So I think you made a glancing blow to non-copyable types. Those features are available. New generic capabilities for non-copyable types are available in the Swift 6 compiler. You do not need to turn on. So you would pick the Swift 5 language mode, but it's using the Swift 6 compiler to run in Swift 5 language mode.

28:39You get non-copyable types. You don't get the strict concurrency. That's right. Right, and that's exactly, this is part of a journey that the entire Swift ecosystem needs to go through. So being ready for Swift 6, having your dependencies ready for Swift 6, there's actually at swiftpackageindex.com, which is this great website, they have a tracker now that tells you which packages they are compiling that build cleanly under Swift 6 code. But it really does depend on the nature of your program and whether your dependencies are now ready for Swift 6, whether you want to turn on that language mode.

29:09And this dates back to, we've been doing this now since the Swift 4 days. So since we introduced the Swift 4 language mode, we've always had this source compatibility guarantee promise that whenever you download the new compiler, with a couple of exceptions where maybe there are a couple of issues with your code where maybe the code was explicitly incorrect, we always want you to be able to compile your code as is with the latest compiler. And then when you're ready for some breaking change, there were a few in Swift 5 and obviously in Swift 6, the key change here is strict concurrency. You're then able to turn it on on a per target basis.

29:49Is that like a longstanding kind of marketing decision to tie them to the, I mean, just deciding that Swift 6 means strict concurrency? You could have, for example, said Swift 6 just means Swift 6 language features and there's some other option for strict concurrency. and he said, no, we're tying this feature to this number because people want the higher number? Is that like a sort of a social engineering decision? Yeah, it's a way of thinking about the forward progress. I mean, you don't want to be stuck in this world with the Python 2 to 3 transition style thing, right? Where those were tied to updating your compiler and then you couldn't get the new stuff without changing your code to adapt to the way that the new language works.

30:28So it's this way of helping engineer the ecosystem system to help have this continuous forward progress. But at the end of the day, people also, you know, some people have written code in such a way that it won't be so easily adapted to SWIFT concurrency. Some people have written code using a lot of new frameworks and a lot of async await and the path for them is actually pretty clean. And so we want people to be able to opt into that. The choice as to whether you opt in or not is up to you. If you're finding that you are experiencing quite a lot of pretty gnarly crashes, it's probably worth considering opting in.

31:02one great time to opt in is if actually you want to start introducing a lot more parallelism to your code. So we have these powerful new devices. They have many cores. You might find yourself with an app that previously was doing most of its work on the main thread with a little bit of background processing, but you really want to take advantage of a lot more parallelism in your code. That would be a great time to turn on Swift 6 mode in order to know that you can do those refactorings without fear of introducing new data races. So yeah, it's really up to each individual project to make that decision and to see how the community is moving forward with them in order to update their dependencies and then take the plunge.

31:41Do you worry about releasing Swift version 10 many years from now and huge code bases are still in Swift 5 language mode? Like they're using a Swift 10 compiler to run Swift 5 language mode because they could never get the wherewithal to go stricken currency compliant and you're just plowing bravely forward here at Apple for making version after version, and they're all great, but they can never cross the sixth threshold because they can never get their code to run under strict concurrency because of millions of lines of dispatch queue and manually created locks. Do you worry about hindering your products?

32:10You've basically made a hard gate of like, you're not going to be running a Swift 7 next year or whenever if you can't go strict concurrency. And you're like, well, my reason I can't go is because we have 10 million lines of manually managed locks or something. So it really only governs a handful of things. So the goal is always, whenever we introduce a new language feature, that you do not have to update to the new language mode. We were looking at somebody's project yesterday where they were still on Swift 4 mode, and really there was not that much they were missing out on. So we have this long-term promise to always support those language features so that people aren't forced to update.

32:47But like I say, most of the language features themselves are not gated on the language version. And so really it's only when we need to take these big step forwards that we encourage people to upgrade. They'd be running in Swift 5 language mode, but they'd still have access to all the new Swift 10 features, but they would feel bad about themselves because their number is 5, and you're rolling out 7 and 8 and 9 and 10, and people would look at the little gamified badge on the Swift package index and like you don't have the little things that's Swift 10 compliant, and I have a little star next to my package, and you don't.

33:18I get the language features, it's just not compliant. I also think there's a misconception that you need to totally eliminate all of the uses of tools like locks and dispatch queues in order to migrate to Swift 6. I don't think that's true. I think locks, I mean, the Swift 6 standard library includes a new primitive mutual exclusion lock called Mutex. And that is a tool that people can and should use in some scenarios in their code. And I know there are a variety of other lock types out there that people are currently using. You don't need to stop using those types in order to migrate your code base to the Swift 6 language mode.

33:53The same thing is true of dispatch queues. And like I said, part of the reason why the system is built on incremental migration is because we know there's so much concurrent code out there that is using, you know, dispatch and other concurrency primitives. And if you had to eliminate or just totally refactor all of your code in order to migrate to Swift 6, nobody would ever do it. So I don't think you need to actually like massively refactor your code in order to migrate to Swift 6. Though in some cases, like in Ben's talk, you'll see a talk that he gave back in 2021. He actually took a sample app and it was using dispatch.

34:29And he went through and replaced some uses of dispatch queues with actors. And that might make the migration a little bit easier in some cases. but you'll sort of see when you watch the talk some of the things that are made easier by introducing actors in some places but it is still possible to do it if you're using other things like dispatch cues. I have seen that talk. One of the challenges there is that doing that refactoring prior actually made it a lot easier to migrate to Swift 6 and that's actually something that we'd encourage is people who have been adopting async and await and things like that they will find that turning on strict concurrency mode is a lot smoother for them But we've also, in the latest compiler, added a lot more affordances, for example, around not having to make your type sendable, but also be able to pass them through between isolation domains.

35:17One of the challenges with writing the latest talk is that actually I had these great examples of problems that I was going to talk about, and then we fixed the compiler, so they weren't a problem anymore. It happened like three times. That's a good problem to have. It's a very good problem. I mean, that brings me to the next topic. for both of you, what is it like developing Swift in the open? Because I'm watching all year on Swift Evolution. I see the features coming in Swift 6. It's part of the reason I kind of backed off my recent attempt. I'm like, look, they're fixing a bunch of stuff in Swift 6.

35:46And you see them go by. You see the proposals. Here, we're doing this thing. They're fixing the problems in your talk. And I see it happening all throughout the year. That's very different than most other people here at Apple. I mean, maybe some people sit down for WWDC and they're shocked by Swift 6. But if you're following the forums and watching the proposals, it's developed in the open. It's open source. the process of deciding what goes into it is open. There's no mystery involved. What is that like for you in a company where that is absolutely not true of all the other teams that you're working with, except for maybe WebKit?

36:15For WebKit, but also increasingly we're seeing more of this style of operating. Foundation now is operating in a similar fashion. And that has actually been key to the next thing that we've announced this year, which is that we now have this single unified foundation code base across platforms. So the same foundation that you're running on your phone and on your Mac is the foundation code that you will be running if you were to stand up a server running on Linux. And so they've been running language proposals, sorry, language proposals, framework proposals to introduce new features such as, I think, Predicate, which is a foundation type, recently acquired support for regexes, and that proposal was discussed in the open.

37:04And then the other example, I heard your podcast last week where you were wondering, speculating about whether there was going to be a new testing framework. That's because I couldn't remember the name of Swift Testing. That's the one I had seen, yes. And yeah, so Swift Testing was developed in the open. We had some really great community feedback from that. And so that's another place where we're doing that kind of open dialogue with the community about sort of the next layer up of Swift framework features. Is there any, like, you can use it as an example to the other groups, like, look, we have a public issue tracker.

37:41And when people have problems, we can discuss them in the open and look how much more efficient it is to go back and forth on GitHub issues and discuss proposals. And these other groups are, like, sending carrier pigeons across the country through seven different intermediary parties with this game of telephone to find one crashing bug. Do you ever pitch the other groups and say, hey, I mean, I obviously worked on Foundation. You know, this could be you. You could be getting bug reports from people and communicating with them in an efficient manner and fixing them. Yeah, we get a huge amount of benefit from the Swift community, I think.

38:12When we bring ideas to them for new language features, we get this real-time feedback where the people on the forums, they spot issues with what we're proposing that we had not thought about. and we iterate with them on that and we get a huge amount of value from getting that real-time feedback from people. So I would say that's certainly been a valuable process for us. Plus you have to argue about keywords. The true purpose of every language evolutionist. We've fallen into this mode now where this is something we've evolved as a process in the language steering group that Holly and I sit on which is we're now in this mode where we will agree a proposal in principle, where we talk about the fundamentals of the language proposal and how it's going to work.

39:02And then what we say is we've agreed that in principle, and now there's like a free swim where everybody gets to specifically focus on the name we're going to use for the keyword. And that has actually helped the process a lot because the bike shedding is a shiny thing that people immediately move towards. And so if you say, like, let's park the naming discussion for now. Let's talk about the fundamental feature. Then when we've agreed the fundamental feature and we accept it in principle, then we can have, like, a discussion about what we're actually going to call it. And I mean, I know that's a source of contention and it's a silly argument for people.

39:35But it really does make a big difference in language. So some people look at the, like, Switch Evolution or other language lists and they're like, it just seems like a bunch of people arguing over, like, whether copyable should have a tilde in front of it, should be a new keyword or like. But that's so important because those decisions you make, people live with those for decades. So you should spend a month arguing about it. Because I've seen it change. And for the illusion, the original proposal will have this thing or whatever, and you'll end up with a different thing. And it's better. You're making it better by arguing about it.

40:02I guess people just don't have a tolerance for it. They think, oh, that's not important. I don't care what the word is called. But it makes such a big difference to the language. And anytime you make a slightly wrong choice. I remember I was talking to, I don't know, it was Dennis Ritchie or one of the old Unix guys or whatever. Do you have any regrets about your career? and he said, I wish I'd put an E on the create system call. You know, C-R-E-A-T. Wow. How long is he been living with that? Like, and like, I just, I wanted to save that character and now it's create for just for the rest of it.

40:25We're all, it's on Mac OS. It's on every Apple platform right now somewhere in the source code, there's a call to create with no E on it because this guy made a bad decision in the 70s. And so you don't want that to be you. So yeah, spend the time arguing about it. And I think that what you said, like doing the, figuring out what you're going to do and arguing about the keywords is a nice separation so you can make forward progress. But I'm here to endorse arguing by keywords. It's also really valuable because there was a recent proposal called Sending Parameter and Result Modifiers. And we did the same thing there where we had the concept from the proposal.

40:57We accepted it in principle. And then we had a revision review to focus on the name of the keyword, which was originally called transferring. Now it's called sending. But the revision review thread is really interesting because a lot of people are coming in. And as part of justifying why they think this keyword should be called something specific, they're reasoning through how they're thinking about the feature and how they would explain it to other people. And at points where they maybe got something slightly wrong, someone else would come in and say, oh, I think this actually works this way.

41:25And I think this keyword is a little bit misleading. And so that review thread is really cool because it didn't feel like a really heated, contentious debate. It felt like a healthy debate of people trying to come in and explain a concept and then listening to other people explain how they thought about it. And it's also valuable for us in figuring out how to actually explain the feature to Swift programmers because what the formal specification is in the proposal is not, you know, the level of detail that you actually need to understand in order to use the feature. So, yeah, those name bike shedding threads are valuable for a bunch of different reasons.

42:02Yeah, and that's part of the reason doing it in public, I feel like, is so beneficial because the people who are working on the proposal know it at such an intimate level. And then you throw it in a bunch of people who have no idea what you're talking about, and they will tell you, this is confusing to me. Like if they're using a term of art that's meaningful to compiler people or you've just all internalized as a group what this means because you've been debating it for a month or whatever. And the word doesn't make in their mind make them think of what it actually is. And so changing the word will make it more learnable and more memorable.

42:29And again, the people who don't like bike-shitting will say, well, yeah, it's a weird word, but you learn it, and then it just becomes internalized. That's what happens to everybody, but that doesn't make the language approachable. If you pick a good word, if the word means what you want it to mean, it will help people learn the feature faster. I definitely find that because, again, some Swift features, I read the proposal and I don't understand it until you change the keyword. And then I'm like, I read the same proposal. I'm like, oh, now I get it because the word you've chosen is different, and now I understand what you're getting at.

42:56Even non-copyable types was like that because I didn't understand what you were trying to do until it went around a few times. I'm like, okay. Start like the sending and whatever. And I think you picked that because of the – was it part of the synergy with sendable and everything? The connection with concurrency. Yeah. Previously, it didn't sound like it had anything to do with concurrency. And so riffing off of sendable in a slightly different form so that it's not like I'm talking about sendable versus sendable. Someone did actually suggest calling it like lowercase s sendable, but that's really difficult to talk about.

43:23But sending is close enough that it's very clear you're talking about sending a value over an isolation boundary because that's the term that Swift uses for that concept. So you have this immediate connection to concurrency, and then you can dig in deeper to how it works. Just don't let the math people know the language. That's what I'm saying. Well, it's funny just to kind of reiterate what John said. You know, when I still had a real job and I was working with other Swift developers, it was hilarious the younger ones. when our code base was, some Objective-C was largely Swift, but you would bring a young, typically a younger person who has grown up on more, you know, JavaScript-y languages.

43:56And I think Swift is like that. And I don't mean that in a bad way. I mean, in a good way, it's much more approachable. And then we would, they would look at a file of Objective-C and they would just recoil because it just looks so different. Like, even though there, I like Objective-C just fine. I'm not a super fan, but I like it just fine. but it's so much less approachable, I think, in so many ways because it's so different. And I think those silly arguments about a tilde, one of you said a minute ago, like a tilde or not, and what keyword to use, they really dramatically, in aggregate, can change the whole kind of vibe of a language.

44:28And Swift's vibe, I think Marco had said earlier, or maybe somebody said, you know, there was a window of time where it was getting a little architecture astronaut-y, I feel like, but I feel like that's really been brought around in a good way. And I feel like we're heading on a good path. And those arguments, while I was one of those people that was like, oh, my God, why do I care? But then just like John said, you think about it for a minute. You're like, oh, no, this is what you two just said. This is worth arguing about. And I think it's important. Architecture astronauts are saving your butt, OK?

44:56Yeah, that's very true. You're doing a good enough job of architecture astronaut. And you're like, oh, they all went away. No, they didn't. They just did their job. Fair. No, that's fair. That's fair correction. Yeah. I mean, the goal is very much we have to plot this path, right, between helping people make code correct and also helping make people easily able to bring forth what's what's on their mind and and make it like a low ceremony language where they don't have to put that many keywords um and sometimes those two things can be intention and that's something that the community really helps us work through right like so um i think even with concurrency right the the strict checking mode the goal there is to have the compiler help you work through exactly what you're trying to express.

45:39And so sometimes we do have to resolve that tension. And that's really the game of language design is making sure that we keep that vision of having Swift be as low ceremony as possible, but not any lower than that, right? Because if you have like no ceremony, then you don't know what's going on. And right now you're in like an untyped language where it's really difficult to understand exactly what the code is doing. If you have too much ceremony, then you get, a language more like Java where you have to write multiple different things to achieve the same result that in Swift would just be like a couple of words.

46:15So yeah, it's plodding that path and that's actually something that we think Swift hits the spot of which is why we think it would be such a great language to expand beyond just its existing app development ecosystem and expand into other places where people want like the performance of a ahead-of-time compiled language that doesn't have garbage collection, whilst also giving you the ability to have a joyful experience writing code where you don't have to write that much code and you don't have to fit too much stuff in your head at once. Still hanging on to that dream of Swift being the language that spans from the lowest level of the operating system up to scripting.

46:51And there's a lot of programmers who are the potential audience for Swift, but obviously a lot of the programmers who are your target audience are Apple employees. How do you work with the other teams at Apple when it comes to language features? How does that work? So just give an example, like result builders for the SwiftUI thing, non-copyable types, Objective-C interop. Like, do you come to them and say, hey, we think I have an idea? Do they come to you? Like, what is the interaction with the rest of Apple for language features? Language features that will obviously, they will benefit everybody when they get out there in the world.

47:20But sometimes you look at them, you're like, okay, that was a language feature that was made specifically for teams at Apple so they could adopt Swift faster or whatever. I mean, I think the way I would think about it is that no feature is ever good unless you use it. So when we're developing a feature, we really need to do that development with somebody who is directly using that feature. And ideally, you do that development in real time. And so when we're working with a team like the SwiftUI team, We really want to know that something like result builders is really going to hit the spot of them being able to create that really expressive API and develop that feature with them and have them use it and give us feedback in real time.

48:05Are you bringing result builders to them, or are they bringing the idea of SwiftUI to you and saying we need a generic system to do this? I don't think SwiftUI in particular is not. So another example would be embedded Swift. So obviously we've got a lot of material this week, and we've been putting it up actually prior to this week, encouraging people to check out Embedded Swift and use it for developing for the Raspberry Pi Pico or the Playdate or something like that. But we also developed it in conjunction with some of our developers who are working on things like the Secure Enclave. And we've talked about that's actually one of the places where we've adopted it this year.

48:43And so we directly work with them and they inform our thinking about how to target that language mode. And it really ends up being a better product. I think if we developed the language ahead of time and then said, here it is, we knew you needed to do some firmware development, here's a language that does it, we would not get as good a result. Yeah, and another example of SwiftUI is like the old limitation for the parameter things. You get one through 10 or whatever, and it was parameter packs or whatever thing that goes around that. Was that an example of like, OK, well, you obviously didn't have that language teacher.

49:14They rolled out SwiftUI anyway, and there was this kind of, semi-not well-known limitation or whatever. And why was the limitation? There was a language limitation. Then you could look at that and say, all right, well, our language is failing the team here. How can we solve that? But not just by hard coding a thing for SwiftUI, but adding a language feature that now is beneficial to anybody who wants to use it. But as a side effect, that limitation in SwiftUI is gone. Yeah, so parameter packs specifically were a generics feature that I think we always knew we wanted to have, because there are such a wide variety of use cases for them.

49:48And Swift UI View Builder is not the only API that adopted parameter packs last year. You also see it in Foundation's Predicate API. You see it in WeatherKit APIs because there's a lot of APIs that are structured like that where you have a variable number of things that you pass in and then you get the same variable number of things as your output there. But I help a lot of people try to express something in Swift every day across a wide variety of framework teams. people writing apps, people on the forums. And one really important job of my team, the language team, is to see all of these different use cases that people have and first and foremost, help them use the language as it is today.

50:28In a lot of cases, people are just trying to use some feature that already exists and they need some help figuring out how to exactly make it work for their specific use case. And in cases where there is an expressivity limitation in the language, we take all of these different use cases, again, from a variety of different sources. We use the forums as a big source of use cases for different things as well. Macros are a really great example of this. There were a variety of different use cases for frameworks at Apple, SwiftData adopted macros, the new observation library from last year as part of the Swift Standard Library uses macros.

51:04But there were also a ton of use cases spinning up on the forums about people who were wanting to do really similar things in their code. And something that was awesome during the review process of macros and Swift Evolution was people were trying it out and putting up example macro packages on GitHub. And that also was a really great example of people actually trying out the feature and seeing how it worked for them at the same time that it was being developed. And that turned into real feedback that was incorporated into the design. So yeah, usually the way that these things work out, unless there's some big overarching goal like data race safety, that was a goal that was driven by us.

51:44But a lot of times it's that we're helping so many different people use the language in a variety of different ways. And we can, you know, generalize these expressivity limitations into a single language feature that works for everybody. It's a really interesting process. Parameter packs is actually, I think, an example where we really feel like we're successfully doing what we try to do, which is have this progressive disclosure where we have these really advanced language features that ultimately are able to produce APIs, help people produce APIs, that you would not know you're using these advanced features when you use them day to day.

52:22You do not know when you go create a view with 11 things in it, that actually that is only possible because of parameter packs. You don't know that when you've got this really nice API where you tell the weather API to give you temperature and wind speed, it's actually giving you two strongly typed values that then instead of giving you two untied values like in any type value that you used to have before, you immediately get these two strongly typed values where you get code completion on exactly the types that you have that make it so much easier to use. Macros is another example where the creation of macros was general enough that people were able to create these great new APIs that you do not have to think about when you're using them.

53:01So Swift Testing is another one I know you folks were ragging on the fluent design of other testing frameworks. And one of the beautiful things about Swift Testing is that you write just regular expressions. Sorry, I shouldn't say regular expressions. Especially that was the problem. Wrong term. I can't say that's a jump game. You write ordinary expressions, ordinary Swift expressions like A is not equal to nil or something like that. you put them inside a pound expect and then the pound expect macro will do some magic stuff under the hood to do reflection actually exactly similar to what you were talking about where it breaks down the object and looks at all the different properties we don't have diffing quite yet, that's a great idea to maybe bring to the Swift forums and talk about if you just look at any other testing framework I'm pretty sure they know it exists that's the thing with testing frameworks there's so many of them, there's so much prior art and XC test was a little bit crusty but you're spoiled for choice so you just look at all the popular languages and all the testing frameworks And you've chosen this time not to go with a bunch of words with dots between them, but some people like that.

53:58So I predict that Swift testing, it looks like a great advancement over what came before, but I feel like testing frameworks are difficult to get right on the second or third try. So going beyond XC test is great. We actually had planned to talk to the both of you more about Swift testing, but in interest of time, I wanted to give or we wanted to give you guys a couple of the floor to answer a couple of softball questions. First of all, I'm going to start a little bit negative, and then we're going to end with a positive. Is there any misunderstanding? It's more curveball. Yeah, right. I actually have a statement.

54:32I don't know. Support's metaphor. Is there any common misunderstanding in the community that maybe grinds your gears or you just feel bad? Like, I'm trying to make this not so negative. Like, you just feel bad that people just haven't grokked that, oh, you know, all of us, myself, maybe included, think A, but it's actually Z, you know, or whatever the case may be. And maybe there isn't anything, but if you had, let's say, you know, a couple of minutes to correct some common misunderstanding, is there anything that jumps to mind? About Swift, not just the one. Yes. Yeah. There's one immediate one that comes to mind.

55:05People in Swift love protocols. Protocols are great. I love protocols too. But a lot of people, when they're starting to write, you know, an app, they start by adding a protocol into their code. And then they end up using a lot more abstraction than they really needed to in their code. Like they end up using any types or if you're familiar with the formal term existential types, which we try to steer people away from because those are a really complicated feature. And understanding why they have some of the behaviors they have is really, really nuanced and hard for a lot of people to grasp. And in a lot of cases, you don't need them.

55:40So I would tell people to start with a concrete type, start with a struct specifically until you need more abstraction or you need reference semantics and then sort of evolve from there. The same thing is true of global. I've seen so many people write static variables that never change throughout their code base. So I would tell people to start with a let. And that's really helpful for data array safety as well. Yeah. I blame, what is it, maybe you know, protocol-oriented programming. Remember that LWDC? I was thinking the same thing. A lot of people went to that session and were like, protocols, they're the future.

56:12I'm starting every app with protocols. It's worth re-watching that talk. What the talk said was, if you're thinking about creating a subtyping relationship, instead of a class hierarchy, start with a protocol. Unfortunately, what people heard was, start with a protocol. It's right in the title. They read the title and they're like, great, I'm on board. This is the right tool for everything. And so it gets to that point where it's kind of like the black box, why don't they make the entire plane out of protocols, right? That's not what you want. You want to start from struct, like Holly said, and then generalize your problem when you find you need to generalize it.

56:43That's actually – That's how we programers do, though. They generalize it from the start. Yeah, that's really good advice. And then finally, because we really are running low on time, what are you proud of lately? Like, I mean, obviously – and there's obvious answers, like Swift concurrency and the strict concurrency. It's an incredible land, and you should be proud of that. But is there maybe something that, you know, your pet feature or project or what have you that maybe not a lot of people have seen, Embedded Swift is a great example. I've seen a lot of this on the WWDC session titles anyway, but is there something maybe a little more esoteric or just your pet thing that you're really, really into that you're proud of?

57:17I don't know if it's esoteric, but I think we're pretty proud of the progress we've made around cross-platform support. That's especially something that we've been pushing this year. We have support for more distros this year. We have now Debian and Fedora. We've been working with the community on creating this really great plugin for VS Code that allows you to use VS Code, if that's what you're into. Personally, I'm sticking with Xcode, but a lot of people have very personal preferences. We also have some articles up on how to integrate code completion into NeoVim and Emacs, if that's your jam as well.

57:52So I think we've made some really great progress in that area, and we've seen both internally and in the outside community a lot of more rapid adoption of Swift on Linux environments and on the server generally. I think if you saw some discussion in the keynote to the fact that we're now running Swift on the server to do some of the new Apple intelligence features, and that's all built on this foundation that we've been working on for years with projects like the Swift Neo framework and things like that that have always given us this ability to stand up servers that have this really great ability to, again, have this high-level language that we feel is really enjoyable to write, but that managed to get you, in the case of the server, really low memory footprints, which can be a big challenge when it comes to large server farms especially.

58:46And that's been a really big win for us that we're pretty proud of. World domination is still on the table. Still on the table. How about you, Holly? My team's focus this year was data array safety and SWIFT 6. I'm personally really proud of my team because a lot of the team was new to the data race safety model and the concurrency model in general. You know, at the beginning of this year, originally it was built by a smaller group of engineers and then more people got involved in concurrency. So, yeah, I'm really proud of the work that the team has put in in general into this release. And I'm also really excited by how the community has started to adopt these features and surface feedback to us and talk about what's difficult, talk about what error messages are confusing, and sort of seeing the community really embrace this new model of programming and come to a shared understanding and improve both the compiler and the documentation and the language.

59:47I'm really excited to see where this goes from here. That's awesome. Ben Cohen, thank you so much for joining us. I really appreciate it. Thank you very much. Holly Borla, thank you. so very, very much to both of you guys. We really, really appreciate it. Thank you so much for having us. And thank you to Apple for hosting. And with that, I think we're good. See you next week.