News
- What’s new in Swift 5.9?
- A Vision for Macros in Swift
- swift-ast-explorer
- Write Swift macros by Alex Hoppen
- Expand on Swift macros by Becca Royal-Gordon
- Privacy Manifests by Tony Tan
- Visualize Privacy Manifests – Discussion #2423 from Cihat Gündüz
Packages
- swift-openapi-generator by Apple
- CocoaUI by p-x9
- CloseEnough by Zev Eisenberg
- app-store-server-library-swift by Apple
- swiftly by Patrick Freed
Creators & Guests
What is Swift Package Indexing?
Join Dave and Sven, the creators of the Swift Package Index open-source project, as they talk about progress on the project and discuss a new set of community package recommendations every episode.
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.