Swift Package Indexing

We should sing a song. We should sing a song.

Is that going to be the new start to the podcast?

How's your singing voice?

My singing voice is awful. Although, actually, so while we talk about singing voices and

speaking voices, both of us are trying new microphones today. And so we may sound very

different on this podcast recording to what we normally do. If we don't sound so great this week,

please bear with us. We'll get it fixed by next time.

Yeah, it's just the mics. It's only the mics.

It's definitely not the voices.

Speaking of last time, can you actually believe that we talked about upcoming Swift 9 features

and absolutely failed to mention macros?

Yes. What were we thinking?

That's kind of bizarre. I did actually, obviously when WDC started and they were brought up,

that immediately pulled it back. I'd also seen Paul Hudson's blog post about the Swift features,

and it was obviously front and centre right there. Yeah, it was just bizarre. We completely,

completely failed to mention it at the time. It's it's really curious how stuff can be so out in the

open. And you because we both were aware of it, right? I've read the manifesto, but it's completely

It's completely gone. I mean, Apple could really just stop with the secrecy because,

you know, it's just there. People don't notice anyway.

[laughs]

[00:10:00]

Their secrets are quite literally safe with us.

[laughs]

[00:10:04]

But they're also a great feature, right? Have you seen the two sessions of WWDC? The one by Alex

Hoppen, which is the more introductory one, and the other by Becca Royal-Gordon?

[00:10:17]

I think I saw the introductory one. I haven't yet watched the other one.

[00:10:20]

Yeah.

I think there's maybe something we could briefly talk about with the macros because

not only did we fail to mention it last time, we actually did speak about macros before.

And I was reminded of that when I saw that second session by Becker Royal Gordon. And that is,

you may recall the context in which we talked about macros, and that was the package by

Kashikawa Katsumi, Swift AST Explorer, that was in episode 25. You may recall that's a

website that he set up where you can paste in a Swift source code snippet. And it'll give you

so you do this, you paste this in on the left hand side. And on the right hand side,

you see sort of like a, almost as if you do a, a, you know, in Safari's dev tool,

you can see the HTML underlying the page.

It gives you the past abstract syntax tree of the source code,

and you can hover over the elements,

and it highlights the source code

that corresponds to those syntax nodes and that sort of stuff.

I do remember that, yes.

I think I even also linked to that in the newsletter.

Yeah, you did.

And the reason I brought that up at the time,

and I'm pretty sure I mentioned it,

was that I thought this is going to be really great

for when you're writing macros, because in order to write macros, you're going to be using Swift

syntax. And I thought it would be quite complicated to sort of assemble the syntax

nodes that you need to, that you can modify and then you know, to create your macro.

And the reason I thought that is because if you read the vision, the macros vision document,

it lays out a number of different ways in which you can do macros. And I guess the two

sort of most common ones or the most easily understood ones are lexical macros, which is

like C preprocessor type macro expansion, where you effectively do like text replacement, right?

You define something gets replaced in a preprocessor stage, and then the compiler

runs and the other version, and there's a third one. But this one that Swift macros

is actually using is syntactic, where you manipulate the syntax tree, syntax nodes,

and then you create. So you have input that's valid Swift, and then you can modify it and you

output different valid Swift. But at the time, I thought, well, okay, this is really great, but

this is probably going to be a bit difficult to work with. And the really interesting bit is

that it actually isn't. They've actually done it in a way that gives you the best of both worlds

because with Swift macros comes a library, Swift Syntax Builder, which is a result builder DSL that

allows you to assemble nodes by just taking little source code snippets. So if you have a very static

thing that you want to do in your macro, you know, just expand something. And like, if you want to

write an initializer, that's always the same to certain types. You can literally just paste

the source code string as you would write it. And that is going to be part of that syntax builder.

And you don't need to fiddle with any syntax nodes. You can literally just act as if it was lexical.

and under the hood that gets passed into syntax nodes and returns. So you don't need to fiddle

with the details. You can if you want to. And that gives you lots of powers, obviously.

But in very simple cases, you can literally take source code and even interpolate stuff

into the source code. So it's really, really powerful mechanism. I can only recommend

