Swift Package Indexing

Actually, I've got a little quiz for you.

We have a quiz already, straight away?

Well, yeah, we have a news quiz.

Okay.

It leads to news, I think.

Okay.

How do you add a package to a Swift package manifest?

Can you, off the top of your head,

give me the incantations you have to make to add a package?

Well, yes I can,

but only because I've been working on this thing to say.

Because you've cheated, right?

Yes, I have cheated.

So what is it?

Because I think there's a, there's a, there's a part of it that you probably

don't know, even, even though you've stared at this earlier this week.

Okay.

Okay.

So you add the dot package clause in whatever the top area is, you find the

top area, whether, where all the other package clauses are and you add one

alongside it right? That's the technical, that's exactly what it says in the instructions.

That's what it says in the docs, yep.

And then you find all of the other product areas and you've got a product.

Yeah right, so that's the target dependencies, yeah right and there it's dot product and name

and package goes in there. It's always, it's never quite clear which one it actually is,

But even in the top section, that's, and what I'm alluding to is we've started some work around

making package instructions easier. And it is actually quite easy if you're working in an

Xcode project because Xcode has some references for adding packages to your project. And even

just by importing something, if you import a product that Xcode knows about via some mechanism,

I think it's if it's in a package collection that you've added to your list of package collections

Xcode knows about, then if you do an import statement of a product, it'll actually automatically

add, do all the things that need to be done and add the package to your manifest. Now,

this only works if you have an Xcode project file. And if you're working in an actual Xcode project,

this does not work if you are working on a on a pure Swift package. In that case, you actually need

to go into the package manifest and add stuff. And for quite a while, we've had something to help you

at least a little bit with that because even the package clause, the first thing you mentioned,

adding the package dependency to the package clause, the top part of your package manifest,

even that is that line dot package. You're not done there because you need to specify what package

version you actually want, right? And there's different variants of how you specify that.

Typically it's from colon and then you give a start version and then from that start version,

it picks the highest released version on the same major version. So if you do 1.0.0,

it'll take any 1.xy version with the highest x and y possible. But there are a couple of other

variants of that and we do support that. For instance, if a package has a beta release,

which would be a branch version that you're following, then it has a slightly different

clause. And I think the clause is, and I don't even know, I'd have to look, I think it's branch

colon and then the branch name. So honestly, just to interject on that,

I've not done that manually since the Swift package index existed because we do have those

for the latest stable version and the latest default branch. And if there's a beta version,

we have all of those ready. And I've not typed that in manually in a couple of years now.

Stay Forever Yeah. But the thing is that we're working

towards an adding and that was spawned by a little discussion on Mastodon where Matt Mazzucotti

questioned whether it's actually useful to put installation instructions in your readme.

And a few people were quick to point out, well, it kind of is important because, because of these,

you know, intricacies of, of what you need to add. And, you know, you might know the package name,

you might not necessarily know the product name, and then, you know, you certainly want some

instructions on what to add. And the thing we're looking to add, as triggered by that discussion,

although we did have an issue in our list already, was to help with the second part of that, and

that is the product clause, or rather the product dependency in your target. And there we're looking,

because we have all the information from the package manifest, so we know what products a

package exports, so we can provide a selection dropdown UI element where you can pick the product

that you want to add, and then we can write out the product clause that we need to copy,

at least help with that bit of it. And that's what this little quiz was about, you know,

have this all in one place so that package authors can just point there rather than

have this set up. And it will then automatically also always be up to date. So if you rename your

products in your manifest, you don't need to worry about your readme going out of date and stuff like

that. It'll all be almost up to date on that installation page. And I think that's a great

idea, especially the concept of being able to link to that. So at the moment, and it will continue to

work this way, the "use this package" button on any package page does like a popover where it presents

the information. If you're using Xcode, here's the URL that you paste into Xcode. And if you're using

package.swift manifest, then here are and it will be the both the package clause

and the product clause as you say. The fact that that's a popover will remain

but we will give people a mechanism to link directly to their package page with

that already popped over so that you can link it as installation

instructions in your package readme. Yeah that'd be really nice, really nice to have.

We also discussed - and this is not going to be in the first deploy of this

