Swift Package Indexing

just anything to keep the air moving a little. It's not often that we have to,

that I complain of hot weather in the UK, but it's almost 30 degrees in here today,

so it's not very pleasant. Speaking of temperatures and 30 degrees, I finally found a

reason why Fahrenheit is better than Celsius. So is this the John Gruber thing? Because

he was the one that convinced me, actually. Oh God, no, no, no, no. He has no standing.

The reason is, I have the calendar and weather widgets on my watch next to each other, and I keep

looking at my watch and I think, "Damn it, it's the 19th already. It's the 20th already in the

month." I thought we only just had the start of the month, and I keep looking at the temperature.

And if this was Fahrenheit, that probably, that problem wouldn't happen around here where it

hardly ever hits zero degrees. So it'd always be 32 Fahrenheit and above. So,

but I'm not going to switch anyway. I'm just going to have to train myself to-

No, I'm not going to switch either because it's too much, it's impossible over here to switch

into Fahrenheit because you'd be the only person using it. But I quite liked, this is years ago

now, I quite liked John Gruber's explanation of it, which is that it's a more human scale

for temperature. It is, you know, 100 degrees Fahrenheit is very hot and zero degrees Fahrenheit

is extremely cold. And so in the middle, you've got the human range of temperature. And I quite

like that, that spoke to me, actually. I thought that was quite a good way to think about temperature

in a way that Celsius doesn't make sense like that, because zero Celsius is kind of cold,

but it's not terribly cold. It's extremely cold. Like zero Celsius is like insanely cold.

That's because you live in the South. No, it's because I just can't deal with cold. And then,

you know, on the upper end, 40 is quite hot. So 40, 100, I mean, you can still,

yeah, it's all right. I think Celsius is fine. I think it's fine too. But that's not why people

are listening to the podcast, I'm pretty sure. Still not. So I think we should do a little bit of

relevant news and things before we spend the entire time talking about temperature.

I think there's just a couple of little updates on the project that are worth going over,

first of all. Some good news. Our Swift 6.1 processing is finished. And the problems that

we spoke about last time where we had the package list was letting packages that requires Swift 6.1

in, but the project itself wasn't yet building them. And that kind of all that mess that we had

with 6.1 is over. And not only is it over and we're accepting 6.1 packages, but all of the

processing for compatibility with Swift 6.1 has now completed. So that's great news. And I'm sure

you'll be happy to see the back of that problem as well. Oh, yeah. Yeah. That's a good result that

we got that done. We also updated the Ready for Swift 6 page with the latest numbers for the

Swift 6.1 processing. I was a bit surprised that there's still fluctuation there. I think it's

still not settled down what's getting marked as... I think there's an influx of new things that get

marked as errors with 6.1. I guess that's all just part of the process, right? Every time there's

going to be a little bit less of that, I suppose, and we'll land in a place where the errors go down.

Definitely saw an uptick, I think, in the number of packages without concurrency warnings. So that's

definitely good. Yes. Well, there were a couple of reasons for that, right? And this is why that

chart and that page in general is so difficult to kind of reason about because there are so many

moving parts in that. There are the compiler updates. There are people adopting Swift 6

and currency... Oh, sorry, Swift 6 language mode. And all of those things are moving forward

independently of each other. And yet the chart only shows one number, which is always a little

tricky to reason on that. But also included in the Swift 6.1 release was the fix for

incorrectly identified concurrency errors. So there were some packages with Swift 6 that were

showing concurrency errors, and we were reporting those concurrency errors. And we've talked about

this on the podcast in the past. We were reporting those numbers correctly, but the numbers themselves

were incorrect. And they are now fixed in 6.1. And so we're not only... It's actually three

dimensions of movement now that you have that bug fix in there as well. You've got the compiler

moving forward. You've got people's packages and source compatibility moving forward. And then

you've got the fact that this bug was fixed, which correctly reports the number of issues

in a package. So I wasn't surprised to see the total number of packages that have zero

data race errors increase. But I think that second chart of the total errors is... I don't

think that's providing a lot of very interesting information. - Yeah. One other wrinkle that I

noticed, and I was a bit surprised by it, is that I tested a couple of packages which have

zero errors, like both when I run it and as reported in 6.0, like when you compile with

Swift 6.0, but do have warnings and errors that we correctly report as such in 6.1. So there seems

