Swift Package Indexing

that this might actually be, might actually be for the podcast. So I did run a test this time to make

sure I don't mess up the recording again. And so I set myself a timer half an hour and recorded

myself just, you know, as I was working. And of course I can set a timer and immediately forget

about it. So every Monday I do system maintenance and stuff, and I set a three or five minute timer

for each machine to check it after it's been rebooted. And you wouldn't believe how often

that timer goes off and I think, what's that about? Yeah, what on earth do I need to do?

Within three minutes, I forget what this timer was about. I'm not in the kitchen,

so there's nothing obvious heating up or something that needs attention. And I just don't understand

what's going on. Well, welcome everybody to the Over 50s podcast. Well, it started sooner than

that but yes yeah I'm not I'm not I'm not actually quite 50 yet I'm 14 oh all right all right well

you've you've segmented us nicely there um so anyway you can imagine how long it took for me

to completely forget about this recording and then when the timer went off I stared at the

at the watch and then but because it was 30 minutes that I made the connection 30 minutes

was weirdly very unusual time for a timer then ah right yeah you had this recording running

What you haven't mentioned is why you were doing this. Well, do we really need to

go into this? So well let's let's talk about it. We had a bit of a week last

week. We had a serious issue with the package index itself and we also had a

podcast recording last week and when I received the Sven's audio file it was

about three quarters missing with just complete silence and there must have been maybe a loose

connection or something like that from Sone's microphone and so I asked him to do some testing

and that was his half an hour microphone record that he was just referring to.

Yeah exactly and this actually ties nicely back to the remainder of my story because when I was

listening back to this I'm still working on this problem. I'm still picking up the pieces from what

went wrong last week. I listened back and there are these sighs in the recording like,

"Oh, why is this not working? I completely forgot the microphone. It is hilarious to listen back to

this. Someone's suffering at their desk in agony over stuff. Oh God, I'm just glad this isn't

running the whole time." Well, so that's the thing. We are actually surrounded in modern life by

tens of microphones. I don't know how many microphones there are in my house, but there

are a lot. Yeah, I wonder how many are live. Yeah, exactly. And I don't want to hear all

the exasperation that I say throughout an average day.

I'm actually becoming more conscious of this because I work here with the window wide open.

I can often hear the neighbors talking two floors down on their balcony. I've started

of reining myself in a bit because I do sometimes when stuff doesn't go right I

do tend to curse a bit and I thought I need to dial it back. That's really

interesting I can I hear my neighbor there through the wall. Sometimes it needs

to be done it's like hitting return harder has an effect for sure. Yeah should

we should we briefly talk about what actually happened? Yeah so let's talk

about the problem.

Yeah.

So in broad strokes, we released an update last week, early last week.

I think it was Monday afternoon.

Um, and the repercussions only became obvious later that evening.

And long story short, what happened?

We lost about half of our versions and a version in our system is a.

Get reference essentially.

So we have one, uh, branch that we're tracking the main branch, default

branch of a repository and then we're tracking a reference, a version for every release that package

has. And you can imagine there's a number of them. We have a bit over 6,000 packages and we have

100,000 versions that we're tracking in the index. And we lost, I think like 45,000 before we noticed

what was happening and why it was happening and pulled the plug. And the problem was there was a

delay for us to notice, a significant delay due to how the bug manifested itself between us

actually having a chance to see that we lost the revisions?

Yeah, without going into like real detail about it, it's kind of a complicated

situation where it wasn't... we have these analysis cycles where we'll run past all the packages

looking for changes and then back round again looking for changes and back round again, and

And they take about, is it about three hours

that it takes to run past that?

Last time I checked, something like that.

- One complete cycle takes around three hours

and then it goes back to the start.

- Right, and the bug only manifested

in the second set of analysis

after this bad release was deployed.

And so you're in that worst of all situations

where the release gets deployed, everything seems fine,

and then at some point later, everything goes to, yeah.

And the thing is, I stopped stuff when I initially saw the problem and then I rolled back and I

didn't see a change. And I didn't see the change because the problem didn't manifest itself

immediately. And then I rolled forward again. And that cost us revisions because had I stopped there

and given that more time, that would have saved us. But long story short, we lost the revisions.

that's actually not the end of the world. The revisions come back quickly within one analysis

cycle. We're all back on the revisions. What we also lost, unfortunately, were all the builds that

we have attached to a version. And those are the compatibility builds that we run, that we kick off

for each package across all the platforms and all the Swift versions that we're tracking, which is,

I think 30-ish per version.

