We should sing a song. We should sing a song. Is that going to be the new start to the podcast? How's your singing voice? My singing voice is awful. Although, actually, so while we talk about singing voices and speaking voices, both of us are trying new microphones today. And so we may sound very different on this podcast recording to what we normally do. If we don't sound so great this week, please bear with us. We'll get it fixed by next time. Yeah, it's just the mics. It's only the mics. It's definitely not the voices. Speaking of last time, can you actually believe that we talked about upcoming Swift 9 features and absolutely failed to mention macros? Yes. What were we thinking? That's kind of bizarre. I did actually, obviously when WDC started and they were brought up, that immediately pulled it back. I'd also seen Paul Hudson's blog post about the Swift features, and it was obviously front and centre right there. Yeah, it was just bizarre. We completely, completely failed to mention it at the time. It's it's really curious how stuff can be so out in the open. And you because we both were aware of it, right? I've read the manifesto, but it's completely It's completely gone. I mean, Apple could really just stop with the secrecy because, you know, it's just there. People don't notice anyway. [laughs] [00:10:00] Their secrets are quite literally safe with us. [laughs] [00:10:04] But they're also a great feature, right? Have you seen the two sessions of WWDC? The one by Alex Hoppen, which is the more introductory one, and the other by Becca Royal-Gordon? [00:10:17] I think I saw the introductory one. I haven't yet watched the other one. [00:10:20] Yeah. I think there's maybe something we could briefly talk about with the macros because not only did we fail to mention it last time, we actually did speak about macros before. And I was reminded of that when I saw that second session by Becker Royal Gordon. And that is, you may recall the context in which we talked about macros, and that was the package by Kashikawa Katsumi, Swift AST Explorer, that was in episode 25. You may recall that's a website that he set up where you can paste in a Swift source code snippet. And it'll give you so you do this, you paste this in on the left hand side. And on the right hand side, you see sort of like a, almost as if you do a, a, you know, in Safari's dev tool, you can see the HTML underlying the page. It gives you the past abstract syntax tree of the source code, and you can hover over the elements, and it highlights the source code that corresponds to those syntax nodes and that sort of stuff. I do remember that, yes. I think I even also linked to that in the newsletter. Yeah, you did. And the reason I brought that up at the time, and I'm pretty sure I mentioned it, was that I thought this is going to be really great for when you're writing macros, because in order to write macros, you're going to be using Swift syntax. And I thought it would be quite complicated to sort of assemble the syntax nodes that you need to, that you can modify and then you know, to create your macro. And the reason I thought that is because if you read the vision, the macros vision document, it lays out a number of different ways in which you can do macros. And I guess the two sort of most common ones or the most easily understood ones are lexical macros, which is like C preprocessor type macro expansion, where you effectively do like text replacement, right? You define something gets replaced in a preprocessor stage, and then the compiler runs and the other version, and there's a third one. But this one that Swift macros is actually using is syntactic, where you manipulate the syntax tree, syntax nodes, and then you create. So you have input that's valid Swift, and then you can modify it and you output different valid Swift. But at the time, I thought, well, okay, this is really great, but this is probably going to be a bit difficult to work with. And the really interesting bit is that it actually isn't. They've actually done it in a way that gives you the best of both worlds because with Swift macros comes a library, Swift Syntax Builder, which is a result builder DSL that allows you to assemble nodes by just taking little source code snippets. So if you have a very static thing that you want to do in your macro, you know, just expand something. And like, if you want to write an initializer, that's always the same to certain types. You can literally just paste the source code string as you would write it. And that is going to be part of that syntax builder. And you don't need to fiddle with any syntax nodes. You can literally just act as if it was lexical. and under the hood that gets passed into syntax nodes and returns. So you don't need to fiddle with the details. You can if you want to. And that gives you lots of powers, obviously. But in very simple cases, you can literally take source code and even interpolate stuff into the source code. So it's really, really powerful mechanism. I can only recommend watching that session by Becker Royal Gordon to get those details. I found that eye opening in how easy it actually is to get started with it and not having to delve into the details of Swift syntax, depending on what you're going to do. Obviously, that's very powerful, and that's something you might need or want to do later on. But for simple stuff, you can go a long way just with little source code snippets and stuff like that. So that's something I found really interesting and remarkable about how that's implemented. - Right, that's great. And the other thing about macros that was probably just worth mentioning is, I think you asked the question on the last episode, did I think that there would be any secret features of Swift that would drop alongside whatever was announced last week? And turns out that actually macros was the key feature that everything that was announced last week used, right? So there was nothing else needed. - Well, and it was secret for us, right? (both laughing) - Exactly, yes. - I don't recall anything else in there. I haven't caught up on a lot of sessions to be honest. I've watched a chosen few because last week was a lot about adding actually Swift 5.9 support to the Swift package index. So I was a bit... - Well, that's it. And let's talk about that for a second because as we speak, the build machines that we have in various data centers around the world are currently crunching through, is it about 70,000 builds to test compatibility with Swift 5.9 with every package on every combination of platform and then obviously the new Swift version. - Yeah, yeah, exactly. It's a bit more than 70,000, but off that order of magnitude, I think we're about a third, well, we should be well over a third through now. It was a third this morning. So by the time you hear this, we're probably done with it. Probably done, yeah. Yeah, and thankfully, it's getting a bit easier to set this up every time we have to do it. There are some really tedious aspects about it, and we've sort of managed to whittle those down a bit and make it a bit easier to adopt new versions. Still, I'd hope there aren't more than two versions per year that we need to adopt, but it is getting a bit easier, which is great. Yeah, and I think the main reason we briefly discussed whether we should pull the trigger and add it early because last time 5.8 we waited quite a bit. We didn't add anything during the beta phase. But macros actually were, I think, the main reason we did it this time because I think it's going to be really nice to be able to search the Swift package index for packages that have macros in them so you can explore a what 5.9 offers. And obviously for that to work, we need to support 5.9. - Right, yeah. And we'll also start displaying. So at the moment we currently display three different product types on the package page. We display the number of libraries in the package, the number of executables, and the number of extensions. And we will now add the number of macros in there so you can see for any package, all four of the different product types and how they apply to what's in the package. But I think it's kind of, there's always a dilemma with adding new Swift versions of if you add it at beta one, then obviously we do this huge backlog process and everything goes, we determine the compatibility information for all the packages using a beta one compiler. And we're not gonna run that whole process for every single beta that comes out. And so it kind of relies on people actively developing packages if they want new beta update compatibility because we will only rebuild their package if they release a new version or move the default branch forward or something like that. And if there are any changes to Swift inside this beta cycle, then we either do the whole big backlog churn again at the end, or we just kind of say, well, your code will have been compiled with one of the betas. - Yeah, I think it's fair during the beta process just to let it sit. And I think a lot of the active packages automatically have changes of one sort or the other. During that time, we can probably, we should probably, we should consider just rerunning everything once 5.9 releases out. - Yeah. - But I think during the beta phase, that's fine. Plus, recent years, honestly, I think the changes between betas aren't dramatic. It's probably more around macro implementation sort of things that get sorted out, but we're not actually testing those bits anyway, right? When we build a package, the macro definition doesn't even get tested. So that's, it's a bit like plugins, right? There isn't, there's a bit of a, it's a bit of a weirdness in what kind of package is that in terms of dependencies, right? We don't have a mechanism to actually honestly test a plugin or a macro in that sense. I wouldn't even know how we would do that. Like we do for package building in general. - Yeah. We live in an imperfect world. What can I say? (laughing) There we go. The other thing that came out of the conference, which we actually had a issue, sorry, not an issue, a discussion opened by Get Gunders yesterday about the privacy manifests and the package support for privacy manifests. I actually watched the session video this afternoon for that. And I think it's just worth talking about that as well, because that is a very obvious feature for us to add into our package page. So just to catch anyone up who hasn't seen that session video yet, the privacy manifest that you can now embed within a package give, well, let me back up one more step actually. So if you have an app and you are filling in your privacy nutrition label as you submit your app to the App Store, One thing that it is currently your responsibility to do is look at every single one of the third-party SDKs that you're using and try and determine what they're doing in terms of privacy. And usually that involves reading through terms of service and lots of very vaguely written documentation. - The fun stuff. - Yeah, exactly, yeah. No documentation, legal jargon. And so the new feature is that SDK authors may now encode the things that they are doing related to privacy in a privacy manifest and include that in their SDK package. So fairly shortly, within let's say six months, we are going to get packages increasingly include these files And it's a really great feature for us to add to the package page. The more I watched of the video, sorry, it's a short video. I would recommend watching the whole thing, but it became clear to me very quickly that there was enormous amount of data that package authors can put within that file. And so we certainly can't summarize it on the package page itself. We may be able to give some kind of representation of like this package indicates that it does 13 things or something like that, or maybe we just have to say this package declares some privacy implications and have that be a link to a documentation, not a documentation page, but a full page of what we're passing out. But actually I think that brings me on to one other point which is that obviously the PLIST file of this manifest is encoded with key names and that kind of thing. we're going to have to have all of the descriptions and definitions of each of these keys baked into our app somewhere because I don't think there's an automated way to convert those keys into something readable. There is for the full application. So you can say with like an Xcode project, gather together all of my dependencies and give me a privacy report that I can then submit to the app store. But I don't think there's a way, And that seems to be in a readable format, but I don't think there's a way to do that for an individual package. - Right. - Maybe there is. - Right. I wonder if SPM might have tools to gather those up because I could imagine that on the command line, you would want to do it, right? Xcode can do it, but often there's an Xcode build command. Perhaps, I mean, SPM would be even better offering the same thing. That would be nice. In terms of displaying it, I was under the impression that it is effectively, it represents the same thing that you can see in the app store under the privacy and nutrition labels. So I thought that might be a way of distilling these bits of info together, but I might be wrong. - I think, I mean, certainly those privacy labels are derived from the data in this file, but it's not a one-to-one mapping of keys. I, as far as like, and I'm, I'm 12 minutes into my research of this by watching that video. So I am speaking from an extremely uninformed viewpoint here. But my, my impression of what I saw in that video is that there are, there are more detailed keys in there that some process narrows down to one of those nutrition labels. And I'm not sure whether that process is public or private. Right. Yeah, yeah, yeah. I got that sense too. I was just, I am thinking though that we could, I mean, it would be duplication of effort. I mean, unless there is a way to actually get those results out of Xcode or Swift PM or something, I was thinking that we could do the same thing, right? Distill it down into a view that looks very much like the nutrition labels. - Yeah, and even those nutrition labels, if you imagine three of those nutrition labels on our package page, that's quite a lot of space to take up there. So I don't know, this is not even a declaration that we will work on this problem, but it does seem like something we should at least investigate seriously. - Yeah, I mean, I think it's great data to have if you choose dependencies. - Yes. - It's up there with license, I think, to have that sort of info there. There's even mentioned that there are certain, there are going to be certain requirements about certain SDKs. I don't know what the name was there. I think privacy impacting third-party SDKs. There was supposed to be a list of pre-screened. - Yeah, so there's a thing called required reason APIs. So this is to prevent fingerprinting. So this is a technique that various companies use to try and get around the tracking controls. So for example, if you look at somebody's amount of disc-free space, if you even get access to a microphone and record like room noise, I've heard that they track people on. So if you get a recording of someone's room noise, and then if they're on a different device, but with the same room noise, you know that those two devices are the same person. And yeah, it's awful. So there's lots of things that they can use to fingerprint a device that is not, you know, the official way of getting a tracking ID. And they were very clear in the video to say that that is never allowed. And what they've done is they've added a whole load of APIs now that you have to have a good reason to use. And again, you can use these manifests to document the reason you're calling the API that gives you the amount of free space left on somebody's hard drive. - Yeah. - And actually that brings me onto something else that's crossed my mind as I was thinking about this in the context of the Swift package index. And that is, would we increase or decrease, depending on which way we decided to do it, a package's score based on how much or little of these privacy implications they kind of include in their manifest? - Well, I think at the very least, the presence of a declaration should bump your score a bit, right? Because you give people... That's an easy thing to do because you give people information. We don't judge the content, but the presence gives people the ability to judge whether they want to add it or not. I think that's helpful and that should elevate a package. - Yeah, I think that's a great way to approach it because what you don't want to do is penalize people for being honest with what they're doing. Like if they are collecting a lot of data, that's like, it's better to know that. And I would feel slightly less comfortable reducing score based on how many boxes you tick in that privacy manifest. But I really liked the idea of just saying, well, if you've done, if you've taken the step to include this, you get a couple of points. - And with the rest we can deal with by adding filters, right? We could have a filter that allows you to only select packages that have no privacy implications. And then it's up to the person searching for dependencies to make those choices, make those trade-offs, whether you are okay with something that tracks or whether you don't want that at all. So I think those were probably the most relevant bits of WWDC for the package index. And should we move on to some package recommendations? - There's a couple of things that I- - Oh, there's more. - Did want to mention. Yeah, I wanted to circle back very briefly to 5.9 because one thing, now that we've added 5.9 and we're now supporting packages that are 5.9 only, there's a case to bear in mind, and that is around documentation generation. So if you add documentation to your package, what you typically do, you add the documentation target that you want to have documentation generated for. And specifically, you don't specify any Swift version when you do so. And that means we choose which Swift version we build your documentation with. Now, what we haven't done by adding 5.9 is changing which documentation version by default we build with, which Swift version we build your documentation with. And that remains 5.8. So if you don't change your SPI manifest, we'll generate docs with 5.8. Now, if you have a package that is 5.9 only, obviously 5.8, the builds will fail, there will be no documentation. So in that case, or if you're interested to build with 5.9, you should set the key in the SPI.yaml file, Swift_version 59, which then would opt into building the docs with 59. So that's a little thing to be aware of. You also might want to change that back once 59 goes live, so you're not stuck on 59 later on. - Yeah, this is what I was gonna mention actually, is that when we ask people to make this kind of change, it's easy for them to make this kind of change because they need the feature in Swift 5.9 at this point, then 5.9 gets released and nothing bad happens because they are still on 5.9 and everything's happy. And then 6 comes out and they're still building with 5.9. - There's an easy service we can think of depending on how many people that do. We could even consider alerting people or even automating pull requests, I think, because we know which packages opt into. We do. A 5.9 documentation generation. And we have lots of packages that generate docs, but it's also not, it's not thousands, it's hundreds. And the 5.9 opt-ins might be, will be a lot fewer still. So there might be something there to help out. Plus, you know, obviously all the packages that don't specify tools version 5.9, which are 5.8 compatible, it can just leave everything as is and keep generating the docs as they are. The other interesting bit is we've seen a huge traffic jump in documentation overall, since WWDC. There have been a couple of packages announced that are very popular. More on that in a bit, I think. So it's effectively doubled our documentation viewing, which is great, like 20% of our traffic is documentation traffic right now. Yes, I predict we're going to talk about that in the next section. Indeed, we are. At least I've picked something there. So, we'll see how that goes. Shall we then? Yes, let's do some package recommendations. Do you want to kick us off? I can. And I can transition straight onwards to that package that is driving a lot of that documentation traffic and that is Swift OpenAI, not OpenAI, this trips me up so many times, Swift OpenAPI Generator. And that's a new package by Apple. There's a WWDC session about this, meet Swift OpenAPI Generator. What this is, is a package that auto generates your network interface from a, an open API JSON file, which is a file that many API's ship that describes the API. So effectively, you can ingest that file with this tool and it spit out, I think it's structs, but effectively, you know, like an API that you can then use to interface with that, that API. So you don't have to write any networking code, really. And that's really amazing. And what's what's even better, that package comes with really, really great tutorials, how how you set this up, how you use this. So if you're not familiar with open API, this yaml file or JSON file, it's actually available in both formats, what that means what that looks like, and how that works. It has a really, really great tutorial to step you through the process. Obviously, there's also the session that describes that. I think it's also just worth mentioning at this point that OpenAPI has been around for a long time. And this is not like OpenAPI itself is not new. This is Apple kind of embracing and making it easier to interact with OpenAPI specifications. Yeah. Chances are an API you're working with has an OpenAPI. Almost certainly. Yeah. JSON file. Yeah. So if it's modern, it should have, if it doesn't, maybe you can talk to the team. It shouldn't be many, many backend packages that the backends are implemented with actually have extensions that auto generate that file from that API that again, so you can actually, you know, generate code on both sides, which is kind of magical. But it's available for many, many packages, backend frameworks have that, ship with that or have extension that support that. So that's really great. It also comes on the client side with many implementations for networking clients. So, like, for example, if you're planning to use URL session, there's another package that builds on top of this that gives you all the APIs. When you're working with URL session, there's one for async HTTP client, There's one for vapor, there's one for hummingbirds. So for all of these, you have sort of ready made tools to get those working. And there's even another third party one that just dropped this week after WWDC request DL, which is a networking library by Breno de Moura, which is quite a nice networking package as well. It's a bit of a DSL. We had this in the past. we had a package that was a DSL to describe a query. This takes the same approach further. You don't just describe the query itself, you describe the whole networking request in a DSL. So that's also a package that I want to throw in and mention at the same time as this one by Apple. That's requestdl by Breno de Moura. So there you go, really nice set of packages for not just backend. So obviously this is more about the client side of developing apps that target APIs. And you tease talking about the documentation, they never follow through with it. So the nice thing about all these packages is that the documentation for them is hosted by Swift Package Index. And it's wonderful to see Apple trust us with the hosting of that documentation. and it's not something we take lightly in terms of that trust, because it would be very easy for them to think, well, we shouldn't trust the third party site, even though they are now a supporter of the site, but I think it's a really nice gesture that they trust us enough to host this documentation. And as Sven said, we've seen some increase in our documentation traffic because of it. Because these are new packages, people are checking them out, And in the read means there are links to the Swift package index hosted documentation for them. - Yeah, I'm really, really happy about this becoming a bit of like in my work, I see, I often go to packages that I know we use and look at the documentation through us, even if it's linked externally, I really like that there's as a single place, I know where to look to find the docs. I think I'm really, really happy about that development that we're not just about finding the packages initially, which is something you probably don't do all the time. Looking up docs, I really do all the time. Maybe even our own docs, like our SPI manifest file, I often go to that page through the normal route to the package page, to the documentation link, to the docs. - And it helps us, you know, the whole point of us creating this documentation hosting system was to make it trivially easy for people to host their documentation. Now, doc C doesn't make it hard to host documentation. You know, it comes with a command where you can transform your documentation archive for static hosting, and then you can stick it on GitHub pages and you can host it that way. And it's not an enormous amount of work, but I think one thing that we have done is that we have made it a trivial amount of work adding, you know, one word to a YAML file that you stick in your repository route. And what's really nice to see is that as more people start to trust that we're doing a good job with this and Apple being the ultimate kind of flag in the sand of like, well, if Apple are happy to trust it, I think that really just, it moves the whole ecosystem forward because if it's so easy to host your documentation and it's so easy to add a couple of comments above every type that you make, then we just start to enable a better documented Swift ecosystem. And there's lots of people all pushing in that same direction. And I'm just happy to be part of that. I think that's great. - Yeah, I think it's really great. Right, you wanna give us your first pick? - Yeah, my first pick is Coco UI by P-X9. - Is that the cousin of C3PO? - I think it is, yes. (laughing) Yes, there is a GitHub username, but even their commit author information is p-x9. So that's all we have to go on. (laughing) Thank you for your work, px9. So what it is, is a, it's actually similar to a package I've used in the past. And the package that I've used in the past is SwiftUI Introspect by Sightline, which is a company. And both of these packages let you dig under the covers of SwiftUI. So if you have a SwiftUI label, then it is likely, but not guaranteed, this is likely that under the surface, if you're running your application on iOS, that might be a UI label. If you're running on Mac OS, it will probably be an NS label. And so what these packages allow you to do is they allow you to say, if the backing of this control is a UI label, let me inspect and modify the properties of that UI label. And the reason I mentioned Cocoa UI specifically when I've already mentioned in the past and used Swift Introspect is that it adds a couple of nice little features, which is it has a few kind of extra features extra bits of syntax or actually view modifiers that you can add on. So for example, it adds some lifecycle modifiers. So you can say with a text, a SwiftUI text control, you can say, you know, .coco as a view modifier and get hold of the view controller, for example. But you can also add a view modifier for on view will appear and on view will disappear. And those kinds of lifecycle events, which may not be completely covered yet in SwiftUI. I mean, SwiftUI moves forward every single year and there are less and less reasons to dig below the surface of SwiftUI every year, but that doesn't mean there's no reasons to do that. And I think this kind of, this package, they're very safe. If they don't find the correct control underneath, they don't do anything. And so you don't really risk your application crashing because of using this kind of thing, but they do allow you that extra little bit of control if and when you need it. - Nice. Yeah, I did see that package and I was wondering exactly that thing because I do recall when I first looked or first saw Introspect, that there was a bit of a warning label in the readme if I recall correctly, you know, be careful this is exposing under the hood details which might change in the future. I did not see a warning like that in Coco UI. Does that mean it's safer or more stable, or is that just safe because it just won't do anything at all if there's something wrong with the uncovering of the details? - My understanding of both of them is that they will do nothing if they're not. - Right, okay. - There may have been a warning on Introspect maybe early on but certainly by the time I used it, so I used it for the iOS DevJobs application. - Right. - And by the time I used it for that, there was, if it didn't find what I was expecting, it would just do nothing. - Right, okay, I see. Cool. Right, my second pick is called Close Enough by Seth Eisenberg. And that's a really interesting and nice package. So this is for testing. And what it does is it ships a property wrapper that makes comparing floating point or floating point-ish values easier. When I bring this up, you are probably immediately thinking about, well, XCT_assert_equal does have an accuracy parameter where you can specify if you compare two doubles, for instance, within which delta the comparison should be considered equal, right? You can provide the accuracy, and then if they're that close or closer, they're equal. Which works great if you have a straight up double or float or something like that. The problem is if you want to compare structs that are equatable but they contain properties that are floats or contain nested types that contain properties that are floats, that won't work, right? Because you can't pass in that accuracy parameter unless your type is a floating point type. But what you can do with this property wrapper is if you mark properties with that, and my understanding is only in a testing context when you use XAT_asserts, you can then specify the accuracy on a type by type basis to consider that accuracy for those properties only. So you can actually use XAT_ASSERT_EQUAL, you don't specify any accuracy there, like individually, you specify it on a type level, and it'll filter through into the structs that you're comparing. I hope all of this makes sense. It's always difficult to describe this sort of thing in a podcast. If you look at the readme, it'll immediately make sense if you've ever done any comparison of structs having nested types with doubles, you know how difficult that can be and how annoying that can be to filter through that. This is a really great package to deal with this. Close enough by Zef Eisenberg. - Anything that makes testing more reliable and a little easier is good by me. My second one actually is similar to your first one in that it is an Apple published package. So the package is App Store Server Library and this is published by Apple. So a few years ago now, Apple published their App Store Server API and App Store Server Notification API. So you can, for example, manipulate the things that you can manipulate within the developer portal once you've logged in with your developer ID and also get notifications of things like when a purchase was made or, you know, there's various events that happen during the purchasing cycle that you can choose to be notified of on your backend. And there have been many third-party libraries that have dealt with this, creating a Swift wrapper around those online APIs. One worth mentioning is Bag Boutique by Morten Guggesen. And that's been around for a little while. And in fact, actually, ironically, that is generated from the open API spec that Apple published for their App Store Connect API. So, you know, this is all, we're all going around in circles here. But yes, Apple have now made an official Swift wrapper library around those two APIs. And it's the kind of thing that you probably won't do this from within an application, but you certainly will be doing it. If your backend is written in Swift on the server, this API is going to be very useful to you. And this library is going to be essential. - Was there a WWDC session that came with that? - Yes. I was wondering if that was introduced. - There was one, and I thought it was linked from the readme file, but it, oh yes, it is. So if you go to the documentation section of the readme file, there is a link to documentation, which is actually not hosted on Package Index. That one is on the Apple developer site, but there is also a link to the WWDC video, which is called Meet the App Store Server Library. - Very nice. Right, my third pick is called Swiftly by Patrick Free. This isn't a source code dependency package. This is a tool and this is a work in progress tool. It's a tool chain installer akin to Swift Env, which people might know or Rustop, if we're talking about different ecosystems. What this will allow you to do is install Swift. And the idea is for this to be the official tool to do this. So this is an SSWG project, the official effort to bring in a tool like that to make it easier to install tool chains on all platforms. Right now it's Linux only, which I find really interesting that that's the first platform that this ships for. And it's really nice. It's not fully done yet, but I did want to highlight it early because if you work on Linux, that's already a really useful tool because it can be a bit more difficult there to install Swift tool chains. So it does have install and use commands there, which means you can just give it a, pick a name, like there are shorthands for certain Swift versions, like five, eight would give you the release version. You can do 5.9-snapshot. It'll pull in the latest 5.9 snapshot and stuff like that. And then you can use swiftly use to switch between installed versions, which is really nice if you want to experiment. And all of this works in Docker, obviously. So that's a very easy way to play around with this if you're on a Mac even. In the future, there are other commands to come. So this is something that's actually different from Swift. and for example, which does some of this, it'll have an update command, so you can update a tool chain that you've installed in place. It'll also allow you to list available versions. So it's a really nice tool to work with Swift on Linux, and Mac OS obviously is in the works, so it'll come to Mac OS soon. I'm not sure what the timeline is on this, but it is in the SSWG, so if you're interested in progress, they do publish the meeting notes every month or so, so you can see what's planned around this. And yeah, it's now a project within SSWG and a public package that you can install. - That's fantastic, yeah. And again, like my comment about testing, anything that makes installing Swift on Linux easier is fine by me. So I think that pretty much wraps us up for another episode. We will be back in two weeks with more recommendations and maybe more features of Swift that we missed in WWDC that we forget, that we forgot about. Who knows, right? - Who knows exactly? - See you in two weeks, bye-bye. - See you in two weeks, bye-bye.