to be something in 6.1 that raises new Swift 6 language mode errors that didn't before. And that

was surprising to me. I thought in general, the expectation is that that isn't going to happen.

But it looked legit. Like I looked at it, there were clearly warnings or errors issued by the

compiler when I ran it on the packages. And I suppose the packages need to make adjustments.

- Right. Yeah. The last little data point on this that I thought was worth pointing out is... So we

have three lines on each of the charts on this Ready for Swift 6 page. And we've moved the kind

of large link to this page off the home page on the Swift Package Index now, but it is still linked

at the bottom of the page under Ready for Swift 6. And we'll also include a link to it in the show

notes. But there are three lines on each of the charts, one for all packages, which actually kind

of dwarfs the other two lines that we have, but you can untick the all packages line and see the

other two lines that we have, which are all packages authored by Apple and all packages

authored by the Swift Server Workgroup. And if you untick the all package line, you can see

something quite interesting, which is that there is a very definite trend in those subsets of

packages where people are obviously working on this problem. And both the Apple packages and

the Swift Server Workgroup packages have doubled the number of packages that do not have any data

race errors since the last run that we did. So not since the beginning, but since the last run

that we did, which was in December 2024, it's jumped from 26 to 54 for the Apple packages and

from 14 to 31 with the Swift Server Workgroup, which is, it shows that real work is happening

there. And that subset, I think, gives a nicer picture of what's actually happening, which is

that things are getting better. Yeah, definitely. Maybe we should say a word regarding that bigger

gap between the last collected numbers. And that's mainly at the time when we learned about this

reporting of false positives, we sort of stopped running this every two weeks because it felt like,

you know, we had more and more reports of people saying, look, we don't have any warnings, but

you're showing some. So we thought, well, it's actually not worth running it because the ratio of

false reports seem to be quite high. And I think now we've sort of reached a point where

it's enough to do this when there's, you know, new Swift point releases. So I, you know, Swift 6.2

will presume, well, that's a full release. So, and I think that might be enough.

Yeah, so we'll get a beta of that in a month or so at WWDC, I would imagine. Yeah.

Yeah. The question is, do we even bother running the processing with a beta or do we just,

you know, run it in the final version in the fall?

The plan with those regular runs was always to do them for the majority of last year. That was our

plan in terms of when we would run those kind of repeated runs to check for data safety. I don't

know that the page is giving that much useful information anymore. I think it served its purpose

last year and it's not useless, but it is of limited value given that when we do reprocess

all those builds, it actually knocks our build infrastructure into kind of slow mode for just

over a week's worth of processing time, which is quite a heavy toll to pay. And so if it was

something that we could just do with no cost, not a monetary cost, but no cost in terms of the system,

then I would say, yeah, sure. We, you know, we run it every month or something like that, but

but it does have a cost. And so I think I'm more on the side of let's run it, let's take the

figures when we do the Swift 6.2 release, but not during the betas. Yeah, yeah, exactly. I mean,

I'm not sure how we did it last year. Do we adopt the betas during the WWDC week? I think we

end up adding it early, right? We don't wait until September to add 6.2. So there'll be some...

Yeah, but I could see us doing... If we add the beta over the summer, which we almost certainly

will, then when the final 6.2 release comes, I can see us at that point doing a fresh set of data,

but only that once. Yeah. Yeah, which we normally wouldn't. In the past, we haven't. When we switched

from a beta to a release version, we didn't rerun all the builds, but this might be a reason to

actually do it. It's sort of a week that it starts heating up the cluster. And we've also

made a couple of changes to still prioritize new package additions. So the impact shouldn't be

felt like... I mean, there is an impact, but it shouldn't punish new packages as much as it did

in the past, where it really puts you at the end of the queue, potentially. And that's not the case

anymore. Yeah. Yeah. We made that tweak to that, didn't we? Yeah. Yeah. So there we go. Swift 6.1

is on the site. The other tiny little bit of news that just warrants mentioning is that... I don't

remember whether we mentioned this last time or not. I think we may have done, which is that we

had to temporarily disable package collection signing due to a fairly complex and quite boring

set of circumstances, which we probably don't want to talk about here. But the good news is

that that's all enabled and back up and working and package collections are, as they were, signed

fully, able to be used without warnings in Xcode. So I thought that was just worth mentioning.