32 I think, yeah.

Yeah, so you can imagine that's a lot of builds that we now have to catch up on.

We're actually still in the process, tail end of the process.

We decided last week not to replay a backup.

We do run backups of the database, but that was also unfortunate because we were so deep

in trying to figure out what was going wrong.

we didn't actually, or I didn't actually think through how complex a database rollback is.

And it's actually a lot easier than I thought at the time. I did not stop and think that's

a bit unfortunate because we could have very easily played that database back

and have avoided doing the builds. Yeah. And that's the thing, like in these situations where

you have to make a decision and you make that decision under pressure and while the world is

falling around you, it's sometimes difficult to make the best decision in those situations.

I mean, the other thing that happened last week,

completely outside of this tech stuff is I played a paddle game. Paddle is a kind of a tennis game.

They play here in the South of France. And I hurt my back. I got, did you call it lumbago in English?

Sure, yeah.

Lumbago in French, yeah. And I was completely wrecked. I couldn't move,

couldn't even sit the first couple of days.

since Wednesday afternoon. That certainly didn't help. And it's really, really hard

to think straight in these circumstances. So last week I deployed that release that

nuked half of our versions. I ruined our podcast recording. I ruined my back. I hope this week's

going to go better.

But apart from that, how was the rest of the play? Yeah.

Yeah, just going great. It's just going great.

So in slightly more positive news, we have also been working on...so I think we mentioned

this a few months ago actually, that we were putting in a pull request on the Swift.org

website repository to add a packages page on that site to start to bring in some of

the Swift package index data onto the Swift website

to help kind of showcase and expand the package ecosystem

and what people see on that site.

So we're getting a little bit closer now to merging that.

And I thought it might just be interesting to run through

how we get the data into that page.

And there's the technical side of it,

which is physically, or not physically,

but technically, how do we query the database,

query the API, put together the right file,

submit it as a pull request,

and that will be the technical side of updating it,

but actually that's not very interesting.

The more interesting bit, I think,

is how do we pick the packages that are on that page?

So if you haven't seen the page demo yet,

we did link to it last time,

but we'll pop a link in the show notes again

to the, we have a staging site for it set up.

And that staging site has a little bit of a preamble

about what packages are and what the Swift package index is

and that kind of thing.

But then it quite quickly goes into a set of lists

of packages.

And some of those lists come straight

from the package index database.

So for example, there are categories in there.

So there's a list of six networking packages,

six packages that might help with testing

and that kind of thing.

Those, the sources of that are fairly straightforward

in terms of that's just the top six search results

that come off the Swift Package Index site.

So if you did that same search on the package index,

you'd get the same six packages

as we're currently gonna be showing on swift.org.

Then we have a couple of lists that are things like,

for example, I think one of them at the moment is

packages that have macros in them.

So kind of highlights macros are a new feature in Swift 5.9.

And so let's highlight some packages that use that feature

on Swift.org so that people can see them.

But again, the results that come in are just,

if you did that search on Swift package index,

it would be in exactly that order.

But actually the top category on the list is probably,

I think, the most interesting one.

And it's called, or we've called it the community showcase.

And this is a manually curated set of packages.

And I think it's interesting to talk about

where that manual curation happens,

how it will happen going forward,

who's responsible for it, that kind of thing.

We're about to make a post on the Swift forums about this.

So this is slightly premature,

but I think it's worth talking about here too.

So the whole idea behind the Community Showcase

is that it shouldn't try and be like a best of the best

packages or something like that,

but whatever packages are being discussed in the community.

So whether that be on a podcast like this, for example,

where we're gonna talk about some community packages later,

or any other podcast from the community,

or blogs or newsletters or something like that.

So what packages are being highlighted?

What packages are people talking about?

And the only rule we've made actually

is that nomination of a package to go in this showcase

should be, you should nominate somebody else's package

rather than your own.

So for example, when we do the community packages

at the end of this podcast,

we don't link to our own packages.

We talk about other people's packages

and other podcasts and newsletters and things like that

also doing that. So that's the rough criteria and we will collect nominations

from people who run that kind of, you know, podcasts and blogs and things like

that via the Swift forums. But then of course those nominations have to go

through and six of those - let's say there are more than six nominations - we have

somebody has to make a choice of, you know, which actual packages go onto that

page. And this is where the Swift website workgroup initially comes in. So I'm a

member of the Swift website workgroup and we do various bits of development

and try to push the Swift website forward a little bit. And we do several

bits of work towards kind of making the Swift website a little bit better and

