Swift Package Indexing

I think the first thing I want to mention in this episode is I booked my ticket to the

Server-Side Swift conference. Did you book a ticket?

I did in fact book it. I booked the ticket, booked the hotel. The only thing I haven't

booked yet is the flight. So looks like we'll finally meet. Fingers crossed.

You're well ahead of me then because I haven't yet booked the hotel, but I do have a ticket.

And yes, it will be nice to both be in the same place at the same time because

you went last year and unfortunately I was not so well last year when the conference was on,

and so I couldn't attend. And then the year before I was there, but you couldn't attend

the year before. So we've nearly met at the conference twice now, but this year, this is the

one. This is the one, exactly.

Only took us five years.

It only took us five years, exactly. But just for anyone who is interested, it's worth mentioning

the details of the conference. Early bird tickets are still available. And if you have any interest

in Server-Side Swift, which if you're listening to this podcast, you probably do, then the

Server-Side Swift conference is 2nd to the 3rd of October, 2025 in London. And like I say, early

bird tickets are still available. There's no speakers or schedule up yet. In fact, I think

there's still an active CFP for the conference. So maybe you could even speak at the conference

if you're listening to this. Yes, the CFP still appears to be open until June the 30th. There we

go. So you may, if you have something interesting to talk about at the conference, submit yourself

a CFP, but if not, then consider a ticket if you've interest in Server-Side Swift.

Yeah. And if you're, as Dave said, if you're interested in Server-Side Swift development at

all, just get a ticket. You don't need to wait for the speaker list because the speakers will

be great. It was a great conference last year and the talks are, you know, they're certainly

very important, but also everything around the conference is really great. There's a lot of

time to catch up, socialize, meet people. I found it really great. Lots of people I'd only

interacted with online that I had a chance to meet last year. And the few that I didn't

manage to bump in, I hope to run into this year. And yeah, same for everyone else. I think it's a

great venue too. We should mention this is happening at the Science Museum in London.

So even if you don't want to talk to anyone at all, you can just roam the halls and look at the

Lunar Lander and stuff like that. Look at old airplanes and stuff, but you should talk to people.

Yes, you should. It's definitely, that's the best bit of any conference. The year before last,

I actually did a small presentation at that conference and the venue is fantastic. Of course,

the Science Museum is wonderful, but it was in the, or at the time when it was two years ago,

it was in the IMAX theater there. And so my slides were projected onto an IMAX screen,

which is the first time I've ever had that happen. So that was fantastic.

Yeah, it's a great venue.

You don't really know what big fonts are until you've had them projected on an IMAX screen.

So that's that. I think there's also a couple of little bits of news from

the project over the last couple of weeks. First of all, we shipped two new compatibility platforms

for our compatibility matrix on every package page. So there was a blog post and we'll link

the blog post in the show notes, but we have added both Wasm and Android to all of our

compatibility checks. And it's been kind of interesting to see the results of those platforms.

They are significantly more compatible already than you might expect. Now, obviously,

whenever you have a package that relies on any of the kind of Apple specific platform UI kit,

Swift UI, AppKit, any of those kinds of things, you're automatically going to fail compatibility

with both Linux and Wasm and Android. But actually, I was pleasantly surprised to see that

almost 19% of packages are already compatible with Wasm and almost 28% are compatible with

Android already, which is kind of remarkable.

Yeah, it's great to have those platforms in. It was really surprisingly easy to actually add them

thanks to the Swift cross-compile efforts. So there's a... I think this was introduced with

6.0, like the SDK support. And now with Swift 6.1, Android came on board as well. And it's really

like you install these SDKs alongside your tool chain and that allows you to compile to the target

platform. So I think what effectively it does is sort of the SDK is a bundle of artifacts you need

to cross-compile like headers and additional libraries and stuff. And then you can run on

your host platform and compile to the target platform. And because we've already been running

Linux builds, it really meant just creating almost like a variant of the Linux build in both cases,

because the builders are Linux-based in those cases, and you install the additional SDKs and

you just compile to Wasm and Android. And yeah, it took some testing and stuff, but it was easy to

add. And like every year, I just hope that at some point we'll even get to something similarly easy

with the Apple platforms, because we still have to wrestle whole Mac virtual machines for all of

those platforms. If those SDKs also had something like that, that would be amazing and make it much