watching that session by Becker Royal Gordon to get those details. I found that eye opening in

how easy it actually is to get started with it and not having to delve into the details of Swift

syntax, depending on what you're going to do. Obviously, that's very powerful,

and that's something you might need or want to do later on. But for simple stuff,

you can go a long way just with little source code snippets and stuff like that. So that's

something I found really interesting and remarkable about how that's implemented.

- Right, that's great.

And the other thing about macros

that was probably just worth mentioning is,

I think you asked the question on the last episode,

did I think that there would be any secret features

of Swift that would drop alongside

whatever was announced last week?

And turns out that actually macros was the key feature

that everything that was announced last week used, right?

So there was nothing else needed.

- Well, and it was secret for us, right?

(both laughing)

- Exactly, yes.

- I don't recall anything else in there.

I haven't caught up on a lot of sessions to be honest.

I've watched a chosen few

because last week was a lot about adding

actually Swift 5.9 support to the Swift package index.

So I was a bit...

- Well, that's it.

And let's talk about that for a second

because as we speak, the build machines that we have

in various data centers around the world

are currently crunching through,

is it about 70,000 builds to test compatibility

with Swift 5.9 with every package

on every combination of platform

and then obviously the new Swift version.

- Yeah, yeah, exactly.

It's a bit more than 70,000,

but off that order of magnitude,

I think we're about a third,

well, we should be well over a third through now.

It was a third this morning.

So by the time you hear this,

we're probably done with it.

Probably done, yeah.

Yeah, and thankfully, it's getting a bit easier

to set this up every time we have to do it.

There are some really tedious aspects about it,

and we've sort of managed to whittle those down a bit

and make it a bit easier to adopt new versions.

Still, I'd hope there aren't more than two versions

per year that we need to adopt,

but it is getting a bit easier, which is great.

Yeah, and I think the main reason

we briefly discussed whether we should pull the trigger and add it early because last time 5.8 we

waited quite a bit. We didn't add anything during the beta phase. But macros actually were, I think,

the main reason we did it this time because I think it's going to be really nice to be able

to search the Swift package index for packages that have macros in them so you can explore a

what 5.9 offers.

And obviously for that to work, we need to support 5.9.

- Right, yeah.

And we'll also start displaying.

So at the moment we currently display

three different product types on the package page.

We display the number of libraries in the package,

the number of executables, and the number of extensions.

And we will now add the number of macros in there

so you can see for any package,

all four of the different product types

and how they apply to what's in the package.

But I think it's kind of,

there's always a dilemma with adding new Swift versions

of if you add it at beta one,

then obviously we do this huge backlog process

and everything goes,

we determine the compatibility information

for all the packages using a beta one compiler.

And we're not gonna run that whole process

for every single beta that comes out.

And so it kind of relies on people

actively developing packages

if they want new beta update compatibility

because we will only rebuild their package

if they release a new version

or move the default branch forward or something like that.

And if there are any changes to Swift

inside this beta cycle,

then we either do the whole big backlog churn again

at the end, or we just kind of say,

well, your code will have been compiled

with one of the betas.

- Yeah, I think it's fair during the beta process

just to let it sit.

And I think a lot of the active packages

automatically have changes of one sort or the other.

During that time, we can probably,

we should probably, we should consider

just rerunning everything once 5.9 releases out.

- Yeah.

- But I think during the beta phase, that's fine.

Plus, recent years,

honestly, I think the changes between betas aren't dramatic.

It's probably more around macro implementation

sort of things that get sorted out,

but we're not actually testing those bits anyway, right?

When we build a package,

the macro definition doesn't even get tested.

So that's, it's a bit like plugins, right?

There isn't, there's a bit of a,

it's a bit of a weirdness in what kind of package is that

in terms of dependencies, right?

We don't have a mechanism to actually honestly test a plugin

or a macro in that sense.

I wouldn't even know how we would do that.

Like we do for package building in general.

- Yeah.

We live in an imperfect world.

What can I say?

(laughing)

There we go.

The other thing that came out of the conference,

which we actually had a issue,

sorry, not an issue, a discussion opened