Yeah. I did actually notice that they wouldn't work at all if they're unsigned in Xcode. So

for that period of a few days, it might've been, I think it was less than a week in the end,

it didn't actually work, but no one complained. So that's good news, I suppose.

I get the feeling that package collections are not very well used. Certainly our package

collections are not very well used. People may have their own set. I think one good use of

package collections is if you have a set of packages in your company that are approved and

you can adopt them without anybody raising an eye to them, then make a package collection of them.

And they're right there in Xcode every time you need them. But keyword package collections,

which is what we implemented, I don't get the sense that they're very well used at all.

Yeah. Plus I think it would have only affected you if you wanted to add them fresh. I think

if you had them already, it wouldn't have done any harm. So it wasn't a big deal, I think.

Anyway, it's all fixed and back up and running. So that's great.

Right. Well, in terms of non-project news, there's one thing that we could briefly talk about,

and that is a tool that's been mentioned and announced on the Swift forums, and that's called

Xtool. And I wanted to give a shout out to that. It's a tool to bring Xcode to Linux and Windows.

That's what it says in the announcement. It's been around for a bit, I think, and it's now

been formally announced. The idea is to be able to build and deploy iOS apps from non-Apple

platforms. Now, there's one thing to be mindful of, and that's also been mentioned in the Swift

forum thread where the project has been announced. There are licensing restrictions around how and

where you use Apple's SDK. Now, I am not a lawyer, but you are potentially towing a legal line

here when it comes to using this tool on non-Apple platforms. I think you're okay if you

use it on Apple hardware, even if it's not Mac OS, so that might be all right.

I think if in doubt, it would be useful to clarify the situation before you go off and

invest hugely in this. I think you should be fine if you just want to try it out.

But before you deploy CI and that sort of stuff, I think it's best to check, maybe wait if there's

any clarification in the forum post. We'll obviously share the link. I haven't seen anything

as of today being discussed there other than it being mentioned. You might be having licensing

issues. But legal questions aside, the project looks really interesting. So, just the mere

fact that it exists technically speaks, I think, to Swift becoming a stronger cross-platform

language day by day. It's really exciting to see that this is even possible. And the project looks

really nice. So, there's extensive documentation. There's actually a detailed doc C tutorial where

it walks you through what you need to install. It's like brew, you brew install the thing,

then you sign in to your Apple developer account, how you connect your device. And it's like,

really, it talks about just plug your device into USB. There's no mention of this being a Mac or

you needing Xcode. It really just is a CLI binary that you run. And I really love the fact that it's

actually a command line interface. I do appreciate the GUI for something that I really know already,

like as a shortcut or as a convenience for something that I understand and I know how it

works. But I really find learning about something new, a command line interface is just fantastic

because the representation of what the inputs and outputs are, are to me much clearer in text form.

I find it much easier to see, all right, I type this and I get this back. And then I can replicate

that locally. I find that much, much easier to do than watching a video or looking at screenshots

and stuff. And I found that really nice that there's a tool now that does a lot of the things

that Xcode does graphically. I mean, I know there's Xcode Build that probably also does that,

but anyone who's ever interacted with Xcode Build's command line interface will probably agree

that a proper Swift argument parser command line interface is likely more comfortable to use.

So yeah, I think it's a really interesting project and I'm curious to see where this might lead.

- I think there's a couple of things I want to mention here. I think one of the

areas that is crying out for a tool like this is actually some of the cross-platform frameworks like

Flutter and React Native, where you still have to do those final builds with Xcode. You can develop

the software on any platform, but then you have to do the final build with Xcode on a Mac.

And there is just no solution to that, apart from get a build machine, which is a Mac.

Which for a certain segment of applications is a big disadvantage, not a big disadvantage for Apple,

but a big disadvantage for the people who are using those tools. And there are a significant

number of people and especially a significant number of companies, because as soon as you'd

have to justify writing two separate apps, one for Android, one for iOS, then those cross-platform

frameworks begin to look really tempting. And there's a lot of companies that use those

cross-platform frameworks all over the place. So I think that segment of mobile development

has been crying out for something like this, which is interesting to see what it will do to

those technologies. And then the other thing that I think is worth mentioning is,

and it has been announced because there was a post on the Swift blog in February by Owen Voorhees,

which is the next Swift build tool, which is presumably again, going to come