feature - but we also discussed having a preview of a package manifest

syntax highlighted with the code that you're kind of selecting with the

by picking the version and the product in there too. Now I'm not sure how

necessary that is, but it is the kind of thing that, especially for people just

getting started with adding dependencies to pure Swift projects, that could be

helpful. Yeah, I think it would be really interesting to hear what people think

because I believe we are... it's really hard to think back how weird that was

adding a package dependency the first time because, I mean, even though I can't

remember the syntax. I at least remember there's two things to do and roughly where to put them,

and then there's enough scaffolding there to guide me. I couldn't type a package manifest,

just type it out for the life of me. I just couldn't. I always need a template.

But I'd be really interested to hear if people think this is actually useful to see it in the

context of a manifest, to see where stuff needs to go, or if that's just noise. It's hard to

judge when you're sort of familiar enough with it.

- And if we could take a look over in Apple's direction just for a second, I think

Xcode being able to manipulate package manifest files better would be an amazing step forward.

- Oh yeah, yeah, definitely. I do vaguely remember there was talk about a Swift PM command,

like add package that would then add it to the manifest. But I don't think that went anywhere.

or I'm not sure what state that proposal is in,

but it was talked about at least.

- I just want Xcode to do it.

- Yeah, yeah.

Well, when I say Swift PM,

I kind of assume that Xcode would gain that capability

then also for pure Swift packages.

It's always a bit weird.

Xcode is this thing that has this Xcode project

kind of mechanism and then Swift PM kind of mechanism,

and they're not the same.

It's hard to really talk about it.

It's almost like it has two different modes of operation

in those contexts.

It's kind of weird.

- And I had a standing prediction for a few years

in IOS Dev Weekly just before the conference every year

that my standing prediction was this would be the year

that they would choose Xcode Project

or package manifest file and just have one.

And that hasn't happened yet, so I've stopped predicting it.

- Yeah, well, for that to work, it would actually start,

need to start supporting iOS apps and all that

from a package manifest, right?

- That was where I thought they would, yeah,

that's where I thought they would start going with it,

but it does not seem to be the current,

I mean, it may be the plan for the future,

but it does not seem to be the current plan.

- I mean, it has to at some point, right?

I do wonder if that might happen in the context of a,

there was a pitch, it's quite a while ago now,

to redo the package manifest and do it in a, um, what's it called?

The builder, um, mechanism, you know, like the DSL mechanism to go away, you know,

from this, um, struct that you fill in kind of mechanism to, uh, a, a builder

DSL kind of mechanism.

And I wonder if that might happen all at the same time, maybe for Swift six or

something that, that, that format will change and then incorporate the other

things at the same time.

I don't know.

But I do feel it's not ideal the way it is right now.

- So anyway, the good news is it will get

a little bit easier if we, or should I say,

when we deploy these improvements.

- Yeah, definitely.

- There's another thing which has been going on this week.

At the end of, it was actually at the end of last week,

that we submitted a pull request onto Swift.org

with the first stage of an integration

between some of the data coming out

of the Swift package index

and the official Swift.org website.

So this is something we've been working on

for a little while now.

And it's in pull request at the moment.

So this is very much a kind of first step

towards some kind of integration between the two sites.

And the first thing that we're doing there

is some package lists.

So we've proposed a new page on Swift.org

and it's in the top level menu as packages.

And you can, in fact, you can actually see a mock-up

or a prototype of what we are proposing

to merge into the site.

If you go to the Swift.org open source project

and look for the issue that was opened by me.

And the very first title in that issue is a link

to the hosted prototype that we've got.

So it's a packages page, and on that page

is a list of currently three sets of different packages.

There's one called Community Showcase,

which is going to link to packages

that we mention here on this podcast.

And actually, this is, the reason I'm talking about this,

one of the reasons is we would love to know

if you write a newsletter or run a podcast

or something like that where you talk

about other people's Swift packages.

And if you do, please get in touch.

You can get in touch via our Discord,

which we'll link in the show notes,

because we'd love to get more sources of people

talking and writing about the package ecosystem

and include those packages on the Community Showcase section

of this new packages page.