by Get Gunders yesterday

about the privacy manifests

and the package support for privacy manifests.

I actually watched the session video

this afternoon for that.

And I think it's just worth talking about that as well,

because that is a very obvious feature

for us to add into our package page.

So just to catch anyone up

who hasn't seen that session video yet,

the privacy manifest that you can now embed

within a package give,

well, let me back up one more step actually.

So if you have an app and you are filling

in your privacy nutrition label

as you submit your app to the App Store,

One thing that it is currently your responsibility to do

is look at every single one of the third-party SDKs

that you're using and try and determine

what they're doing in terms of privacy.

And usually that involves reading through terms of service

and lots of very vaguely written documentation.

- The fun stuff.

- Yeah, exactly, yeah.

No documentation, legal jargon.

And so the new feature is that SDK authors

may now encode the things that they are doing

related to privacy in a privacy manifest

and include that in their SDK package.

So fairly shortly, within let's say six months,

we are going to get packages

increasingly include these files

And it's a really great feature for us

to add to the package page.

The more I watched of the video,

sorry, it's a short video.

I would recommend watching the whole thing,

but it became clear to me very quickly

that there was enormous amount of data

that package authors can put within that file.

And so we certainly can't summarize it

on the package page itself.

We may be able to give some kind of representation

of like this package indicates that it does 13 things

or something like that, or maybe we just have to say

this package declares some privacy implications

and have that be a link to a documentation,

not a documentation page, but a full page

of what we're passing out.

But actually I think that brings me on to one other point

which is that obviously the PLIST file of this manifest

is encoded with key names and that kind of thing.

we're going to have to have all of the descriptions

and definitions of each of these keys

baked into our app somewhere

because I don't think there's an automated way

to convert those keys into something readable.

There is for the full application.

So you can say with like an Xcode project,

gather together all of my dependencies

and give me a privacy report

that I can then submit to the app store.

But I don't think there's a way,

And that seems to be in a readable format,

but I don't think there's a way to do that

for an individual package.

- Right. - Maybe there is.

- Right.

I wonder if SPM might have tools to gather those up

because I could imagine that on the command line,

you would want to do it, right?

Xcode can do it, but often there's an Xcode build command.

Perhaps, I mean, SPM would be even better

offering the same thing.

That would be nice.

In terms of displaying it, I was under the impression

that it is effectively, it represents the same thing

that you can see in the app store

under the privacy and nutrition labels.

So I thought that might be a way of distilling

these bits of info together, but I might be wrong.

- I think, I mean, certainly those privacy labels

are derived from the data in this file,

but it's not a one-to-one mapping of keys.

I, as far as like, and I'm, I'm 12 minutes into my research of this by watching that

video.

So I am speaking from an extremely uninformed viewpoint here.

But my, my impression of what I saw in that video is that there are, there are more detailed

keys in there that some process narrows down to one of those nutrition labels.

And I'm not sure whether that process is public or private.

Right.

Yeah, yeah, yeah.

I got that sense too.

I was just, I am thinking though that we could,

I mean, it would be duplication of effort.

I mean, unless there is a way to actually get those results

out of Xcode or Swift PM or something,

I was thinking that we could do the same thing, right?

Distill it down into a view that looks very much

like the nutrition labels.

- Yeah, and even those nutrition labels,

if you imagine three of those nutrition labels

on our package page, that's quite a lot of space

to take up there.

So I don't know, this is not even a declaration

that we will work on this problem,

but it does seem like something

we should at least investigate seriously.

- Yeah, I mean, I think it's great data to have

if you choose dependencies.

- Yes.

- It's up there with license, I think,

to have that sort of info there.

There's even mentioned that there are certain,

there are going to be certain requirements

about certain SDKs.

I don't know what the name was there.

I think privacy impacting third-party SDKs.

There was supposed to be a list of pre-screened.

- Yeah, so there's a thing called required reason APIs.

So this is to prevent fingerprinting.

So this is a technique that various companies use

to try and get around the tracking controls.

So for example, if you look at somebody's amount

of disc-free space, if you even get access to a microphone

and record like room noise,