easier to run these compatibility builds across the board. The big one, of course, that's still

missing is Windows. And that is something that we would both love to have on that compatibility

matrix, which would take our number of platforms from eight to nine. But we do still have a couple

of technical issues. The software that we've built to run the builds that we use for compatibility

testing has a couple of dependencies that are not yet compatible with Windows. And so that would be

quite a lot of work to work around those dependencies. But also, we would need to flesh

out an entire Windows build infrastructure, which is something we don't have. And unfortunately,

we're on the verge of losing our Microsoft Azure sponsorship. So it's also not something that we're

able to kind of put a whole load more resources behind in terms of that build infrastructure

right now. So it's definitely on our minds. We'd love to do it, but it's not in our short-term

future, I don't think. Yeah. Yeah. Unfortunately not. It's interesting how often it actually comes

up. Windows support is being requested quite frequently. The main dependency we're lacking

is Swift Neo. And I do know that there's interest in actually porting that. I know the Vapor folks

are sort of interested in that as well. They have lots of requests, surprisingly,

for Vapor on Windows. And that's obviously a dependency for them as well. So I'm confident

that'll see changes at some point. It can't be too far off. There's a lot of interest in Windows,

and I think we'll get it sooner rather than later. Fingers crossed.

Yeah, absolutely. And then, so we've actually published two blog posts in the last two weeks,

which the second one was a little celebration of our five-year anniversary of the launch of

the Swift Package Index. So we launched just before WWDC 2020, which if you remember,

was actually a little delayed in 2020 because I think there was some global event happening

or something like that, but I forget now. So WWDC was a little delayed, but we launched just before

the conference in 2020. And we published a little blog post with some statistics and some

kind quotes that people gave us about the Package Index with a couple of graphs showing how package

growth has happened over the last five years and how much documentation we host and how many builds

we do and all sorts of stuff. So again, I'll include a link in the show notes to that blog post.

Yeah. Yeah. And on that occasion, thank you to everyone who's supporting and using the project.

It's just amazing to see how much it's grown. We started with, was it 2,500 packages? It's 9,000

now. I mean, of course, it's not a lot if you compare it to other ecosystems, but it's a lot

of growth in those five years, has a lot of really interesting and fun packages and helps. I use it a

lot, actually, the site itself to find stuff and not just because of the Swift Package Index, but

just of work in other aspects of the project itself, but also sometimes when I try stuff,

it's a site I use often. And interestingly for me, use has shifted to looking at the documentation

pages much more. I think if I had to say what I use the site for has dramatically shifted towards

documentation. And I think that that's really a testament to the efforts by the community to

actually add documentation to their packages. I'm constantly amazed how high the ratio is of

new packages that are being added with documentation opt-in and the quality of

the documentation in particular. There's lots of packages that have good documentation and some

have amazing documentation with tutorials and migration guides. It's fantastic work being done

there. So yeah, thank you, everyone. Yeah, absolutely. Thank you so much for

not only using it, but the people who also sponsor us through GitHub. That's incredibly

important to this project being as successful and available as it is. So it's been a fantastic

five years of running it. So thank you very much. Here's to the next five. And then some.

Exactly. Yeah, exactly. Yep. All right. I think there's another big thing happening this week.

You just mentioned it like five years ago. Yeah, five years ago, we launched just before

WDC. The actual five year anniversary is probably exactly on the day this podcast episode will come

out, which is in the middle of WWDC 2025. And yeah, we've had an interesting keynote yesterday

on State of the Union, I think. Did you sacrifice any of your devices yet on the beta alter?

Or did you? No, not yet. So we should mention that we're recording this on the Tuesday. So that's,

yeah, as of today, we've only seen the keynote and the State of the Union. Although I did notice

that it appears that every session video has been released yesterday. So I have a feeling.

Yeah, I have a feeling that unlike previous years, whether you a few every day throughout the week,

I think they've just dropped the entire set this year, which is great. But the only ones I've

watched so far are the keynote and the State of the Union. And I haven't yet sacrificed any of

my devices. The only thing I've done so far is install Xcode 26. Yeah, which is, well, actually,

before we move on to what we thought of the thing, I read a blog post today by Daniel Seidey,

who made the case as to why the unified OS versioning is a huge advantage to us as developers.