kind of pushing things forward in terms of the content on Swift.org. But also the

Swift website workgroup is going to be the group which is responsible for

initially curating which of these community packages make it onto this

page. And this is going to happen on a fairly regular schedule. So we're

thinking it'll either be every two weeks or maybe every month that these get

updated, something like that. And so there'll be a series of kind of phases

to it. We'll collect some nominations from people who run these community

resources and then the work group will make a decision on which one goes in and

then we'll finally update the Swift website via the pull request that we

talked about earlier. And so we hope that that is a reasonable way to

organize this. It's certainly... we don't want to make the decisions. The Swift

website workgroup is you know managed by Apple and actually the Swift website

workgroup is only temporarily going to be responsible for this. There was a

blog post I think again like a couple of months ago where the Swift

project announced that there would be some new workgroups coming and one of

those work groups is the ecosystem work group. And one of the things that that

work group is going to be responsible for is the package ecosystem. And so I

think the plan eventually will be to have that work group make this decision

rather than the website work group. But what we were very keen for it not to be

was us. We don't want to make this decision, do we? Yeah, I really liked what

you said at the start that this ecosystem category is not so much about

the best package or quality as a metric, but what's interesting and what's being talked about.

And I think this is sometimes reflected also in our choices where we pick stuff that's just

interesting because I think there's more than one reason to look at packages. It can be inspirational,

it can be educational, it can be fun. It can be something that someone who's learning the language

or learning about packages is just trying.

And I think all of these should get some space.

It shouldn't just be about, you know,

what absolutely bulletproof, perfectly maintained package

do I need for my networking?

Of course, that's one of the reasons

why you need a package index or package recommendations,

but it's about more than that.

I mean, a lot of this is educational.

I look at packages that I know I won't have any use for,

but that I just find interesting, you know,

you know, in the way they present themselves, how they do things, what their documentation looks

like, the readme, that sort of stuff. It's often interesting aspects of the language that I don't

know well that I want to learn about a bit. Or just to observe someone taking their first steps

in publishing a package. That's also interesting and fun to see, and I know how that starts.

because we've all started there, right? We've all had our first package, our first pull request

something up and it can be really daunting and seeing that happen and maybe help it along a bit

with a pull request yourself if you notice something can be really nice and welcoming.

And that's part of why we called it the showcase. That word showcase is literally what this is.

and we want to highlight brand new packages there

that maybe haven't had that kind of battle testing,

but they may be interesting.

And I think it's a really positive thing

that Apple wants to showcase that kind of package

on the official website as well.

And that shows that it's not just about,

it's not all about, well, you can't get on this page

unless you absolutely make the best package there is,

because what does that even mean? (laughs)

But this is a look at the ecosystem.

This is, you know, the Swift 6,500 packages,

something like that.

But there's all sorts of interesting stuff

going on inside that thousands of packages.

- Yeah, definitely.

- So the next thing that will happen with that

is that we will make a post to the Swift forums

and the purpose of that post is obviously

to lay out our plans a little bit,

but also to ask for the primary purpose

is to ask for feedback.

So if you have any feedback on this idea,

nothing is too late.

Yes, we have a prototype up and we have been through,

like if you go to the pull request,

you'll see lots of reviews there and tweaks

and we have been moving it forward,

but this is not,

I think the stage that I would consider this at is,

We'd be happy to merge this given no feedback comes from the community, but that feedback

from the community is absolutely within scope to make changes to what we're proposing.

Yeah. Right. We got any other news?

I don't think I have any other news. So should we do some packages?

Actually, one thing we could briefly talk about, which was in our messed up recording,

but that's the first round of Dependabot updates that we saw against one of our projects in

the Swift package index.

So we mentioned this three weeks ago now that there's a new feature on GitHub.

If you have a Swift project, they now run a dependency check against your repository.

believe this is currently only happening if you have a package.resolved checked in,

because that's the underlying information they use to discover whether any of your packages that

you're using as a dependency have any issues. And if that is the case, and it's not even an opt-in

that happens automatically, it will highlight this in a section on GitHub. I'm not sure what

the panel actually is, we'll add a link to the show notes. This actually happened to us. So one

of our packages that we don't update frequently was running an old version of Swift Neo, which had

some updates that fix CVEs. And those were highlighted and alerted us to that fact. And then

we ran a package update to update it to the latest version. So that's really nice. Again, we'll add a

link to the show notes to show what that looks like. And I believe package

resolved being checked in is a requirement, but that's probably the case