I've heard that they track people on.

So if you get a recording of someone's room noise,

and then if they're on a different device,

but with the same room noise,

you know that those two devices are the same person.

And yeah, it's awful.

So there's lots of things that they can use

to fingerprint a device that is not, you know,

the official way of getting a tracking ID.

And they were very clear in the video to say

that that is never allowed.

And what they've done is they've added a whole load

of APIs now that you have to have a good reason to use.

And again, you can use these manifests to document

the reason you're calling the API that gives you

the amount of free space left on somebody's hard drive.

- Yeah.

- And actually that brings me onto something else

that's crossed my mind as I was thinking about this

in the context of the Swift package index.

And that is, would we increase or decrease,

depending on which way we decided to do it,

a package's score based on how much or little

of these privacy implications

they kind of include in their manifest?

- Well, I think at the very least,

the presence of a declaration should bump your score a bit, right?

Because you give people...

That's an easy thing to do because you give people information.

We don't judge the content, but the presence gives people the ability to judge whether

they want to add it or not.

I think that's helpful and that should elevate a package.

- Yeah, I think that's a great way to approach it because what you don't want to do is penalize

people for being honest with what they're doing.

Like if they are collecting a lot of data,

that's like, it's better to know that.

And I would feel slightly less comfortable

reducing score based on how many boxes you tick

in that privacy manifest.

But I really liked the idea of just saying,

well, if you've done,

if you've taken the step to include this,

you get a couple of points.

- And with the rest we can deal with by adding filters, right?

We could have a filter that allows you

to only select packages that have no privacy implications.

And then it's up to the person searching for dependencies

to make those choices, make those trade-offs,

whether you are okay with something that tracks

or whether you don't want that at all.

So I think those were probably the most relevant bits

of WWDC for the package index.

And should we move on to some package recommendations?

- There's a couple of things that I-

- Oh, there's more.

- Did want to mention.

Yeah, I wanted to circle back very briefly to 5.9

because one thing, now that we've added 5.9

and we're now supporting packages that are 5.9 only,

there's a case to bear in mind,

and that is around documentation generation.

So if you add documentation to your package,

what you typically do, you add the documentation target

that you want to have documentation generated for.

And specifically, you don't specify any Swift version

when you do so.

And that means we choose which Swift version

we build your documentation with.

Now, what we haven't done by adding 5.9

is changing which documentation version by default

we build with, which Swift version

we build your documentation with.

And that remains 5.8.

So if you don't change your SPI manifest,

we'll generate docs with 5.8.

Now, if you have a package that is 5.9 only,

obviously 5.8, the builds will fail,

there will be no documentation.

So in that case, or if you're interested to build with 5.9,

you should set the key in the SPI.yaml file,

Swift_version 59,

which then would opt into building the docs with 59.

So that's a little thing to be aware of.

You also might want to change that back

once 59 goes live,

so you're not stuck on 59 later on.

- Yeah, this is what I was gonna mention actually,

is that when we ask people to make this kind of change,

it's easy for them to make this kind of change

because they need the feature in Swift 5.9 at this point,

then 5.9 gets released and nothing bad happens

because they are still on 5.9 and everything's happy.

And then 6 comes out and they're still building with 5.9.

- There's an easy service we can think of

depending on how many people that do.

We could even consider alerting people

or even automating pull requests, I think,

because we know which packages opt into.

We do.

A 5.9 documentation generation.

And we have lots of packages that generate docs, but it's also not, it's not thousands,

it's hundreds.

And the 5.9 opt-ins might be, will be a lot fewer still.

So there might be something there to help out.

Plus, you know, obviously all the packages that don't specify tools version 5.9, which

are 5.8 compatible, it can just leave everything as is and keep generating the docs as they are.

The other interesting bit is we've seen a huge traffic jump in documentation overall,

since WWDC. There have been a couple of packages announced that are very popular. More on that in

a bit, I think. So it's effectively doubled our documentation viewing, which is great, like 20%

of our traffic is documentation traffic right now.

Yes, I predict we're going to talk about that in the next section.

Indeed, we are. At least I've picked something there. So, we'll see how that goes. Shall we then?