And it's basically around all the availability checks for things like SwiftUI, where you might

say before you declare a function or before you use a function, you might say when available on

iOS 18, Mac OS 15, TV OS 18, watchOS 11 and Vision OS 2, you now will presumably just be

able to say, yeah, you can now say, please check for OS 26. And that covers everything now, which

I think that's one practical advantage for developers of the naming system changing.

It will take us a little time to get used to that naming system change. But I think

it's a good thing because generally, you do want to, when you're doing those availability checks,

you do want to set everything with every platform at a certain year. So I quite liked that. And I'll

include a link to that blog post in the show notes again. Yeah, no, I think that makes perfect sense,

the change to years. The 2026 is a bit, it's not 2026 yet. I can see how they want to, not when it

probably hits the mainstream, it's going to be 2026. But then I'd argue you should have probably

also called it WWDC 2026, right? No, I think this makes sense to me.

WWDC is very firmly in 2025. But the operating systems 26 don't actually release until September

and October this year, at which point we are much closer to 2026 than we are to 2025. And so I think

it does make sense that the majority of the time that iOS 26 will be available, not in beta, will

be in the year 2026. Yeah, I mean, this is a lot like, you know, $9.99 pricing. It's like, it's

targeting psychology more than anything else. I would have made the same decision given, given,

if it was if it were a June release date, I would probably go with 2025. But given that we get access

to it way in advance of the people who actually going to eventually use it. I think I think it's

the right decision given it's September and October when they normally ship. All right.

All right. I thought the conference was good. Yeah. The State of the Union was interesting.

I actually I didn't quite make it to the State of the Union last night, but I watched it today.

Interesting changes to lots of the frameworks. We've got the new changes to Xcode, which are

good. One that I didn't expect was the Swift Assist feature to be in this year's version. I

thought that might be a little further delayed. And also for it not to rely only on the Apple

model for prediction. And actually it's more than prediction. It is.

It's not quite an agent, but it is a chat that you can have with an LLM about your code that

will also write code for you. But you can go backwards and forwards in that chat. It's

definitely more than code completion. Yeah. And I didn't actually see that called out. Is that

the Swift Assist equivalent? Because I don't think they mentioned Swift Assist.

I think no, I don't think. I think the words Swift Assist were very deliberately not mentioned

yesterday. At least I didn't hear those two words said at all. But from what was previewed as Swift

Assist the year before, this feels like an evolution of what that was.

Yeah. Yeah, definitely. It's great to see that they have the on-device models and stuff and

that you can very easily interface with them. I played around with it a bit. Foundation models,

it's super easy to use. I'd be interested to see the quality of it and what it can actually do.

Again, I just did a trivial thing and it's hard to judge them from just a couple of things. You

really need to gain experience with those to be able to judge them. But you can see how

in the future with more advancements, this is a really interesting and compelling

thing to have that you don't need to reach out. You don't need to fiddle with API keys,

that it runs on device without a network connection, without shipping your data off.

That's just massive benefits. And if it has quality that's in the ballpark, I think

that gives it a lot of weight. Even if it's not maybe the most cutting edge model, I think there's

a case to be made that it's a trade-off you might want to make in those cases. Plus,

you can still do the other thing if you really feel like you need the extra oomph, if it exists.

I'm much more excited about the coding support than the foundation models, just simply because

that's something I've been interested in for a little while in Swift coding and in non-Swift

coding, actually. I did a little experiment at the beginning of... Oh, no, it was the end of last

week, I think, that I did this. Are you familiar with Claude Code?

- Yes.

- Okay. So, Claude Code, if you're not familiar with it, is what they call an agent for writing

code with one of these LLMs, in this case, Claude. And I was curious to try something with it.

So, I actually got it to write me a Swift package this week, and that Swift package, I think,

well, it is in the Swift package index as we speak. And what I did was I spent about an hour

writing and refining with the help of some LLMs to help me do that, writing and refining a

quite detailed specification for the package. And then using a technique that I learned from

Peter Steinberger, who has been doing a lot of work with these agents at the moment,

I found it very interesting to basically pass this specification between two LLMs. So, I took it from

the one LLM and read it and made sure that it was correct and corrected a few things or added a few

things that I wanted this package to do. And then I passed it to another LLM and said, "Please find