for most packages. So yeah, there you go. Yeah, I think it's really nice

that this is on by default for repositories that have that file. I

think you can actually go a step further if you want to, and this is not on by

default, but you can go in and say "also please raise a pull request" and the

dependabot will, if it finds a vulnerability, it will then take your

package.swift and package.result file and upgrade both of them if necessary to

a version that no longer has that. So you can have it literally

open that pull request and all you have to do is merge that to get the new

dependency in there. We take a slightly different - I think we mentioned this

again three weeks ago - we take a slightly different approach to that in that we

have a script that runs every week that says here are you out all of your

out-of-date dependencies so we're not gonna have that automated dependable one

on but we we do love this this feature of the notifications yeah yeah that's

really great okay should we should we do some packages join a kick us off fun I

shall do so my first package my first pick is called xcbeautify by Tuist

I absolutely love this. We've been using xcbeautify for quite a while in the Swift package index itself, not only in the project.

So what I should explain what it does. xcbeautify is a executable, a command line executable that you can pipe your Xcode build and Swift build output and test runs through.

And it beautifies the output.

If you've seen what XCTest failures look like or build failures look like, it can get a

bit messy, XED beautify.

Makes that nice on the command line.

It even adds ANSI colors, so you get nice colored output.

Works also in CI as a nice output there.

We've been using that for a while.

Not only in our CI, we've also run the Xcode builds through Xe-Beautify of our build output

that we generate.

So if you go to a package page and click through to the builds and then click on any of the

Xcode builds, you know, like the iOS watchOS to be OS builds, that output there is run

through Xe-Beautify to make it look nicer, make it more digestible because it can get

really noisy.

Now a new feature they added in version 0.21 and I think now they're also there even on

1.0.0 so if you go to the latest major version you'll effectively have this.

They added a new GitHub actions renderer which doesn't give you quite that ANSI colored output

it but it generates an output that is picked up by GitHub to surface test errors in the

GitHub Action UI. And that is really, really nice because in the package index, we have

hundreds of tests and if there's a failure, it's really hard to find them because we have

our log output is thousands of lines.

So you have to scroll a lot to find the error.

What this does, it shows you the not only the error output, you know, what the failure

was with the expected and actual values.

It also gives you a click through to the source of the test so you can read all the

context around it. And this is on the GitHub Action overview and it's really nice. I think

it also inlines into pull requests alongside the code there. It's fantastic. I just absolutely

love it because in the past I really dreaded when there was a CI failure. I often just

ran rerun the tests locally because I couldn't be bothered scrolling through thousands of

lines of tests. I thought I went, I'm just going to get a coffee, run the tests and see

what's happening and now it's just all there. You can click through and see the results

straight away. Absolutely brilliant.

- I love this feature. I think it's such a time saver. I was in exactly the same boat

as you if I got a CI test. My first port of call would be to run the tests locally again,

and only if the test passed locally would I start to look through that log file.

- First port of call was to shout profanities and run it locally.

right yeah shout to my neighbor kid here that's right so yes it's a it's a great

step forward for it and I think I'm just happy that we've we have this on our

project now it's saving time already yeah absolutely okay my first package is

by Vikram Kriplini and it's SwiftUI Shimmer so this is a bit of a package

that a package that has a little bit of nostalgia to it but also is is still

very much useful today. Do you remember when the original iPhone came out and it had no

passcode on the original iPhone? Why would you possibly need to protect? Yeah, it's

wild that they didn't have a passcode on it. Because there was nothing to protect, right? It had

almost no information on it and we lived - it was a different time, Sven. It was a

- I did lose it.

I lost an original iPhone without any passcode and stuff.

I changed some, I mean, obviously changed my,

I'm not even sure, was it even iCloud at the time,

my password, but--

- No, no iCloud.

- Unimaginable these days.

- Yeah.

Anyway, so what it did have instead of a passcode

was a beautiful bit of UI where it said slide to unlock

and the text of the slide to unlock,

there was a kind of shimmer effect

that went from left to right across the text

of a little at an angle,

as if the light was catching it.

And it was to indicate,

because don't forget touch screens were fairly primitive

at the time, this was to encourage you

to interact with that element.

And it was a lovely bit of UI,

I think one of the most beautiful bits

of the first iPhone.

So SwiftUI Shimmer is a package that brings that

to all of the modern platforms.

It's actually been around for a couple of years now.

But the reason it caught my eye this week

was because you can add a shimmering slide to unlock screen

on your Vision OS app with this,

with this SwiftUI modifier in this package.