Yes, let's do some package recommendations. Do you want to kick us off?

I can. And I can transition straight onwards to that package that is driving a lot of that

documentation traffic and that is Swift OpenAI, not OpenAI, this trips me up so many times,

Swift OpenAPI Generator. And that's a new package by Apple. There's a WWDC session about this,

meet Swift OpenAPI Generator. What this is, is a package that auto generates your network

interface from a, an open API JSON file, which is a file that many API's ship that describes

the API. So effectively, you can ingest that file with this tool and it spit out, I think

it's structs, but effectively, you know, like an API that you can then use to interface

with that, that API. So you don't have to write any networking code, really. And that's

really amazing. And what's what's even better, that package comes with really, really great

tutorials, how how you set this up, how you use this. So if you're not familiar with

open API, this yaml file or JSON file, it's actually available in both formats, what that

means what that looks like, and how that works. It has a really, really great tutorial to

step you through the process. Obviously, there's also the session that describes that.

I think it's also just worth mentioning at this point that OpenAPI has been around for a long

time. And this is not like OpenAPI itself is not new. This is Apple kind of embracing and making

it easier to interact with OpenAPI specifications. Yeah. Chances are an API you're working with

has an OpenAPI. Almost certainly. Yeah.

JSON file. Yeah. So if it's modern, it should have, if it doesn't, maybe you can talk to the

team. It shouldn't be many, many backend packages that the backends are implemented with actually

have extensions that auto generate that file from that API that again, so you can actually,

you know, generate code on both sides, which is kind of magical. But it's available for many,

many packages, backend frameworks have that,

ship with that or have extension that support that.

So that's really great.

It also comes on the client side with many implementations

for networking clients.

So, like, for example, if you're planning to use URL session,

there's another package that builds on top of this

that gives you all the APIs.

When you're working with URL session,

there's one for async HTTP client,

There's one for vapor, there's one for hummingbirds.

So for all of these, you have sort of ready made

tools to get those working.

And there's even another third party one that just dropped this week

after WWDC request DL, which is a networking library

by Breno de Moura,

which is quite a nice networking package as well.

It's a bit of a DSL.

We had this in the past.

we had a package that was a DSL to describe a query.

This takes the same approach further.

You don't just describe the query itself,

you describe the whole networking request in a DSL.

So that's also a package that I want to throw in and mention

at the same time as this one by Apple.

That's requestdl by Breno de Moura.

So there you go, really nice set of packages for not just backend.

So obviously this is more about the client side of developing apps that target APIs.

And you tease talking about the documentation, they never follow through with it.

So the nice thing about all these packages is that the documentation for them is hosted

by Swift Package Index.

And it's wonderful to see Apple trust us with the hosting of that documentation.

and it's not something we take lightly

in terms of that trust,

because it would be very easy for them to think,

well, we shouldn't trust the third party site,

even though they are now a supporter of the site,

but I think it's a really nice gesture

that they trust us enough to host this documentation.

And as Sven said, we've seen some increase

in our documentation traffic because of it.

Because these are new packages,

people are checking them out,

And in the read means there are links to the

Swift package index hosted documentation for them.

- Yeah, I'm really, really happy about this

becoming a bit of like in my work, I see,

I often go to packages that I know we use

and look at the documentation through us,

even if it's linked externally,

I really like that there's as a single place,

I know where to look to find the docs.

I think I'm really, really happy about that development

that we're not just about finding the packages initially,

which is something you probably don't do all the time.

Looking up docs, I really do all the time.

Maybe even our own docs, like our SPI manifest file,

I often go to that page through the normal route

to the package page, to the documentation link,

to the docs.

- And it helps us, you know, the whole point of us

creating this documentation hosting system

was to make it trivially easy

for people to host their documentation.

Now, doc C doesn't make it hard to host documentation.

You know, it comes with a command

where you can transform your documentation archive

for static hosting,

and then you can stick it on GitHub pages

and you can host it that way.

And it's not an enormous amount of work,

but I think one thing that we have done

is that we have made it a trivial amount of work

adding, you know, one word to a YAML file