me the weaknesses in this specification and ask questions about those weaknesses." And I took the

response of that and also then added some answers to those questions and then passed it back to the

first LLM and said, "Please integrate these changes into the spec." And ended up, after about an hour's

worth of work with what was quite a detailed specification for a Swift package to pass

a markup language called Critic Markup, which is an extension to Markdown where you can

mark additions and insertions and substitutions in written text. So, you can do like a little

brace and then plus plus and then a word and then plus plus and then the closing brace. And it knows

that you want to insert that word into the Markdown document. Think of it a little bit like

track changes in pages, but in a Markdown format. And so, I had it write this spec and then I gave

that spec to Cloud Code. I just said, "Please implement this, including a full test suite,

including DocC documentation, including Markdown files that include examples of DocC documentation,

as well as just the documentation for the structures and classes themselves." And it went

away and thought about it for probably 45 minutes, something like that, and spat out a package.

And if you look at... So, I was actually watching it do its work for most of the time.

And you could see that it was not only building and running the test suite, it was then kind of

refactoring the code it had written for better testability and then writing a test then to test

it and then running the test, make sure they pass, writing documentation. And after 45 minutes,

I had a package that was working, just kind of remarkable that it needed literally no intervention

from me at all. Now, I would want to test that package further. In fact, I hesitated before

adding it to the index because I haven't used that package in Angular, but I have used it in

a little demo application. And of course, the tests are there and the tests do what they say

they will do because there's tests. So, it was very interesting to do that. And so, the reason

I mentioned that is that what has shipped in Xcode 26 is a step towards that, but already,

and this stuff is moving so fast at the moment, that already what was released yesterday is a

little bit behind state of the art because that kind of stuff was a few months ago. And we are

talking like literally just a few months ago, but it makes a real difference for the LLM to be able

to interact with your tools in terms of, I think it's time to run the test now. So, I'm going to

run the tests and I'm going to look at the output from those tests and see if they pass. And then

if they don't pass, I'm going to look at the error message that it gave me and then rewrite the code.

And so, it's a real huge step along that path, which, yeah, I thought it was a very... I wanted

to experiment with it and I felt that was a decent experiment that I came up with.

Yeah. No, it's remarkable the capabilities they've gained. I mean, we've touched on this a

couple of times. We have slightly different points of view on the whole AI stuff, although I think a

lot of it is also aligned. I think it's... Initially, my main complaint was that it doesn't

actually work or didn't seem to work, but I had to revise that a bit. I tried independently. I

tried actually something just before Peter Steinberger came out with his blog posts and

the video about trying this. I had just tried Z, the Z editor has integrated...

Yes.

...Claude thing and I used it to write a script. When we ran the Android and WASM compatibility,

we did a comparison against the skip tools page where they list... They had run a compatibility

test themselves as well. And I wrote a little script to compare their list of results versus

our list of results. And you can imagine writing a script like that is not a big task. And it took me

a little less than 20 minutes to do it and compare the results and verify that it is okay.

And even before I started, I thought maybe that's something I should try, compare how I do versus

how Z with Claude does. And obviously, if I was to do that, I had to do it myself first because

what's the point watching the thing and then it's then harder to do it yourself when you have a

finished thing. But interestingly, once I'd finished writing the script on the same day,

I pulled up Z and then I was looking at the prospect of describing to the thing what I wanted

to do after I'd just done it. And I couldn't even find the energy to start writing a prompt

to tell it what I wanted to do because I had it, I had just done it. So I said, "No, I'm not going

to do this. This is silly." But then the next day I was sort of fresh and I thought, "All right,

let's let's let you know, fresh new day, let's go and do it again." And I honestly, I'll admit,

I didn't think this would actually work at all because from everything I'd seen, these sort of

wander off and do stuff. And like a Swift script, this wasn't even a package. This was a Swift

script. I think I might've turned it into a package. I don't remember. Anyway, it wasn't

a trivial thing. I mean, it wasn't a super complex thing, not anything like what you've done or what

Peter has done. But still, I thought this would be too complicated for this to understand what I want

because there were a couple of things that were kind of tricky. Like the two input formats were

adjacent, but they were different. They weren't structurally the same. Not even, you know, one

was an array, the other was an object with leaf items and stuff like that. So it was more than a

absolutely trivial task. And I didn't think it would manage. And it did manage. And it managed