We then have a couple, and I think this will be expanded

before the pull request is merged,

a couple of lists based on keywords.

So we currently have packages that are referenced

by the networking keyword and the testing keyword,

but I think we're gonna potentially expand that

a little bit more before we look at merging it.

And of course, there will be a whole process of review

before any of this gets merged.

So this is not just gonna go straight through,

This is genuinely an open source pull request

that's gonna go through to the site

and we hope that it gets merged,

but of course it may look different to what we proposed

by the time that happens.

- And of course the list would be changing,

I mean not daily or anything,

but they'd be on a refresh cycle of some sort,

maybe a couple of weeks.

But the idea would be obviously that they,

especially the categories are collecting packages

that are good starting points for certain topics like networking and testing as

the examples that would host packages there that you should take a look at if

you're working in that realm.

Something else I kind of thought of, but might be a nice section as I was

preparing for the podcast, and that was highlighting packages that coincide

with new language features.

So for instance, when Swift 5.9 comes out officially,

I mean, obviously we're already using it,

we're even already testing it,

but it's in pre-release form.

But it might be interesting to have a section

about macro packages, for instance,

when 5.9 officially comes out

and more people will start adopting it.

Obviously people are beginning to adopt it now,

but I guess we're early days in the adoption curve.

So in September,

maybe there might be an interesting collection to have.

And then obviously, you know, other Swift languages,

language versions will have other things.

So stuff like that might be interesting as well

for a section there.

- We could definitely do that.

And that could also be one of the,

so the testing and networking tagged packages,

they're not fully automated,

but we do have a tool that will generate the data

that goes into the Swift.org website for those two tags.

And anything that could go through our search system,

So for example, we can now search on packages

that have the macro product type in there.

We could do a similar thing for really anything

on that search criteria, couldn't we?

- Yeah, yeah, definitely.

I mean, it's a question, open question,

how long those lists should be.

We probably need to sort and truncate at some point,

but it's certainly easy to at least get started

their list and then go through and apply some further selection criteria, I guess.

So if you have, either if you do something yourself or if you know of somebody who is

interested in talking about Swift packages, maybe a podcast that you listen to has a section or

something like that where people can pick a package. Pick a package? It's a tongue twister.

Yeah, please do get in touch and we'll see if we can get something more structured together

to do with how the Community Showcase packages are built up.

Yeah, or even just for the podcast, let us know if... I mean, we do monitor

new additions to the index or releases and stuff like that. But there's enough coming in now

that it's easy to miss one or maybe not give it the attention it deserves. And a ping and a nudge

is a great way to highlight a package that is worth talking about. And then we discussed that

one of the sections, I mean, obviously our podcast would also be a source of input for that community

selection. So that's certainly a good way of getting something in. Yeah, absolutely.

There's one thing I noticed looking at these lists, and I wonder if you feel the same. And

I think I even mentioned this before. When I look at this networking packages, the first package is

Swift-neo. Then we have alarmofire, Pulse, Moya. It strikes me there's a,

there's this weird inconsistency about Swift package names. We have a couple others that

sprung out and I think it's, I got reminded because this is one of the few areas that I've

seen multiple packages listed side by side and then it becomes more pronounced. Like we have

combined Dash schedulers, all lowercase, Swift Dash, Snapshot Dash testing, all lowercase.

So we have a couple of packages that follow, I think it's Apple's guideline to have these package

names that are lowercase and K-Bop case, you know, with dashes in between the words.

Interestingly, the very first word in Swift Neo is, Swift Neo is an open source network

application framework and Swift Neo there is spelled like Swift Data or Swift UI.

It's Swift and then capital N I O.

So apparently the actual package name is Swift Neo.

Like, like I just described in the Swift UI kind of spelling.

It's weird to me that the.

Identifier that is used in the package manifest is sort of like an identifier

type label, you know, it's, it's almost as if something's leaking out that

shouldn't be leaking out and the proper package name should be something else.

And I wonder if that's ever going to change, if there's ever going to be

some sort of guideline, what the, what the name should be, but I, it strikes

me as weird that these, these names pop up like this and, and we're not

doing anything special, we're picking the package name here as it is defined