maybe even in a month's time at this month's WWDC. So that is the Swift build technology,

which, and I haven't looked into this in great detail. So maybe if you have, correct me if I'm

wrong here, but I believe that is effectively taking a lot of what Xcode build can do that

Swift build can't do, but also that that is going to be a cross-platform build tool as well. Do you

have any information on whether that's cross-platform? I think it is.

I'm pretty sure it is. I don't know to what extent it will tackle the other things that Xcode

build and Xcode do, right. And that Xtool does, you know, like the signing and the distribution

part. That's what Xtool actually does. You can sign your application. You can, I think it also

supports pushing the binary up. Obviously it does install on device, you know, that's the deploy

part at the very least. It might not be the app store deploy part, although I think it also does

that, but it certainly does the on device launching and interacting. I think it doesn't do debugging

yet, but it's, you know, it's small steps. And I mean, in my mind there has to be, I understood

this announcement of Swift build, this new Swift build to be the first steps in replacing what

I understand as Xcode build, you know, like the Xcode build command and all the machinery in Xcode

to build iOS applications, which is what you currently, you still need.

I believe the intention of it is to replace both Xcode build and Swift build. I think it is a

replacement for both of those tools. Yeah. Yeah. I mean, in my mind, sort of, it is an evolution

of Swift build because I think you invoke, you probably end up invoking it exactly the same way.

So for me, it's like Swift build version 2.0, whereas Xcode build is like very different,

right? It's like a replacement, which is something entirely, well, entirely different. I mean,

it's a command line interface, right? But still, if you, as I said earlier, if you've ever used

Xcode build in earnest, you can tell it's like a very different tool. It's not, you know,

a typical Unix tool in the way you provide parameters in the output that it gives,

because it just inundates you with output. It's like, you don't know what's coming if you start,

if you launch an Xcode build command, you're going to get lots of output. It's just very

different. So I'm looking forward to what this development will bring. I think it's a very

interesting project. And I, it was also on my list to talk about today. So it's good that the

topic has come up. Shall we do some package recommendations?

Yeah, let's do some packages.

Why don't you kick us off this week?

All right. My first pick is another beautiful UI related package by Rob Boehnke. It's called

Redline.

Oh, no, we're going to have potentially two.

I thought we had a conflict today, but it wasn't this.

Here we go. I think we're okay on the others, but we shall see. I just love this package. I mean,

I keep mentioning that I don't do a lot of UI development, especially not these days. But if

I was, this would definitely be something I'd use. What this does, it's a SwiftUI package that gives

you modifiers that you can tack on to views to show spacing, position, and size information of

those views in context with the surrounding views, size of the view itself. And it's just

beautifully rendered. Imagine these springs and struts where you have the distance spaces and

like beautiful, these round rec labels between them to show you what distance is between elements.

Little size insets where it shows you what the size of the element is. It just looks beautiful.

Look at the read menu. You immediately know what this is about and how to use the handful of

modifiers there are. I think it's like spacing and position size. It'll be very obvious how that

works. And it's just a beautiful package. And it's a dev package. Obviously, you're not going to ship

this with it being enabled. So it's a perfect tool to drop into your project to use in your dev

cycle. And then whenever you need to ship, obviously, it's not going to be present

anyway. So it's one of those dependencies that are really super easy to adopt because

they help you in your development. But they will never impact your shipping when stuff might be

problematic if a package isn't maintained anymore or for whatever reason it doesn't build anymore.

You just don't use it and you lose your ease of development, but you never put your

shipping at risk. And I think it's just perfect. >> And I know you mentioned already the readme

file there. But this readme file is the best example of a picture is worth a thousand words

that I've ever seen. The readme file starts with a 20-word sentence that describes the package,

which your eyes actually drawn over that because there is a huge screenshot immediately below it,

which explains everything you would want to know about this package in one screenshot. It is

brilliant. And as soon as I saw that, I thought, oh, what a great looking package. And then I

investigated a little bit and had a look at the code example underneath it. And yeah, I agree.

I agree with everything you just said there. I mean, Rob has made a lot of packages that we've

recommended on this podcast. And so I don't think it's quite as many as your point three

recommendations. But I think he's certainly up there with the potentially second place in terms

of how many packages we've recommended there. But again, I have no hesitation from recognizing this

as just a fantastic thing to check out. And as you say, it just has no downside because you're