in a form that was acceptable. I had no complaints. I ran a couple of additional

iterations, told it, "Look, we should refactor this a bit and this a bit."

I was done after 10 minutes. So I was faster with the thing. I think the only thing

where I benefited from having done it before myself was that I caught a couple of edge cases

while I was doing it. And that's the problem I have with these tools. I wonder how much of an

edge you lose thinking about your problem deeply when you're not actually doing it. I noticed when

I ran the results after I manually compared them that the numbers seemed low. And I realized that

the URLs that were compared were actually, they had different casing. And that's a rather trivial

thing to realize and know, but also because we've had this situation in the past. So all of our

comparisons with URLs are always lowercase and then compared for that reason. And so I spotted

that. But I also, I think I spotted that faster because I had actually just written the map and

the comparison. And you are in the vicinity of the issue when you're in that mindset.

I think if I just sit down and, "Oh, I want this compared." And then I look, "Oh, right."

You're more tempted to accept what you get. And I had the same effect with, it's sort of like the

the complaint dialogues. And you start clicking on accept. Like also when it wants to confirm,

"Can I run this tool?" Initially I had it always to confirm. And then at some point you give in

because you have this, your resistance gets worn down. "Why do I always need to accept?" "Yes,

you're just going to run Swift Build again." "Okay." So I click accept. And then at some

point I said, "Well, just run it. Just God damn it. Just leave me alone and run it."

And that's the thing that I fear most with the actual use of the tool is that my vigilance and my

awareness of what I'm actually doing is going to, it's like taking over a self-driving car.

You're never going to be able to take over when actually it gets critical, right? Because you're

not in the system. You have no state of the operation. Like what state is the system in?

Then you're supposed to jump in and take over. And that's what I find so hard. And I feel like

I really fear the losing capabilities and losing ownership and control over the system as a whole.

And I do realize that we've had this before. Every tool sort of removes you a bit from control.

People used to hand roll assembly, right? I have no idea how that actually works.

That's why I was interested in actually doing it. I wanted to do that experiment because I felt like

I can't just sit there and complain that these things don't work if I've actually never tried

it in earnest. So I wanted to understand because I don't think people like Peter

are making this up, right? And he's not the only one. There's others who've been using this. And I

think there's a scale. There's people who just blindly quote unquote vibe code and just have no

sense of what's going on. And there's people like Peter who are, he's an expert, right? And he's,

if you give me a jackhammer, all I'm going to do is ruin whatever I'm doing, right? It's not the

right tool for me, but there's people like Peter, you can hand a tool like that and he'll use it

responsibly and get amazing results out of it. So I think there's this aspect as well.

- It's definitely, there's definitely a skill to using these tools. That's a hundred percent

correct. And I've been using it for the kind of script that you were writing to compare those

results that you talked about. I've been using it for that kind of task for many months now. And I

was a hundred percent convinced that it was extremely good at writing that kind of code.

This is the first time that I've ever told it to write something from start to finish. And I think

your point about the edge cases and the things that you discovered while you were

writing your own version before you asked the AI to write it. I definitely found that with this

project through the specification phase, like the very first version of the specification,

when I read through it, it didn't make sense because I hadn't thought, and I'll be specific,

otherwise it's going to be very difficult to talk about. Critic markup has the ability to nest

critic markup inside critic markup. And actually when I told it to write the spec the first time,

I didn't realize that was even a thing, but it figured out that that was a thing in critic

markup. And then it just started making up how that should work, right? And because I hadn't

told it otherwise, but I hadn't, well, I didn't know that it was able to be nested. And so I

hadn't thought about that at all. And so in the revision to the specification, I made some rules

about what should happen with the nested markup. And actually what I said is that it shouldn't

support nested markup and it should just, anything inside a markup piece should just be treated as

the output. So that if there was nested markup, then it would just verbatim echo that as the

original text. But that thinking through of that specification process was really, really important.

And I think that's why it took me longer to write the specification than to write the code.

Yeah. Yeah. Yeah. I mean, it's certainly a shift in skillset. I'm not sure if I'm,

I'd be happier writing specs than writing code. That's the other thing. I mean, that's probably,

that really depends on where you land in, in what parts of the system you like. Like I love writing

tests for instance, and that's, I'm probably in the minority. So we all have different aspects