in the package manifest and it could very well be something different.

I'm a bit puzzled why it's been chosen like this.

I don't know, do you feel the same

or is that just me being OCD?

- Don't get me started.

(both laughing)

My biggest problem with all of this

is why do we need Swift in the name?

- Yes, yeah, yeah.

- I mean, I can understand.

So on GitHub, if you want your repository

to be descriptive on GitHub,

where it lives in an ecosystem of every possible language.

I can understand it there.

But why in the package name are we including the word Swift?

I do not understand it.

My personal preference would be to just use camel case.

Sorry, not camel case, what they call it.

The one where every letter is capitalized.

- Pascal case.

- Pascal case, that's right.

Yeah, my personal preference would be for Pascal case

or something like that.

But I don't really care what we pick as a community.

You mentioned an Apple guideline.

I'm not familiar with an Apple guideline.

I'm only familiar with the way they've started

to name all their packages.

So maybe that's referencing a guideline I haven't seen.

But it does seem to be hyphens and all lowercase.

But they all also include the word Swift,

which baffles me.

- I mean, by all means, call your repository Swift-

if it's on GitHub and you really want to be sure

that people don't stumble into your project thinking it's Rust or something.

But the package name, I mean, I mentioned this before, like if you look in your

sidebar in Xcode and you look at dependencies, it's Swift-Swift-Swift- it's

all Swift- and there's so much noise in there and you can't even tell at first

glance what your dependencies are.

And then there are the sort order because some actually start with S and

they're mixed in with all the Swift ones.

And it's, it's a huge mess.

And I understand why, why we've gone down this path to, to leak all this, you

know, it's like, we're not naming.

I mean, I know in Fortran, you used to, in your variable names, you'd have the type,

you know, an integer type, I think started or ended with an I, um, and F for real, R

for real and, and, you know, we're not doing that anymore because the type system

can actually reflect that properly.

But we're always tacking stuff into names when there's no need.

It's bizarre.

I don't like it.

Yeah.

I forget what the convention was called, but I think that it was very popular in

the C days and you would encode the type in your variable name.

So the one I always remember is LPSZ and then a name, which was a long

pointer to a string zero terminated.

And then the name of your variable. And I agree, we don't do that anymore and that's

a good thing.

But that's weird. I thought everything was just "void* in C".

Do you remember the naming convention name? I forgot.

But in C? No.

Yeah, in C, where you did the LPSZ and I and whatever.

No, no, no. I never really did that. I remember it in Fortran.

Was it Hungarian?

I think it might even have been required in Fortran. That's all I know. I only use C with

proper variable names. I think it might have been Hungarian notation. I think that might have been

the name of it, but I'm not sure. Somebody I'm sure is going to point out that I'm incorrect.

We'll be sure to follow up. The other thing we should just briefly talk about before we move

onto package recommendations is our sponsors. So for quite a while now we've had the support

of a couple of corporate sponsors. We've had both Stream and Emerge Tools, who have both

very kindly supported the site for, I think, over a year now. In fact, yeah, way over a

year. And they have been just wonderful. They believed in the

project from the very beginning. And we thank them so much for

their support. But what we don't want to do is just have the same

set of sponsors over and over again. And we want to keep the

site a little bit fresh. We want to make sure that people coming

to the site see different links every now and then. And so we've

been in conversations with a couple of new companies who just went live with

their sponsorships on the site last week. So those companies are Point Free and

Telemetry Deck. So why don't you tell us a bit about those two companies.

Yeah so Point Free you might know Brandon Williams and Stephen Celis who

are creating a great video series about architecture testing and

more. It's a really great site, you should check it out. I use that stuff personally.

They have lots of open source packages as well, so that's a really great place to check.

Telemetry Deck is a service providing lightweight privacy focused analytics for

apps and websites, so that's also a great place to check out. I think in particular recently there

was a change with Google Analytics not being supported anymore. I think you can't use it in

the EU anymore. So that might be a good reason to look at Telemetry Deck to change your analytics

on your website. I think just like with Stream and Emerge tools, the key thing about both of these

new sponsors is they are part of this community. This is not some company that's just kind of