that you stick in your repository route.

And what's really nice to see is that

as more people start to trust

that we're doing a good job with this

and Apple being the ultimate kind of flag in the sand of like,

well, if Apple are happy to trust it,

I think that really just,

it moves the whole ecosystem forward

because if it's so easy to host your documentation

and it's so easy to add a couple of comments

above every type that you make,

then we just start to enable

a better documented Swift ecosystem.

And there's lots of people all pushing

in that same direction.

And I'm just happy to be part of that.

I think that's great.

- Yeah, I think it's really great.

Right, you wanna give us your first pick?

- Yeah, my first pick is Coco UI by P-X9.

- Is that the cousin of C3PO?

- I think it is, yes.

(laughing)

Yes, there is a GitHub username,

but even their commit author information is p-x9.

So that's all we have to go on.

(laughing)

Thank you for your work, px9.

So what it is, is a,

it's actually similar to a package I've used in the past.

And the package that I've used in the past

is SwiftUI Introspect by Sightline, which is a company.

And both of these packages let you dig

under the covers of SwiftUI.

So if you have a SwiftUI label,

then it is likely, but not guaranteed,

this is likely that under the surface,

if you're running your application on iOS,

that might be a UI label.

If you're running on Mac OS,

it will probably be an NS label.

And so what these packages allow you to do

is they allow you to say,

if the backing of this control is a UI label,

let me inspect and modify the properties of that UI label.

And the reason I mentioned Cocoa UI specifically

when I've already mentioned in the past

and used Swift Introspect

is that it adds a couple of nice little features,

which is it has a few kind of extra features

extra bits of syntax or actually view modifiers

that you can add on.

So for example, it adds some lifecycle modifiers.

So you can say with a text, a SwiftUI text control,

you can say, you know, .coco as a view modifier

and get hold of the view controller, for example.

But you can also add a view modifier for on view

will appear and on view will disappear.

And those kinds of lifecycle events,

which may not be completely covered yet in SwiftUI.

I mean, SwiftUI moves forward every single year

and there are less and less reasons

to dig below the surface of SwiftUI every year,

but that doesn't mean there's no reasons to do that.

And I think this kind of, this package, they're very safe.

If they don't find the correct control underneath,

they don't do anything.

And so you don't really risk your application crashing

because of using this kind of thing,

but they do allow you that extra little bit of control

if and when you need it.

- Nice. Yeah, I did see that package

and I was wondering exactly that thing

because I do recall when I first looked

or first saw Introspect,

that there was a bit of a warning label in the readme

if I recall correctly, you know,

be careful this is exposing under the hood details

which might change in the future.

I did not see a warning like that in Coco UI.

Does that mean it's safer or more stable,

or is that just safe because it just won't do anything

at all if there's something wrong

with the uncovering of the details?

- My understanding of both of them

is that they will do nothing if they're not.

- Right, okay.

- There may have been a warning on Introspect maybe early on

but certainly by the time I used it,

so I used it for the iOS DevJobs application.

- Right.

- And by the time I used it for that,

there was, if it didn't find what I was expecting,

it would just do nothing.

- Right, okay, I see.

Cool.

Right, my second pick is called

Close Enough by Seth Eisenberg.

And that's a really interesting and nice package.

So this is for testing.

And what it does is it ships a property wrapper

that makes comparing floating point

or floating point-ish values easier.

When I bring this up, you are probably immediately thinking about, well, XCT_assert_equal does

have an accuracy parameter where you can specify if you compare two doubles, for instance,

within which delta the comparison should be considered equal, right?

You can provide the accuracy, and then if they're that close or closer, they're equal.

Which works great if you have a straight up double or float or something like that.

The problem is if you want to compare structs that are equatable but they contain properties

that are floats or contain nested types that contain properties that are floats, that won't

work, right?

Because you can't pass in that accuracy parameter unless your type is a floating point type.

But what you can do with this property wrapper is if you mark properties with that, and my

understanding is only in a testing context when you use XAT_asserts, you can then specify

the accuracy on a type by type basis to consider that accuracy for those properties only.