of a system that we like. Right. And I also find that's why I'm so a bit worried about offloading

these parts to the LLM is I often write a test and then I think of adjacent tests as I'm writing

that test. And I feel like I fear that if I don't write tests, I lose that branching out and

discovering edge cases that way. It might still happen in other ways. I'm just worried about that.

So one of my biggest complaints about this whole AI, and I resist to call it that still,

the LLMs is the aspect that I didn't trust them to work well enough. I think there's still areas

where they're too blindly deployed and taken for truth when the results, especially when the

results aren't verified and the person, the operator isn't actually able to verify them

and then still they accept the results. I think that's a huge problem. And then the other big

problem is the provenance. Where is all this knowledge coming from? And we've discussed this

in the past. And we see the effects actually on this with package index. We're getting hammered by

AI crawlers since end of last year and they come in waves and they're just slipping up all the

data they can find. And it's not theirs. It's not their data. I talked to my partner over the weekend

and I came up with this description. It's like people are using steroids and everyone else is

getting acne, right? Because they are using all the data's out there and boosting their own systems.

But everyone else is paying the price. If I actually insisted never to use an AI system,

LLM system to help my work, I'd still be affected. And not just the down the line effects because

people use LLMs to create fake news and whatnot. We see all these effects already like society-wide,

but actually tangible effects where our system is getting hammered by AI crawlers and our systems

are running hotter. We probably have to pay more for plans that are traffic related at some point,

if not already, because of that. So we are bearing a cost and it's not the companies that are

actually benefiting from the sales of these AI subscriptions eventually that are actually paying

for it. And that's not even talking about the intellectual property that's getting copied,

like the copyright violations that are happening. And I'm just wondering how that's going to play

out. I think the IP issue is much more of a problem outside of code actually, because

for example, in art and writing and all of that stuff, because the majority, if not all of the

code that's being slurped up is open source. So there is very little IP. Although I had a big

issue with this when they first came out, which was they were clearly trained on all open source

code regardless of open source license. And so that includes a whole load of GPL code. And

at what point does that GPL code not get covered by the GPL anymore?

Yeah.

It doesn't. They are way past the point of verbatim spitting out bits of code like they

did at the very beginning, which is how we know it is chained on GPL code because it would spit

out GPL licenses occasionally. But we've moved way further down the road and they're no longer

working in that way at all. But there's definitely a huge IP issue with books and with art and with

all sorts of other data that is harder to talk about with code because so much of it is open

source. Whether that difference in the licenses is important or not, which I still believe it is,

but I think it's harder to talk about that with code than it is with the other ones.

Yeah. I mean, I get the point that legally it might be okay. I mean, but we've already had,

we talked about this in the past quite a bit. Open source is being a pillar of software

development and it's not really compensated for the value it generates. And there's yet another

facet to it where it is yet propping up another pillar of the industry and is not getting

compensated. Instead of actually turning back and helping out with one aspect of it, there's yet

another front being opened where the value is siphoned off and is powering big tech companies.

It's just not all right. It's really not okay. And the problem is all the mechanisms to control

it are much, much slower than the development. There's no way any legal system or any regulatory

body is going to be able to act fast enough before everything has happened already. The

development is so fast. The EU doesn't even have the first meeting about legislation by the time

this is irrelevant. Like you say, it's irrelevant now because they've moved on to probably not GPL

covered code, even if they have, I mean, they might not have, who cares? No one cares at this

point. I think that code is still there. It just no longer verbatim spits it back.

Yeah. They've just suppressed the signal or the means of discovering it.

I'm not sure it's even suppressing. Anyway, what we should actually do is because we're already

40 minutes into recording the podcast and we haven't recommended a single package yet. So I

think we should probably put this on hold because this is a long discussion that we will never find

the end of, especially because we do have disagreements about some aspects of this.

We're aligned on some of it, but we do also have disagreements. So I'm not sure we'll ever get to

the end of this conversation. So let's do a reduced brief package recommendation section

so that the podcast isn't an hour long. So let's just do one package each this week.

That sounds good. Let's do that.

I will kick us off. Yeah. My only package this week is a package called package-swift-lsp,

which is by Kattouf, Vasiliy Kattouf. And it is a language server protocol implementation for

Swift package managers, package.swiftmanifest files. So if you're not familiar with LSP,