And I think we should encourage everybody

to add slide to unlock to their Vision OS app.

- And then you slide across it with your eyes.

- That's right, you just look from left to right

and the application unlocks.

Actually, I don't know,

this is a little potential rabbit hole

that we're going around here,

but I don't know how,

how does VisionOS do the authentication?

How do you, it must have a class code or a lock or something.

Is there a biometric?

- No, it doesn't, it scans your iris, I think.

- It scans your iris, okay.

- I'm not sure what the name of it is.

There's a marketing name for it.

It's not eye lock or something,

but it is something related to the eye.

But I'm pretty sure it does an eye-risk scan.

Unless I'm fantasizing now,

I'm pretty sure that's what's happening.

- I'm sure I knew at one point,

but I've already forgotten.

So we'll have to see when the device gets here.

Anyway, that's SwiftUI Shimmer by Vikram Kripalini.

- Nice, really nice.

I love that.

It was so, so powerful in what it communicated

and how well it did that.

It's just amazing, yeah.

Definitely lost something there.

- There were several bits of breakthrough UI

with that first iPhone drop.

It's a very rare event that you can have something

that pushes UI forward so far in one moment.

There was a time before the iPhone

and there was a time after the iPhone.

- Yeah, scrolling definitely is.

You know how it continues when you flick it

and the rubber banding at the edges

and I think those are the key things,

the key inventions around these touch screens

that were transformative.

- Well, and the other thing was multi-touch.

- That really was so powerful.

I watched a kid, like in the early days of the iPhone,

toddler pick up an iPhone looking at pictures

and pinching and zooming naturally.

That tells you everything you need to know

about that interaction, that it works.

If a child can pick it up and just naturally do it.

It was so, that was astounding to watch that happen,

watch that, observe that interaction.

- Back to the Over 50s podcast.

I'm actually quite disappointed

when I pick up a physical piece of paper

and I can't do it on that because I need it.

- All right.

This does not zoom, yeah.

- Okay, exactly, nothing's in it.

- My next package is called Swift Prompt

by Michael O'Brien and Michael O'Brien.

I'm actually going to make that same joke as last week

because it's new to all the others, but not today.

We have this nice little bug in our website

where we spell out the author name twice

and that's because I presume that author has commits

with different email addresses and we don't,

at the moment, de-duplicate them.

So--

we figured out what it was, isn't it?

- Oh, right, right.

- The two different apostrophes.

- Oh yes, I figured it out on the podcast.

So there's the apostrophe exactly one is the-

- We did, we figured it out live on our failed recording.

- Well, we had some successes,

but they just never see the light of day.

(laughs)

Right, so the package is a command line interface package

for text input and option picker prompts.

And it's absolutely beautiful.

You need to look at the readme of the package.

Um, what that looks like.

I, I just want to run off and write a command line tool that, that uses it.

It looks really nice is using these, um, Unicode, um, what you call them glyphs.

There's a little screencast on the, um, on the readme to create menus that you can

arrow through and has a password prompt as well, where it hides your inputs.

Uh, absolutely beautiful.

it's if you have any sort of input that you're capturing

for a script, use this, it looks really fantastic.

Yeah, it's a small little package.

That's what it does.

It apparently does it really well.

It's called SwiftPrompt and is by Michael O'Brien.

- So there's always a decision to make

with this kind of situation

where you're writing a command line tool,

you need some input.

And one way is to go down the pass everything in

as an argument, which is the Swift argument parser

way to do it.

And this is a nice alternative to that,

where you might pass some things in as arguments,

but then you want to have some interactivity.

So maybe you want the user to make a choice

between a few known options,

or maybe that one choice depends on another choice,

and that's hard to get right

with just purely arguments.

And so I can see good uses for this,

where for slightly more complex command line tools.

- Yeah, absolutely.

Or because if you pass stuff in through the command line,

it is visible.

There's ways that can be seen

if you're on a multi-user system, for instance.

So that might be a reason to use it.

That's direct input into the process

that isn't telegraphed on as a command line input

or an environment variable.

- Exactly.

My second package is called sf2lib by Brad House.

And this is not only a new package to me,

but the content or the purpose of the package

was also new to me.

So this is a package that passes and renders sound fonts.

Have you ever heard of sound fonts before?

- Sound fonts.

Oh, is that like an accessibility feature

where it has little, oh no, I was thinking of sparklines.

- That would be a great idea, but it's not that, no.

(laughs)

A sound font is a, well, it's pretty much exactly

what you think it is.