coming in looking for the eyeballs of iOS developers. I mean, I'm sure they would love it

if you went and checked out what they do.

But Stream, Emerge Tools, Telemetry Deck, and Point Free

are all absolutely at the heart of this community as well.

And that's really important to us because we want to,

you know, we don't want to overload the site

with advertising and that was something that we've been

very keen to keep top of our minds since the beginning.

But we do have a little bit of advertising on the homepage.

But I think it's better if that advertising comes from the community,

and that's what we're trying to do here.

It's also worth just noting that this is not any increase in the number of

adverts or the amount of advertising or anything like that.

This is just rotating around some sponsors and we would love to have Stream

and EmojTools back at some time in the future, and they would love to come back

at some point, but we want to keep that cycle fresh.

Yeah, definitely.

I do think there's a real indie vibe there.

I did mention Brandon and Steven.

I should also mention Daniel Jiig,

who's the creator of Telemetry Deck.

And these are, you know, just indie developers

that have started these companies

and they're now supporting us and that's just great.

- And Lisa Figas as well is at Telemetry Deck too.

- Right, yeah, sorry, I only knew of Daniel.

- No problem.

Yes, I've been doing most of the conversations with them.

So yeah, thank you so much to our new sponsors

And thank you also to our sponsors

who are currently cycling out.

So that's just a little bit of an update

on the sponsorship of the site.

Of course, the other main sponsorship we have

is we have GitHub sponsors.

So if you can go to any of our open source repositories,

there should be a button there for GitHub sponsors.

Or on the site itself, just above the two advertisements

is a button for how to support us on GitHub sponsors.

And then of course the other sponsor that we have is Apple.

And you can see all of that information

on our supporters page, which is on the home page,

linked from the menu bar on the home page of the site.

- There you go.

- So thank you so much to all of everybody

who keeps this project going.

- Absolutely, thank you.

- All right, let's do some recommendations.

- Do you wanna kick us off?

Let's start with a package called Color Toolbox.

I'm continuing my theme of color-based packages

from last episode.

Color Toolbox by Ramon Torres.

And this is, unlike the last one that I mentioned,

this is not a color palette library.

This is a individual color utility library.

So it provides, it's not a huge package.

it's a kind of utility package.

It will help you kind of shorthand a little bit

of your color management code.

And then probably one of the most useful things,

which I am surprised that the standards,

well, we talked about how complex color is last time,

but also at the same time,

it would be great to be able to bring in

web hex colors into UI and NS colors and SwiftUI colors.

And that's one of the things that this does.

You can also take a color and get a hex value out of it.

But then it's got a couple of also useful

little features like you can detect the contrast ratio,

which is really useful when you're checking your site

for accessibility.

So you can check the WCAG contrast ratio

of any color to any other color.

And you can also, and this is something

I really find very useful.

you can lighten or darken a color by a certain amount.

So you can say, make this color 20% lighter

than it was previously.

And that's so useful for little things like,

if you have like a header and you might want to have,

to differentiate the background color of page

or a view or something like that from the header,

you can just lighten it or darken it a little bit.

And that's a really nice way to get some subtlety in there.

So it's a small package.

It's the kind of thing that if you use it,

it's only been developed for 22 days, so it's fairly new,

but it might come in useful.

And it's Color Toolbox by Ramon Torres.

- Nice.

Right, my first pick is called File Monitor by Kris Simon.

That's a really nice package.

And what it does is monitor file system changes.

So imagine you want to monitor a directory

for any changes within, you know, like creations, deletions, and modifications of files, you

can spin this up and then have a sort of a subscription or a callback to notify you of

stuff that's happening.

And it's really nice.

The thing that I noticed that I've found especially nice is that it supports Linux as well.

And obviously you can imagine there might be some significant differences in doing this

on Linux.

believe there are. So this is a nice package if you have need for this both on macros and Linux.

It's a very simple interface, you can try it out on a playground as well to get a feel for it.

It works as advertised and it's a nice neat package giving you file system notifications

for whenever you need that. You know, might be doing some... I remember seeing this being used

for instance, in Publish the other day where it's monitoring the file system for changes and then

retrigger a build of the package. Publish obviously being a package to create a