I'm not familiar with the internals of it, but I know how to use them. They are a way that

code editors and other tools can interface with this LSP to find out what characters or text is

available in the syntax of whatever language it is, in this case, the language of a package manifest

and suggest the characters that may come next. And it's used in VS code. It's used in the Zed

editor that you mentioned earlier. And I believe it's also used in Xcode for code completion as

well. And the package Swift LSP is an LSP that has been integrated now into both Zed and VS code,

but unfortunately not Xcode yet because there's no way to integrate third party LSPs, I don't think,

into Xcode. That will give you code completion on the syntax of a package manifest,

including package completion. So you can add a dependency for a package, start typing the URL,

and it will suggest a valid package based on the characters you've typed. And that data is actually

coming from the Swift package index list of packages file. So they actually give us a little

thank you in the acknowledgements of the readme file. They acknowledge both Matt Massicotti's

language service protocol, which was the foundation for their project, and then

the Swift package index for providing a great package data for URL completion. And so if you

are writing a package manifest with Zed or VS code and have the extension that they have provided,

you get fantastic completion within package Swift file, better than Xcode.

>> I think that's really remarkable, that these editors in a couple of cases are eclipsing Xcode

because they're so extensible, right? That's really fantastic.

>> And no AI at all involved in that one. >> It was actually my pick, first on my list

of picks. So there we go. >> I'm sure luck to you.

>> Yes, yeah. And that's actually via this package while trying it out. That's how I

ended up using Zed again. I had looked at it in the past. That's how I ended up actually in that

whole LLM experiment writing that script. Funny, funny little sequence of events.

>> I've been using Zed recently for the HTML and CSS work on package index, actually, because

you definitely don't want to do HTML and CSS work in Xcode. It's not what it's designed for.

But I used to use, well, I still do use Visual Studio Code for that, but I've been giving Zed

a try and it's very good. It's an editor written in Rust, actually, and it's extremely good.

So what package are you going to pick? >> So in my pick, I'm going to talk about LLMs.

My second pick is a package called Probing by Kamil Strzelecki. And this is a really interesting

package. It essentially gives you a debugger-like execution control via checkpoints in your code.

So what you can do is you can sort of like encode, write probe points that you can advance to.

Like imagine setting a breakpoint, except you spell it out, like stop here. So you have named

scopes. And then in a test, you can actually advance to that point as if you hit continue,

and then you hit the breakpoint. And then you can run asserts on the state.

And I found that really interesting, that that's possible and the mechanics of it.

I haven't dug super deep into it. I've tried the example that it ships with. So there's an example

that fully demonstrates the capabilities. It's a little test package with an application that

has probes put into it, and then tests that exploit those probes to advance to this position,

and then run asserts on the state. But there's one area where I can immediately see this being

super useful. And we've had this actually a couple of times where something failed,

and it only failed in CI. And especially at the time, our CI ran really slow. So it took like 15

minutes. And you really just wish you were able to attach a debugger to a test and see what's

going on. Because you might know it's failing in a method, or a test fails, and that test calls a

method. And that method is quite large. It might call other methods, and you can't pinpoint where

it is. So your only chance is really, if you can't reproduce it locally, your only chance would be

to actually try and refactor the big method into smaller ones that you then test individually. And

you can imagine how much work that would be. But with this, you can actually put probes in. You

don't need to refactor, you just put in probes. And then in your test, you can run to the probes,

and then you can run asserts on the internal state at that point. And then you can break

down the big method into smaller bits and pinpoint the problem much easier. Or actually,

just much easier, it would actually give you a chance to do it without a local reproducer or

this big refactoring. So I think that's a super interesting package for that sort of thing.

So if you have that situation, or are generally interested in that,

give that a look. It looks really, really interesting.

Well, we're slightly shorter than normal package section. We should wrap it up there, because

we have now been going 48 minutes. So we should wrap it up. I think we'll have more to say on

WWDC and the changes coming in Swift 6.2 and any other stuff that gets announced this week that we

haven't yet watched the videos for in our next episode. But we should leave it here for today,

I think. Yeah, let's stop it there. Thanks, everyone. And see you next week. Next time,

rather. Next time, yes. In three weeks, something like that. All right. Take care.

Bye. Bye-bye.

Bye-bye.