Subscribe
Share
Share
Embed
News
- Improved "Use this Package" button Pull Request
- Swift.org Packages page integration preview
- and the associated Pull Request
Packages
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.
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.