website and then you could automatically trigger rebuilds and then you would have to reload your

page and all that. So that's perhaps a nice application for that if you're looking for

for that sort of thing.

So that's File Monitor by Kris Simon.

- Yeah, sounds useful.

My next package continues a theme

that I think I'm becoming,

like I think it's becoming my thing on--

- Is it about colors?

- It's not about colors, no.

It's about having an amazing name for a package.

Actually, it goes on to our discussion

around Swift-lovercase uppercase.

This does not have the word Swift in the name.

And it instantly stood out to me

as I need to know what that package does.

So the package is called Rearrange

and it's by Matt Masigotti,

who I think you mentioned earlier in the podcast actually.

- I did, yeah.

- So again, this is a small package

that is dealing with extensions and utilities

for making it easier to work with ranges.

So NS range, NS text range.

Matt says in the readme, it says it's particularly handy

when used with the Cocoa text system.

So the kind of thing you can do here with like an NS range,

you can shift a range by a delta.

You can shift the start of a range.

You can shift the end of a range.

So you can very quickly, if you're, for example,

as Matt mentions that if you're working with text,

you might want to change the range of a selection of text

and you might want to shrink it or shift it left or right.

And then there are various other things you can do

with NSTextRange and UITextRange and IndexSet and String.

And again, not a package that's going to be

immediately useful to everybody,

but I'm a sucker for a good name and this is a great name.

- Nice.

Yeah, Matt, he's here, he's there, he's everywhere.

- He is, yes.

He's actually a great supporter of the project as well.

So it's nice to give him a shout out on the podcast.

- Absolutely, yeah.

Right, my second package is called

Swift-Concurrency Extras.

And it's a package by Point Free.

And disclosure, which we've just given you,

Point Free are a sponsor,

but anyone who's been following me

knows I'm a huge Point Free fan

and can hardly be surprised that I'm again

mentioning a package of theirs.

So here you go, Swift concurrency extras.

This is a package they released just last week, I believe.

And it's about testing asynchronous code,

which is notoriously difficult.

There is sort of a motivational link

that I'll add to the show notes

where they've raised issues around testing,

in particular, Swift concurrency code on the Swift forums

that sort of spawned all their investigation into this.

And they actually came up with a solution to deal with this.

And the problem is that it's,

in a heavily concurrent system,

it's difficult to do testing

because you sort of need to assert on an order of tasks

or an order of execution, which you don't really have

because if it's concurrent, stuff can happen out of order.

But that's really hard to assert on then.

And what they've done is they came up with something

to actually use a serial executor in test context,

so that everything really happens deterministically

and you can actually rely on the order of the tests.

So you're not actually changing your production code,

that stays all the same,

but you inject a serial executor that sort of then

takes all the concurrency out of the equation

and just execute stuff serially,

as if you had only one single task and a single executor that's doing everything.

And that then allows you to assert on all the steps and have reason about

the order in which things are happening.

And in case that wasn't clear, this is really for testing only.

You shouldn't be messing with this in production, obviously, because, you know,

you'd screw, you'd screw over your concurrency system with that.

And the repository comes with a really good example to illustrate why that is

necessary, why you might want that, why you would need that.

Um, and it's not a convoluted example.

You, you very easily end up in situations where it might appear to be working, but

if you run a test often enough, it'll eventually fail and eventually isn't,

isn't a large number, it can be tens or 20 or a hundred runs where it'll happen.

And obviously that's, that's no good in CI.

If every 10th run fails, that's, that's terrible because you'll

always be chasing some odd failures.

So this is a really great tool to be able to deal with that.

The package comes with a couple of other nice things,

things that we're actually already using

in the Swift package index,

because they are structures that have actually published

individually earlier on,

and they've now pushed this into this package,

and they're called actor isolated and lock isolated.

These are little wrappers around structs

to make them safe for use in testing

and to make them, to avoid race conditions in your testing

when you're asserting on stuff that,

you know, for instance, you have a variable

that you want to save stuff into,

and it's not living in a concurrency context.

You could use lock_isolator to allow access to that struct

without worrying about race conditions and stuff like that.