So you can actually use XAT_ASSERT_EQUAL, you don't specify any accuracy there, like

individually, you specify it on a type level, and it'll filter through into the structs

that you're comparing.

I hope all of this makes sense.

It's always difficult to describe this sort of thing in a podcast.

If you look at the readme, it'll immediately make sense if you've ever done any comparison

of structs having nested types with doubles,

you know how difficult that can be

and how annoying that can be to filter through that.

This is a really great package to deal with this.

Close enough by Zef Eisenberg.

- Anything that makes testing more reliable

and a little easier is good by me.

My second one actually is similar to your first one

in that it is an Apple published package.

So the package is App Store Server Library

and this is published by Apple.

So a few years ago now,

Apple published their App Store Server API

and App Store Server Notification API.

So you can, for example, manipulate the things

that you can manipulate within the developer portal

once you've logged in with your developer ID

and also get notifications of things like

when a purchase was made or, you know,

there's various events that happen

during the purchasing cycle

that you can choose to be notified of on your backend.

And there have been many third-party libraries

that have dealt with this,

creating a Swift wrapper around those online APIs.

One worth mentioning is Bag Boutique by Morten Guggesen.

And that's been around for a little while.

And in fact, actually, ironically,

that is generated from the open API spec

that Apple published for their App Store Connect API.

So, you know, this is all,

we're all going around in circles here.

But yes, Apple have now made an official

Swift wrapper library around those two APIs.

And it's the kind of thing that you probably won't do this

from within an application,

but you certainly will be doing it.

If your backend is written in Swift on the server,

this API is going to be very useful to you.

And this library is going to be essential.

- Was there a WWDC session that came with that?

- Yes.

I was wondering if that was introduced.

- There was one,

and I thought it was linked from the readme file,

but it, oh yes, it is.

So if you go to the documentation section

of the readme file,

there is a link to documentation,

which is actually not hosted on Package Index.

That one is on the Apple developer site,

but there is also a link to the WWDC video,

which is called Meet the App Store Server Library.

- Very nice.

Right, my third pick is called Swiftly by Patrick Free.

This isn't a source code dependency package.

This is a tool and this is a work in progress tool.

It's a tool chain installer akin to Swift Env,

which people might know or Rustop,

if we're talking about different ecosystems.

What this will allow you to do is install Swift.

And the idea is for this to be the official tool to do this.

So this is an SSWG project,

the official effort to bring in a tool like that

to make it easier to install tool chains on all platforms.

Right now it's Linux only,

which I find really interesting

that that's the first platform that this ships for.

And it's really nice.

It's not fully done yet,

but I did want to highlight it early

because if you work on Linux,

that's already a really useful tool

because it can be a bit more difficult there

to install Swift tool chains.

So it does have install and use commands there,

which means you can just give it a,

pick a name, like there are shorthands

for certain Swift versions,

like five, eight would give you the release version.

You can do 5.9-snapshot.

It'll pull in the latest 5.9 snapshot and stuff like that.

And then you can use swiftly use to switch

between installed versions, which is really nice

if you want to experiment.

And all of this works in Docker, obviously.

So that's a very easy way to play around with this

if you're on a Mac even.

In the future, there are other commands to come.

So this is something that's actually different from Swift.

and for example, which does some of this,

it'll have an update command,

so you can update a tool chain

that you've installed in place.

It'll also allow you to list available versions.

So it's a really nice tool to work with Swift on Linux,

and Mac OS obviously is in the works,

so it'll come to Mac OS soon.

I'm not sure what the timeline is on this,

but it is in the SSWG,

so if you're interested in progress,

they do publish the meeting notes every month or so,

so you can see what's planned around this.

And yeah, it's now a project within SSWG

and a public package that you can install.

- That's fantastic, yeah.

And again, like my comment about testing,

anything that makes installing Swift on Linux easier

is fine by me.

So I think that pretty much wraps us up for another episode.

We will be back in two weeks with more recommendations

and maybe more features of Swift that we missed in WWDC

that we forget, that we forgot about.

Who knows, right?

- Who knows exactly?

- See you in two weeks, bye-bye.

- See you in two weeks, bye-bye.