not going to ship it. So it's great. Yeah. Isn't Rob also the person or part of the team who

developed an extensive animation UI library? Yeah. I recall seeing posts of his that are just

beautiful. They show you. Yes. Like it's just fantastic UI work that that did you do you know

what it's called? I can't recall the name. I think it was a commercial. I can't remember the name

either. But you're right that that is the same Rob. Yeah. Right. There you go. Redline by

Rob Boonker. Well, my first package is Redline. But no.

Well, I'm going to put my so I thought we might have a clash today. So I'm going to do my

my other potential clash next so that we both potentially get to do at least one unique one.

So the package I'm going to talk about is called Harmonize by Peristreet Software.

And the reason I thought we were going to have a clash is because you added this package to the

index. It wasn't the author who added it. It was it was you that added it. And so I thought the

reason you'd added it was because it was on your shortlist. Was it? It is on my extended list. I

think it was announced on the Swift forums and I sort of tend to if I see something,

I sort of plug it in if we don't have it already. I thought this was interesting. So the basic idea

here is I'm not I'm not sure I actually agree with the official description. The official

description is that it's a modern linter for Swift that allows you to write architectural

lint rules as unit tests. I can see why they would describe it as a linter, but I think it's

a little bit different to a certainly the way that I think about a linter. What it allows you

to do is encode rules in your unit tests for how your project is structured. So, for example,

if you wanted to make sure that every view model class that you had was inherited from a base view

model, you could write an assertion in a unit test that checks that in your source code. And so it

allows you to encode your kind of organizational structure, your development structure into rules

in your code base and and then have that run as part of your CI so that you never get that problem

of forgetting to do something that might not present itself as a problem immediately, but might

present itself further down the line when you've realized you haven't, you know,

followed one of these rules that you have. And it allows you to basically get references into

your code and get lists of your classes in a very easy way and then write logic into those

unit tests. And I thought that was quite a unique idea. I hadn't seen anyone do anything like that

before. I believe there is a project originally written by Orta Throx, who was one of the founders

of CocoaPods called Danger, which is the same kind of thing, which is you're encoding your

best practices into a separate process that you can then enforce with continuous integration.

And that's the only thing like this that I've seen before. But I thought this was worth mentioning

because of how relatively unique it is, even though you can't have a relatively unique thing.

- Yeah. Yeah, I found that really interesting too. I was sort of wondering if there's an added

value in having it as a Swift test. I mean, obviously it's easy to run, right? Because

you know how to run tests already, or you should. And then there's very little to learn, right? How

do you, you know, don't actually instruct anyone where we have these rules, make sure you run them.

It's almost harder not to run them, right? If you run all the tests, it's going to be a part of it.

- Of course.

- So in that sense, I think that's a really strong argument to have it that way. I wonder if there's

sort of rules that you can't do that way, because I suspect, I mean, it has to run like something

like Swift syntax to understand your code. But I think all the other linters pretty much do the

same, right? I mean, I'm not sure if they all use Swift syntax. I think some of them are regx-based,

but I wonder if that's equivalent, right? If just the fact that the examples are Swift syntax-based

doesn't mean they would have to be, right? I would imagine even if it was, if you wanted

regx-based rules, it is probably also possible to write those in this mechanism. I'm not sure

if they have support for that or if that's something they consider, or if that's a limitation,

I'd be curious about that because if it's not, I think that's the best argument to use that over

the others, because you have so much less explaining to do, right? And maintaining to do

in terms of how do you actually, you know, run this extra stuff. And I think that's a really

potentially compelling argument for that sort of tool.

- I don't know how it handles things. I mean, it probably doesn't is the truth of it, but

handles things outside of code, basically. So one of the things that Danger can do is make sure,

for example, that you've added an entry in a changelog when you submit a pull request,

that kind of thing that is outside of your code base, but still very important. If your

organization has chosen to make that a rule that you must add a line in the changelog when you

write a pull request, then encoding that in something that can get run through CI is difficult.

And so I think Danger probably has a broader set of uses, but as I say, I thought this was

worth mentioning. And this probably does stuff that you would struggle to do with Danger. Like

you say, you're not relying on regular expressions. You're actually dealing with the code in Swift.

- Yeah. Yeah. I don't recall. Now, Danger was, I think, originally at least, like it's JavaScript