So this is a really nice package if you're into testing

And if you're having trouble with testing of things

that are heavily concurrent or making use of async/await.

And that's called Swift Concurrency Extras by Point Free.

- I think if there was a feature in Swift Package Manager

where you could subscribe to every package

from an organization, then Point Free would be added

to the Swift Package Index manifest in that way.

- Well, you're trolling me right now, right?

Because--

(laughing)

- A little bit.

- All right.

I'm not gonna bite then.

(laughing)

- Okay, my final package for today is a SwiftUI package.

And it's from Vansun Leung,

and it's called SwiftUI-VPSwitch.

And it's basically a replacement

for the iOS style toggle,

where you have a rounded kind of lozenge shape

with a circle at one end and in one position it's on,

and when you slide that across it

into the other position, it's off.

And this is just a really nice implementation

of a design style that I've seen

all over the place actually.

If you ever look through Dribbble

or any of the design inspiration sites,

you'll see this kind of effect quite often.

And this is an implementation of it in SwiftUI.

So imagine if you had, for example,

a switch that was representing day mode and night mode.

You might have an image that at the top of the image

represented a starry night sky, something like that,

with maybe the moon in it or something similar

to represent the concept of night.

And on the bottom of the image,

you could have a set of clouds and bright blue sky

something like that to represent a daytime toggle. And as you toggle the switch from

on to off, what it does is it animates the background of the switch up and down to move

between the day and the night states in the kind of viewport, the masking viewport of

the switch itself. Hard to explain. Go and have a look at the readme. There's a beautiful

animation there.

I was just going to ask if it's in the readme because I had trouble following along.

Yeah, I got halfway through, Anil, I had to continue because I couldn't just stop it halfway.

But also the best thing to look at here is just go and have a look at the readme.

And it's the kind of thing that I think is a lovely little...

I wouldn't advocate putting this kind of effect on every switch in your application.

But if you've got a really important switch,

then this is the kind of thing that can highlight

how important that switch is.

- Yeah, nice.

Definitely need to check that out.

That sounded really interesting.

- Yeah, go and have a look at the readme.

So it's SwiftUI-VPSwitch by Vanson Leong.

- Nice.

Right, my third pick is called TLD Extract Swift

by Marco Eidinger.

Not sure why he put Swift in the name there,

but otherwise the name gives away what it does.

It's one of these packages.

I picked it mainly to talk a bit about things

that are deceptively simple.

Not that it's overly complicated,

but it's really easy to fall into this slight trap.

And what it does is it extracts the TLD top-level domain

and the root domain and subdomain from a host name.

And this package is recommended to you

by the Ministry of How Hard Can It Be, right?

because you just split by the dots

and then take the last two elements, right?

That's your root domain.

Except greetings for example, .co.uk, right?

Because that isn't the root domain, the last two,

because that co.uk are considered as the root domain.

So that's not a domain you can register.

And there's actually, I didn't know this,

a public suffix list on the web that lists out and Japan has the same. There's .co.jp

and Australia I think as well. Some countries have a second level of official domains under their

national domain that they hand out. They're sort of, I don't know what you call them, like

like Lamented, you know, you can't freely get those domains there. And it's one of these things,

right, it's very easy to not consider that when you're doing that sort of thing and then suddenly

Co is your subdomain or rather your top domain and when it actually isn't because you've had

enough by one error. The other thing this package has, it has a CI setup to actually refresh from

from this public suffix list automatically.

So it does checks and I guess releases as well,

if it changes and you can even run,

if you use the package, you can run it yourself.

So you can actually refresh this list on the fly.

Not that I think it changes that often,

but it's always nice to have this sort of thing considered

because you can rely on this package to track

any sort of changes there.

So nice little package, TLD Extract Swift by Marco Eidinger.

When you first said the name of that package,

I thought you said TLDR, but no, it's TLD.

And that brings another episode of the podcast to an end.

So we will be back in a couple of weeks.

Please do let us know if you have any packages

or ideas for sources of community package recommendations

for our Swift.org community showcase.

And yeah, we will be back in a couple of weeks.

- Yeah, see you in two weeks.

Bye bye.

- See you then, bye bye.