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.