based, right? And I think it had Swift extensions where you could write stuff in Swift as well.

- I thought it was Ruby.

- Oh, is it entirely? Oh, Ruby? Yeah, something.

- Although maybe, no, I think actually it is, I think you're right. I think it's JavaScript.

I'm just looking at the website now and the code that I can see looks more JavaScripty than,

well, it is not Ruby. This is JavaScript, yeah.

- So, yeah. I mean, I think there's some overlap, but I think they're also different, you know,

as in Danger supports things that are outside your source code, really. It's more like organizational

linting, you know, like organizational rules that go beyond source code rules. And I think

there might be value in actually having those a little separate because one of them is probably

going to be really tied to your CI system. So, if you're offline, for instance, they might not make

sense because they interact with GitHub, whereas source code rules could run at any time, right?

They could, all they need is the code base itself to establish that the rules are being followed.

And they could be just a component in something that sits on top and makes sure that that box

is ticked in the complete rule set around your pull requests and stuff.

- Yeah. So, well, let's make it a double recommendation then. Harmonize by

Peristreet Software and also Danger, and we'll include links to both of those in the show notes.

- Excellent. All right. My second pick is called Swift Mocking by Grey Campbell.

Now, Swift Mocking is a collection of Swift macros used to generate mock dependencies. And

we've talked about various ways of mocking tests in the past, but I think one of the most common

ways is really to create a protocol for your functionality and then inject a dependency

as a conformer to that protocol. So, you know, you might have networking and then you have a

protocol that defines your networking calls. And typically you'd inject URL session as your

live version of your functionality. And then in your test, you insert, you know,

inject a mock that also conforms to your networking protocol, but implements it very

differently. And typically, you know, without any logic, it just has state and allows you to

control its internal state and also what it returns when, you know, functionality on it is called.

But setting this up can often be quite tedious because you sort of end up having to conform to

a protocol twice, right? For your live version, you know, if it's not like URL session, if it's

one of your dependencies that you're trying to mock, then you have to implement the live service

and then also have to do quite a bit of setup around your mock. You know, you need to

edit for all the functions that you want to stub, and then you probably need to keep some internal

state, what these functions do, you know, store the parameters that they're getting, for instance,

in order to inspect them later on, act on them, that sort of stuff. And that's where this comes

in because it's a macro that you just attach to a protocol, and then it will generate all this

for you. It'll generate the stubs that conform to the protocol and keep the state around and give you

for free hooks into that state and into the calls and the responses so that you can actually set up

your object as you want, right? You might say, well, if you get a network request, always return

a 200, right? Or always return a 404, and then your test can handle what happens in that case.

And you can also inspect when a call comes into your network. For instance, you could inspect,

well, what's the URL this has been called with and what's the payload and ensure that you're

setting up your network calls correctly, for instance. And that's all implementation you

normally have to set up, and this macro will give you that for free and sort of type all this out

for you. And the reason why I think this is an interesting project, and I'm sure it's not the

only one, it's the most recent one that I've seen, is that I recall early on when Swift was newer,

one of the criticisms was it's a static language and it really prevents us from doing things like

this, for instance, like mocking, because typically in other languages, it's deployed

dynamically. So, like, you have an object that you want to mock, and then at runtime, the thing is

inspected and everything is rewritten on the fly. Like, reflection is being used to see, well,

what properties does the thing have? What functions does it have? And then these are sort of, you know,

like in Objective-C terms, swizzled and replaced at runtime. And that Swift can't do because it's

static language. I mean, there's some means of doing stuff like that, but it's sort of hackery

and not well supported. But with macros, that's actually not the case anymore, because effectively

that can be done at compile time, just by a lot of typing and the macro system does all the typing

for you. So, you actually get the best of both worlds, right? It sort of appears to be dynamic

because it knows how all of this needs to be done. It doesn't need to do it at runtime because it can

sort of reflect in advance, if you will, by looking at the type declaration and type it all out for

you, what normally would happen at runtime via discovery. So, we're sort of closing a loop a bit

with a macro system where a lot of the things that early on were missing because Swift wasn't

dynamic enough are sort of now filled in by the macro system, you know, pulling it back, so to

speak. And I think that's a really nice thing to see. We all do know that there are some downsides

to macros still because of the compile time cost you pay, but hopefully with Swift 6.2,