It is the equivalent of a font,

but with musical or sound samples,

any kind of sound samples.

So it is a file format that holds both MIDI map information,

so the MIDI notes mapping to certain sample files,

but also it contains the sample files as well.

So for example, you could create a sound font of a piano

and have all the different recordings of all the keys

at various different velocities and things like that,

and then distribute it as one file,

which is here is the piano sound font,

and people could render that and play back

the right samples at the right time based on MIDI input.

So I love the package index because not only does it teach me about new packages, but it

teaches me about whole new things like this because I haven't come across sound fonts

at all. And it's based on a C++ library behind the scenes and the SF2lib I believe is a wrapper

that supports iOS, macOS, TBS. And yeah, it's not something I'm going to use in the next

few weeks or potentially ever but I found it really interesting to learn

about this. Nice, interesting. So how would you actually use it? What's the... is

that to create those sound files or what's the... what does the package... No, it's

not to create them, it is to parsing and rendering of them. So by rendering I

presume it means playback. Yeah, alright, interesting. It does mention that it

depends on DSP and audio classes from an AUV3 support package. So I think

there's almost certainly playback functionality in there.

All right, my third pick is called Swift Async Assert by Angoo Software. And this

is a really nice convenience package when you're dealing with tests of async

functions, because when you do that, you may have noticed that you, for instance, if you try and

write a test XCT_ASSERT= what you put in there can't be async because it doesn't have an async

context. So you'd need to either grab the value first by, you know, running a let temp variable

equals a weight on your thing and then stick it in there. That's obviously a workaround or you

have to write your own wrapper function that does that for you, which isn't hard, obviously.

I mean, that's an easy thing to add. We've actually done that in a couple of cases in

the package index in our tests. This nice little library does that for you. It packages all those

up, does that for all the XCT assert variants out there, so you don't need to cover them all

yourself or start with a few and then always be annoyed when a new one pops up that you haven't

covered yet because that's the situation we are in. We got a fair few, but as soon as we need

exit assert equals with accuracy, we'll have to go back and add that one. So it's really nice to

have this all packaged up. And it's one of those packages that you can, that's easy to adopt,

right? Because this you can do yourself easily or add it if upstream it's missing, you can open a

and a pull request and added.

I love these kinds of packages.

They're easy to depend on because it's something

you can absolutely do yourself,

but it's a time saver that you don't have to.

So yeah, Swift Async Assert by Angoo Software.

- That's great.

My final package this week is a package called Bezel Kit

by Mark Battistella.

And I love how minimal this package is.

It probably has more than this,

but the main functionality of this package is one method.

(laughs)

And it's not even an instance method, it's a static method.

So how good is that, right?

So what does it do?

It tells you how big and what shape the corners are

on whatever device it is running on.

So for example, on an iPhone,

you have the rounded corners at the screen edge

because none of the corners are square

on the iPhone screen.

And they're not even standard corners,

they're squircle corners.

So I forget the mathematical name,

but it's a slightly--

- Squircle.

- It's not a perfect, it's a squircle,

yeah, exactly, it's a squircle.

And the purpose of this package is that if you have some UI

in your application that wants to inset

from the edge of the screen by a certain amount,

it's quite difficult to get the radius of your squirkels

to match the radius of the device squirkels

because not only do you need to make it a squircle,

which of course there are APIs to do that,

but as you inset from the edge,

the size of your corner radius is going to be different

than the size of the corner radius on the device

because your inset, like it's not the same size.

And so what this will do is it will tell you,

it will basically give you the device bezel size

and make it really easy for you to draw perfect squirkels

inside the inset of whatever device it is you're on.

nice. Yeah, the readme, I'm just looking at it, lays that out nicely and gives the examples what

that looks like as a nice... Better than I did.

Yeah. Well, I mean, it has the advantage of being able to show a picture, which you

kind of have to try and paint with your words. But yeah, it looks really nice. I'm wondering,

you probably don't know if, does it have to sort of hard code and figure this out? So if something

new came out this September with a new geometry. Does it actually use the, you know, the insets

that it knows about to do that automatically or would it need to? It's a really great question.

Ah well, maybe we'll know by next time. So that's Bezel Kit by Mark Battistella. There we go, so

we will be back in two weeks or potentially next week if the recording has failed again.

We will find out in about five minutes whether we'll be back next week or the week after.

But hopefully with a perfect recording we'll be back in two weeks

time to talk more packages and we will see you there. I hope so much that we'll

see you in two weeks. Bye bye. Me too. Bye bye.