we see some change there and then it's just a win, you know, all around. So, yeah, there you go.

This was also on my, not on my main list, but it was on my extended list,

which I'm glad I didn't pick it because we would have literally clashed with everyone then.

But yeah, I thought this looked really interesting. And like you say, I think the fact that

macros do have that cost to them at the moment, I think we're about to see a lot more use of macros

when that cost goes away. And I really consider the launch of macros to be whenever we don't

have that cost because they do feel really quite heavyweight to kind of, they feel like a heavy

thing to include at the moment. And so I'm very hopeful for what we'll see macros do. I think

we've only, let me put it this way, I think we've only seen the start of what people will use macros

for so far. Yeah, yeah, definitely. I think the other thing to be a bit wary about with macros is

if something goes wrong, it can be difficult to deal with errors in macros. You know, if you have

like, if you have a bug in the macro, or if you're misusing them, it can, because you might have to

look at what the macro actually typed out, you know, like the expansion of the macro. And that

can be, that can be a lot. But you can see. Yeah, you can. I mean, it's nice that you can actually

see it in line. I love that. But the thing is, because a lot of the stuff is, I mean, it is

generated, but it also has to sort of, in order to avoid, you know, like, for example, name clashes,

you often see really strange names, because the designers have to step around your code a bit,

right? If you name certain things, certain ways, they have to make sure that they don't clash. And

then you end up with, like, really weird type names and stuff. So it can look really weird,

if you look at macro code, almost as if you looked at, you know, like, it's not assembly, but

it is certainly not your typical Swift code that you look at. But I've had cases where

it really helped. Like I was using a package in early on where it was being developed. And I was

using, like, I was example was type throws, and the macro package wasn't really written for type

throws yet. And I got compiler errors that I didn't understand. But then the expansion actually

helped explain why, why it didn't work and allowed me to find workarounds on my end or talk to the,

to the authors to find other workarounds. And that's, that's possible. But it's, it's also not,

it's not quite the same as drilling into source code that is that is written for a

programmer to read rather, because Swift's macros are written for the compiler to read and compile,

really, they're not, they're not really written for you to see or understand at a glance. And

that's something to bear in mind. And I don't think there's really a solution for that. That's

just the nature of the beast. Just as, as, you know, assembly is, that's just the nature of the

beast, right? That's what it compiles down to. This is sort of an intermediate step that is sort

of a bit more understandable, but it's it is lower level. And that's something to bear in mind as

well. Fantastic. I think I have one more package to talk about this week, which is Vault Courier by

Javier Cuesta. And you may have remember us talking about Javier before because Javier is

a previous participant in the Swift mentorship program, and did some fantastic work with adding

author support on Swift package index. So he added in every package page, you'll see the

author information, which is extracted either from the git history, or you can override it in your

spi.yaml file. And Javier was responsible for implementing that feature, which is great,

fantastic step forward for the project. But also now he has released this package, which if you

are a user of either HashiCorp Vault or OpenBAU, which are both tools for security, securely

storing secrets, API tokens, database credentials, certificates, tends to be as your project gets

gets to be interacted with by more than just a few people, the secret storage and that kind

of storage becomes a problem. And there are several, both open source and commercial

solutions to that problem, of which HashiCorp Vault and OpenBAU is two of them. And so Vault

Courier is a client for server side Swift, or most likely server side Swift that can access both of

those services. And I know, because he and I have been chatting a little bit about this as he's

developed it. I know, this is a kind of passion project for him. And he's also put an enormous

amount of work into this. So I thought it was worth highlighting it here. If you are in that

situation, where we're actually not in that situation yet with Swift package index, because

we tend, we're still using kind of environment variables, that kind of stuff for our secrets.

But I think it's where projects kind of outgrow that mechanism, then this is the kind of solution

that you might be looking at. - Yeah, that sounds really interesting. Yeah. Nice.

- So we'll finish off with the server side Swift package, but I think that will be it for

this episode of the podcast. And we'll call it a day there. We will be back in three weeks time,

but in three weeks time, I think, let me just check the dates. I have a feeling that in three

weeks time, it is WWDC week. No, it's the week before WWDC. So we'll have one more episode,

and then the week after that will be the conference. - Fantastic.

- So we'll see you then. All right. - All right. See you then. Bye-bye.

- Thank you. Bye-bye.