Swift Package Indexing

This should definitely go in.

- Got the cat going, yeah.

- Everything.

This has like strong Twitter Spaces vibes.

- Well, I think it's a little more,

it's a little more professional

than we used to do on Twitter Spaces.

Not that much more professional,

but a little bit more.

- It had its charm, to be honest.

It had its charm.

- Indeed, and I kind of liked,

let's talk about it for a second.

I kind of liked it because

there was a couple of really unique features

of it that I thought were really quite strong, which is it had that network effect.

There were advantages and disadvantages to this.

As soon as you went to even enter a Twitter space, people would start joining because

it would pop up at the top of their timelines and they'd just come in.

Now the disadvantage of that is that you couldn't set up your space before people started joining,

which was always a little bit like, oh, it's all just happening all at once.

But the advantage of it was that you instantly got people coming in and listening and interacting

and that was good.

Very, very different to a podcast.

But yeah, I thought it was a good service.

Yeah, I really liked the casualness of it.

You're sort of easing into it and it's almost like as a listener, there's an open

door and there's some people fiddling around with microphones and they're sort of doing

their thing and you check out, oh, okay, it says Swift package indexing might be interesting.

I'll just, I'll just wander in, sit down and see what's going on. And I really liked the

appeal of it. I also noticed when we started not doing it live, it felt a bit weird initially

because I don't know how to describe it. When we sat down for the Twitter spaces and even

though there weren't many people, there were some people and I felt like,

you know, we weren't just talking to each other, but there were other people

listening that I was sort of in my mind addressing and that changed perspective

slightly, ever so slightly. And I think that has settled down a bit.

So I'm sort of conjuring up a virtual audience in my head now,

as it's just the two of us talking.

But it was a very interesting, subtle difference in how you sit down and chat.

Yeah. And if you told me beforehand we'd be doing a live recording,

that would have probably, well, that would have certainly stressed me out more than it actually

did when we sat down and did it. We, someday, you know, at some point, I don't remember how it came

to be, we decided we were just going to try and do this. And we sat down, connected and chatted,

and there was no nervousness or weirdness about it, really. It was quite bizarre how it happened

and then how it tended to be a really interesting experiment

for the time that it lasted.

- You're right, and I think that the casualness of it

is its strength, or was its strength,

depending on, I actually switched to the spaces tab

on the Twitter app the other day,

and nothing loaded, so maybe it's no longer,

but that definitely was its strength of just like,

well, you can just, you don't have to make this

into a big deal, you can just open up a space

and start talking and people can start listening.

And the other really nice thing about the UI

is it showed the people.

So when it showed you a space at the top of your timeline,

the icons of the profile pictures that were in the space icon

were the people who you followed who were in that space.

And so you could recognize people you knew

that were listening to something

and that's a really great way to get people to.

- Yeah, I love that.

I really like to see familiar faces,

like literally faces pop up in the UI.

I do wonder, I mean,

Mastodon, which is where I've moved to,

is interesting in many ways,

and one of the ways it is quite interesting,

apart from just being a micro-blogging service

similar to Twitter,

It has these other social networks powered by the underlying protocol activity pub, like

an Instagram, like picture sharing.

That's called PixelFed, is it?

Yeah, exactly.

And also a YouTube like video sharing thing.

There's also something about podcasting and I've been meaning to explore this a little

further because I do suspect there is something that could work a little bit like a Twitter

space with audio, perhaps also with video.

I certainly wouldn't, you know, it wouldn't have the client side integration yet quite

like Twitter used to have, but it feels like there's something there that could be hooked

into and perhaps with a little glue or web page or something could be made to work a

a little bit like it or maybe there's even more than I imagined there being already.

I think it might be worth having a bit of a look or if someone listening knows more,

I'd be really interested to hear what the options are.

I do know there's some podcasting stuff that is based on ActivityPub available already.

I just haven't had time to look into that.

Sounds like some non-coding work.

of non-coding work. That's exactly what I've been doing over the last few days.

You may or may not know that there is a legal entity behind the Swift package

index project. And it's a company we set up because we needed a legal entity

actually, originally for a Apple developer account.

And that was the thing that pushed us over the edge into setting up a legal

entity because we needed to register for an Apple developer account so that we

could sign package collections. That was

the initial event that made it

happen. But that is growing up a

little bit as of this week, which it now

has a bank account, which it hasn't had so

far because we've been dealing with the

money just kind of without, we really

didn't want to start up the whole

accounting process for that company, so

we've been dealing with sponsorship

money outside of that legal entity at

at the moment, but it's time for the project to grow up a little bit and creating a legal

entity was one part of growing up and giving that legal entity its own bank account is

another part of growing up and it feels like we're coming out of the toddler years and

into the small child years.

Yeah, it's interesting.

I mean, going up to, well, it's like year three, right?

Yeah, in April it'll be three years.

So yeah, we're getting there.

- It is, and it's also probably worth

just talking a little bit about

the kind of finances of what we do here.

So we are currently supported by two mechanisms.

We have GitHub sponsors,

and if you are already a GitHub sponsor,

then thank you so much for that support.

It's literally invaluable to us.

And that's organized through obviously GitHub's sponsorship system.

There are many open source sponsorship systems around there, but we picked,

we picked GitHub to run ours.

And then we also have a couple of adverts on the site from Stream, who writes a

chat SDK, so you can add kind of real time chat to your applications, and Emerge,

who run several tools actually that will help you slim down your applications,

optimize startup time for your applications and various other things around kind of

optimizing what you ship to the app store.

And so again, I think it's worth us, we haven't mentioned our sponsors so far on

the podcast, and I'm not sure we'll do it every single time, but given we're talking

about this kind of stuff, this company stuff, I thought it was nice to give them a quick

mention.

And you really would help us out if you haven't heard of either of those companies, nip to

the Swift Package Index page, and they've both got links on the homepage there.

So yeah, so that's our primary source of income for it.

We also have financial help in a different way from companies who support the hosting

of the packaging.

So we have our main hosting where the website runs and where all of our Linux analysis and

build processes run is provided by Microsoft Azure.

It's always a pleasure to work with both of our hosting providers.

when we approached them, they couldn't do enough for us.

They were fantastic.

And they were actually the second hosting providers

come on board.

Originally, Mac Stadium were our hosting provider,

and they remain our hosting provider for our Mac, iOS,

watchOS, and tvOS build infrastructure.

So and again, it's such a pleasure working

with both of those companies.

Their only questions are, how can we help?

That's basically how I describe those relationships.

And we couldn't do this project without their help

because we, the amount of hosting going out on one side

and the amount of income from sponsors

and advertising on the other side, they don't add up.

- No, those numbers don't line up, no, unfortunately.

And we should say, I mean, this is more or less

a full-time project for the both of us.

The income that we have is really nice

that we do appreciate it a lot.

It wouldn't support the hosting costs that we have.

It also doesn't, as of yet,

support our actual time investment.

So that does help us a lot,

but don't take away from us opening a bank account

that we're overflowing with funds or anything.

That's not quite the case, but...

(laughing)

- We're not getting into investments with all our funds.

- No, but it is really great,

especially also the individual GitHub supporters.

It's always great.

Every week we update the list of sponsors,

like on our homepage, you see the little GitHub avatars

and they shuffle around as you refresh the page.

And every week we update to the latest list.

And it's great to see when the new faces

appearing in the list of sponsors.

And if you feel like you want to be in that list,

don't hold back.

We do appreciate it a lot.

- Absolutely.

Yeah, and I do think it's nice to just kind of

step back from things a little bit

and look at obviously how far we've come

with the actual project, but how far we've come

with making this into something that we hope

will be here for a very long time

and providing the service that it provides

and more for many, many years to come.

- Yeah, yeah, definitely.

Right, do we have some techie news to talk about as well?

- I think we have DocC uploading news, right?

That is right, yes.

So the doc uploaded out, we talked about last time,

is actually live now.

And it was pretty much done for quite a number of weeks now

and I was tweaking it a little, trying to tune it a little,

mainly around the difficulties of trying to get

this whole process to finish and to run

within the 15 minute AWS Lambda hard cutoff.

So there's a 15 minute timeout, a runtime budget that you get.

And after that, the Lambda is killed.

And in all my testing, there has never been a problem with the largest

dock set that we have and that sort of spawned this whole thing.

But yet I was caught out at the last minute with a surprise with respect to performance,

because my testing that I've done, pretty much almost all of it,

I have done with the ARM64 Lambda, the Graviton2 processor node on AWS.

And that's purely because the turnaround for testing was easy for me to deploy from an ARM Mac directly to an ARM binary into that Lambda.

I did test initially, I did compare the x86 and the ARM64 performance,

at least in one aspect and that was the unzipping of the file and that took

like around 40 seconds on the ARM64, it was a couple of seconds faster on the x86

and that sort of gave me confidence that they would be operating at the same level of performance

and then I just subsequently focused on trying to get the test one, so the ARM64 Graviton based one

to run as fast as possible to stay within our 15 minute window and that worked fine.

So the ARM one consistently ran in around 11 minutes

in all my testing without a largest doc set.

Now, when all of this was done,

we debated whether we should deploy the production version

as an ARM64 or an x86 variant.

And ultimately we decided to go with the x86 variant

because I had already set up an auto deployment GitHub action

that would allow us to just tag a version

and that would then auto deploy into an AWS Lambda.

So there would be no blessed development machine setup

be required to deploy into that Lambda.

Literally just tagging the thing would do it all from there.

I toyed with the idea of making that process ARM-based,

but the problem is GitHub Actions,

so the GitHub runners aren't any ARM64 runners.

So the only option really would have been to set up our own hosted runner,

which isn't a huge deal, but at that point, given how often we actually plan to change that Lambda,

if you set up a GitHub dedicated runner, you probably might as well just have it on one of

our or both of our machines to do it ad hoc whenever needed, because one environment would

would have to maintain anyway, so it might as well be one

that's not as removed because we'd have to pick

one of our max stadium machines to host that as well.

And it's just a bit weird and awkward

to set that up in parallel.

So that's why we arrived.

We said, all right, let's use x86 to deploy.

And then the funny thing happened, we were all set.

I tagged the thing, gave it a final test,

and it timed out.

So the x86 runner actually took

more than 15 minutes to finish.

and it did that consistently.

Like it did not finish within the time interval.

And I was really stumped because in my early testing,

I had actually expected that to be slightly faster.

And the weird thing is the part that is,

you'd expect to be compute bound,

which is the unzipping was as fast

or maybe even slightly faster than the ARM64 version,

but all the networking stuff happening after that,

like the transfer of the unzipped files,

the 70,000 files of one gigabyte in total into S3

actually took way, way longer with the x86 variant.

Now, I guess that's not architecture related.

Perhaps it's where these things run.

So I'm guessing, I have no idea,

but it looks to me like in this case,

at least in this case, well, A, in this case,

it's very obvious that the x86 Lambda,

you know, takes probably around 40% longer

than the ARM64 variant to the degree

that it wasn't actually usable for us.

So that took the decision out of the picture

to actually use GitHub Actions to deploy it.

And we now ended up doing what we debated doing earlier

and it's just deployed straight from our dev machines

into the production environment.

But what's really bizarre is that the x86

takes so much longer, I guess, in the network traffic.

I found it really weird, but that's where we arrived.

So that was a lesson learned for sure.

I thought I tested the performance aspects

that are going to be the critical ones,

and yet, yeah, there was a surprise there.

- Yeah, and to step back slightly

from the kind of nitty gritty of executing these,

we do have a fairly significant problem

with the size of these archives.

And we are talking to the documentation, the DocC documentation team about, so

we're both members of the documentation work group that Apple set up.

Um, and we have raised, um, a couple of times and I know that it's kind

of on the list of things to look at.

Swift syntax is the, is the main problematic package that we have, that

we've been using as our, as our test cases in this one.

Yeah, it is.

Um, so there's certainly not a gigabyte's worth of actual type

documentation or source code in that package.

And so it kind of, the current output of doc C

is significantly larger than hopefully

it needs to be at some point.

And so it feels like we are right on the edge

of this just being possible right now.

And I hope that that size heads down instead of up.

- Yeah, I wonder how much of it is actually the size

giving us the long upload time.

I guess also all the requests, round trips of 70,000 files,

individual files being synced.

That's also not helping.

I think both figures need to go down a bit.

I do wonder how that will be possible

because as far as I can tell,

the number of files pretty much scales with the symbol.

So each symbol that you can click on has a representing file

with the metadata to populate the page, the documentation page.

And I'm not sure how much that's possible architecturally in Doc C

to bundle these up or group them somehow,

you know, move away from these being individual files in the file system.

But I still, I'm not sure there are 70,000 symbols in Swift syntax.

I don't know, there might well be, but I suspect there's some duplication happening

in the package overall that hopefully can be reduced at some point.

Yeah, but the good news is that it's now deployed.

Yeah, exactly. We're currently only dealing with that one package for the moment due to the way

we've onboarded and set our processing thresholds, but we'll subsequently lower this and onboard

more packages because the process overall is faster for all packages and should make it

it's smoother and easier and avoid any sort of difficulties with other packages

that might run up against our internal,

because we also have a time budget for the build process

and the upload process both together.

And if a build takes very long

and then the documentation stage comes after that,

it might actually be cut off by our time constraint on the whole build process.

So it'll certainly help to offload this to the Lambda entirely soon.

Yes.

Right.

That was the Doc Uploader news.

Did we have anything else?

So kind of.

I have one more thing which I'd like to just briefly mention, which I saw today.

And it's a new website called areweserveryet.org.

Yeah, I saw that one by Tim.

Yeah.

So this is from Tim Condon, who is one of the Vapor team members.

And he's also on the Swift server work group with Apple.

And he had a look at this,

a Rust site called Are We Web Yet?

And this is the,

here's the terms of the Swift version of that site.

And basically, and I think we've needed something like this

for a little while.

It's a website which just gives a bit of background

information about Swift on the server.

It doesn't try and teach you Swift on the server,

although it does give you links

to Swift on the server tutorials and various other references that you can read.

But it really just says, here are the main frameworks. We've got Vapor, Smoke, and

Hammingbird. It says that Hammingbird is quite new. Vapor and Smoke are production ready and mature.

It talks about how the ORM that we have works. Or not even how it works, but just gives you a link

to it, give you places that you can go and find out a bit more.

And I think this has been missing from the kind of server-side Swift.

In fact, I was writing something about it the other day for iOS Dev Weekly, and I actually

changed what I was going to write because I couldn't bring myself to go and Google all

the names of the different frameworks.

Obviously I know Vapor because we use Vapor.

I remembered Hummingbird, but for the life of me I couldn't remember Smoke.

And then I maybe thought there was another one as well.

I thought Amazon did one.

Wasn't there one called Perfect or something at one point?

But some of them have gone.

Some of them, like Kitura has sadly, I mean it's still up and around, but it's not really

actively developed anymore.

So I thought this website was worth mentioning.

Yeah, really nice.

So we've got some good information on WebAssembly there as well.

I am quite bullish on Swift on the server,

because I enjoy it tremendously.

And I really hope that this just raises awareness

about what's possible.

And especially now that Async/Await

is pretty much in all the frameworks,

it is such a nice environment to develop in.

And I hope it gets picked up more.

It's, you know, we've been over this before.

I think pretty much everything is there

that you might need.

It doesn't have necessarily the depth,

like, you know, the number of packages implementing the same thing in multiple ways, but there

is something there for pretty much anything, everything you might want to do server-side.

So I think it's really great.

Yeah, and I think you're right to be bullish on it for backend services, like an API backend

in Swift is, you know, you're going to have a great time developing something like that

with whatever framework you use.

I think there is quite a lot of work still to do if it's to become a front-end web application

platform as well.

So obviously we're building a front-end application with Vapor, but it feels like it maybe has,

there's more work to do on the front-end side of things than the back-end.

But yeah, it's all, we're heading down a path here and we're heading in the right direction.

Yeah, I mean, I guess in Swift as a language and ecosystem,

it's almost like the default is a JSON API backend

and then a mobile app frontend, right?

So the frontend part is almost like slightly different.

If you ask people,

what's the frontend backend situation in Swift,

they'd probably give that as the answer

and not immediately think of a web frontend.

- Yeah, the frontend is the iOS app or the Mac app.

Yeah, yeah, exactly.

On the other hand, I haven't actually done

a whole lot of web front-end work.

I know that our setup is slightly unusual

in that we're using an HTML DSL to actually render the pages,

but that's not the only way of doing it, right?

There's the more common approach

of using a templating language.

I think mustache is a very common one, or a leaf.

So I wonder if a lot of your concerns about web front-end maturity

would actually look slightly different if that's what we had chosen?

Not so much.

No? Okay. Interesting.

Yeah, not so much because I think actually the generation of the HTML

is pretty nice actually with what we're using with Plot.

And certainly I really have grown to appreciate the fact

that we can manipulate units of what eventually becomes HTML as types and

objects within our Swift code.

That's, there's a lot of power in that system.

The bigger problem is slightly further towards the front end for me.

So in order to do kind of any real modern front end development, you're going to

need something like an Assassin compiler and some kind of JavaScript dependency manager.

You don't obviously need one, but we do use one.

And that kind of stuff is just completely separate from everything else that we do.

And we've got it working like it's no problem.

And we could even spend some time making that more automated by leveraging some of

of the Swift package manager build tools and things like that.

Yeah.

We could potentially integrate that a little further, but at the moment,

developing pure front end stuff, I'm talking like CSS styling and JavaScript

functionality in the browser, the development environment for that is, is

less than ideal because you kind of have to run your project through Xcode to get

the server running and then upload a pure CSS and JavaScript editor and have the

build process for the front end stuff running.

And it's not even as simple as just adding the, the build step for the

front end to the Xcode build process.

Because that, what that would mean is that every time you changed a CSS value,

you'd need to rerun the Xcode project, which is just, that's not really how.

Like I'm front end people are used to very, very smooth, um, workflows where

you just save your CSS file,

it compiles everything in the background

and everything goes live.

And that's what we have right now,

but it's not, that doesn't feel like a particularly

smooth process with a Swift on the server project right now.

- Right, because you sort of have a double approach

you need to build if you have source code changes,

you need to build an Xcode.

And if you have just like CSS changes,

you need to have a file watcher or something

that kicks that off separately.

Exactly.

And that file watcher is, is, is instant and always works.

And so that's where I don't, I wouldn't want to lose that by putting the, the,

the front end process through Xcode, because that's not going to have the

file watcher and not going to have any of that kind of stuff, but at the moment,

there is that quite big disconnect between have I changed HTML or have I changed

CSS or have I changed JavaScript?

And then I need to manually pick which bit of the system to run to

make sure that my changes are live.

And it's fine.

You know, it's not a huge problem, but it's certainly not as...

It's kind of the rough... I would say it's the rough edge of where we are with Swift on the server at the moment.

Well, you know what the solution is, right?

We need a Swift, CSS, and JavaScript DSL, and a Mac Studio that runs it really fast.

You know, I know that there are a couple of people working on CSS DSLs in Swift,

and I don't particularly want to start writing CSS in Swift, honestly.

I think CSS or Sass is a perfectly fine way to write CSS.

But it would absolutely,

for it to even be in with a chance of me considering it,

it would need to be, it would need to solve that problem of,

I don't wanna build and run to do new CSS.

- All right, there's a challenge.

(laughing)

- And with that said,

shall we do some package recommendations?

- Yeah, let's do some packages.

Okay, I am gonna start us this week

with a package from Gil Gonzalez

called Swift Markdown UI.

And it's been around for a couple of years,

but there was a version two release a couple of days ago.

And it's a complete rewrite apparently.

So it's rewrite from scratch with, as Gil says,

a ton of new features and improvement.

And the one that caught my eye

was GitHub flavored markdown.

So this is a native component for Swift UI applications.

It's not, we're not dealing with the web here.

This is back in Apple land.

And there are a lot of solutions, both Apple provided.

You know, it can, the standard frameworks

can render Markdown these days,

but there's a big difference between Markdown

and GitHub-flavored Markdown.

We've run across this with the package index a few times.

at having a good quality GitHub flavored markdown render

for your SwiftUI app,

feels like something that would be worth looking into.

- Yeah, absolutely.

I did see that pop up as well.

Also has documentation hosted on the Swift package index,

if I remember correctly.

- All the best packages do, Sven.

- Yeah. (laughs)

That's why we pick them, right?

(both laugh)

- You know, honestly, that's not why I picked this one.

In fact, I hadn't noticed it at the documentation

until you just mentioned it then.

But if there are two packages

and one of them has documentation hosted by us

and one of them doesn't,

I can't say which one I'm gonna pick.

- Yeah, I saw that and it's really great.

And you're right, the difference is quite remarkable

that it could get flavored Markdown.

I think one of the big things is tables, right?

That GitHub Markdown has, yeah.

- Tables, yeah.

Yeah.

And things like auto lists and task lists.

Obviously, you may not need all those features,

but certainly the GitHub Flavor Markdown is,

in my experience, a good set of changes

on top of standard markdown.

- Yeah, yeah, definitely.

- So that's Swift Markdown UI.

- All right, so my first package is called

KVK Calendar by Sergei Kwiatkowski.

And this is a UI component,

like a calendar component.

And it offers what looks like

really a complete calendar view drop-in.

I mean, if you look at the screenshot

in the package description,

you, at first glance, you probably would think

this is a screenshot of plain old calendar,

you know, like the built-in app.

- Yeah, it really does look like it.

- It has everything, right?

It has time zone support, light, dark mode,

full support for a calendar.

If you need a calendar in your app

and deal with that sort of display,

this is the package to go for.

I did find interesting that it lists support for iOS,

iPadOS, macOS, and Mac Catalyst.

Yet our compatibility matrix

actually only shows support for iOS

and the actual little platform badge,

which is not ours.

this is like a manually set badge also only shows iOS.

So I suspect this is a case where we actually,

correctly I'd say, find that it's only iOS compatible

for the moment because looking at the build errors,

they look to be genuine on the other platforms.

Maybe in the past it was compatible with all platforms

and is only iOS compatible for the moment.

But even so, this is a great package.

So if you're on iOS, this looks really interesting

if you have a need for a calendar view.

KVK calendar by Sergei Kwiatkowski.

- Yeah, it certainly looks comprehensive

if that's what you're building.

And obviously there's been a lot of work done.

I think there's also a standard kind of date picker type

calendar control within SwiftUI these days.

Just to note as well that this component

is UIKit, not SwiftUI.

- Oh, right, yeah, yeah, that's worth pointing out.

- Which is just always worth mentioning.

But this is, I'd encourage you if you're listening to the podcast, just go and have a quick look at the screenshot that's associated with this.

It really does look like the Apple Calendar app.

Oh, interesting. If you are a SwiftUI user, fear not, because in the readme further down, it actually has the UI view representable all spelled out,

which looks like a drop-in, and then you should be good to go to use it from SwiftUI.

Right.

Yeah.

Nice package.

There you go.

Great.

My next one is called Draftsman by Neander Haberty and Draftsman is a layout

builder based on auto layout, but with a declarative approach.

So there have been lots and lots of DSLs around auto layout over the years.

And certainly with SwiftUI coming along, auto layout is very much a UI

kit and app kit technology, which is not been taken forward into SwiftUI.

The layout in SwiftUI is handled in a completely different way, of course.

And this is also not a new package.

This has been around for a couple of years.

But again, there was a recent release 10 days ago, which got this package

into my list of things that I wanted to take a quick look at.

And I quite liked the syntax of this DSL.

So you can kind of say my view dot draftsman dot left equal to other

view dot draftsman dot right.

And then right dot equal to with a parent offset by this much.

And it reads quite nicely in terms of if you're wanting to do auto layout in code,

which I know a lot of people want to do, then this seemed like a really quite a

pleasant DFL to start to do that with.

- Nice.

- And it caught my eye.

- All right, my next package is called Tart

by Cirrus Labs.

Now, this is not a package to use as a dependency.

This is one of those packages that we have in NX

that is a executable, a developer tool,

which is open source,

and is obviously a sort of package that you can build.

you probably would typically install it via Homebrew.

And this caught my eye while I was researching ways to get an Apple Silicon GitHub runner up and running.

Because what this does, this is a virtualization framework based tool

that allows you to spin up Mac VMs with a command very much like you do with Docker commands.

So Tart run and then image name and Tart build and then a base image and some stuff and then you can create new images.

And this is the underlying mechanism the company Cirrus Labs, which is a Apple Silicon based CI provider,

what they use to power their CI.

So a lot of this tool is actually geared and it says so Mac and Linux VMs on Apple Silicon

to use in CI and other automations. So what you can do is use this to build images that you use

in CI and by build I mean not just pull in a macOS 13.2 base image. You can also use Packer

which is a sort of an automation tool to build OS images.

To go further than just getting the base image in,

you can actually run, then install steps afterwards,

you know, to configure the VM, to install Homebrew and Xcode

and all sorts of stuff and have sort of a script

that is run through to build that image.

And then you can even push that image

to OCI compatible registries, which are like Docker registries.

So imagine you use Docker to manage images and run containers.

Effectively think of this replacing your Docker in your command,

Docker run, Docker build with Tart,

and then you can do the same for macOS images.

I've played around with this just a little bit

and built an image based of a IPSW file,

which are the files you can download with the macOS installer files.

So if you use that as an input, you can build one of those images and then spawn it and launch it from the command line.

And it brings up a, you know, like you would expect when you run a virtual machine

with one of the many tools that have spawned up recently based on virtualization framework.

Yeah, and I found that really interesting because this also has plugins to actually set up GitHub Action Runners.

So it looks to me like this would be a really neat way to set up a self-hosted runner

without all the custom setup that you would do with this.

You can actually bake all the configuration into a couple of setup files

that you then run to create the image and then you manage the GitHub runner,

spawning and push it to this mechanism rather than sort of setting up a bare metal macOS machine or VM

and sort of handcraft the machine itself to run,

you can actually script all of this and then make it easily deployable

across multiple machines with all the same setup.

So yeah, it's called Tart by Cirrus Labs.

Interesting. Yeah, I haven't come across this before,

but I've just been taking a quick look at it while you've been talking there,

and it does look interesting.

Oh, and I should add, I read this out, this is not just backwards machines.

you can use the same mechanism to build Linux VMs.

And obviously, Packer is multi-platform.

So with Packer, you can create images for both,

you know, many, many different OSs.

One other note, the thing that I wanted to mention,

it's really interesting how many open source virtualization solutions

have popped up based on virtualization framework.

I find that quite remarkable.

So I've been using, what's it called? Virtual Buddy, I believe.

Yes, Virtual Buddy by Guillermo Arambo,

which is a little app wrapper he wrote that wraps virtualization framework,

which does exactly the same thing really.

You can build your own image, you can run it.

It's a little mackup that does pretty much what parallels and VMware fusion allow you to do as well.

And this has been around for a while and it's based on virtualization framework.

So virtualization framework is really the thing that does all the heavy lifting of

building the VM and managing the VM.

But many people have written these wrappers and sort of innovated on top of it to build these

Docker-like things or VMware-like things to manage VMs. And I find that really interesting,

and I'm really curious where this will lead in the future to easily and very commonly

run VMs more on macros than we used to. Well, I'm also curious whether what Apple did with

with the development of that virtualization framework

is the end of their story with it.

You know, are they happy to be the framework vendor

and let other people build on top of it?

Or is this step one in a plan from Apple

to produce either something that just runs VMs

like all these other apps that have popped up?

Or is there something actually a little more fundamental

in the works?

- Every time in June, every year in June,

This TART thing looks exactly what I would imagine as a dev tool by Apple.

I haven't played around with this enough, but

this really seems to do the thing that I really like about Docker,

where you can build your images and then rely on them to be immutable and always there,

and you just, you know, you bring them up,

have them do their thing, and then, you know, they go away again.

And it's, there's no magic machine that you set up once,

and then you always worry that might drift

from the original config.

This is the great thing about Docker

because you never have these stick around along.

You always make sure that everything you want

happens in the base image.

And I think this is really the thing

that does this for macOS.

I'd be curious to play around with this more.

- Right, so my last package is a testament

to writing interesting release notes

because one of the things that we put in our RSS feed

was not only the link to the package page on package index,

but also whatever release notes

that were entered into GitHub.

And as I was scrolling past all the release notes,

as I was scanning the packages for this podcast,

I came across this release note.

And I'm gonna say the release note

before I even tell you what the package is.

This release includes a complete refactor.

Now it's just better.

(both laughing)

And I read that and I thought,

well, I have to now see what this package is.

And it's a package called Sunkit.

The organization that's produced it is Sunlit,

but as I can see by our new author support,

the person who has written this is Nicolas Marigniello.

And it's a package that I am almost certainly

never going to use,

because what it does is it uses maths and trigonometry

to compute all sorts of information

about where the sun is relative to wherever you are.

So for example, it can calculate first light

and last light, sunrise, sunset, golden hour time,

total daylight duration, total night duration,

all sorts of things like that.

It's a package which is extracted from the app,

which is Sunlit, which is an app on the App Store.

And honestly, I don't really have a lot to say about this package.

It feels like it does exactly what it says it's going to do.

But I just, I love that release note.

I thought that release note was great and that made it worth a mention.

That's great.

Yeah, I can also imagine this is the package you want

when you actually have to deal with this,

because this must be super fiddly.

Right. Who wants to write those calculations, right?

Nice.

All right, my last one is called Preview Resizable

and it is by Juan Duarte or Juan Duarte, I'm not sure, I think it's,

first it's based in Barcelona, so that might be Catalonian, which I don't know how to pronounce.

This is a really interesting package because what it does is makes your SwiftUI previews resizable.

And that might sound odd at first because, you know, you set these things up and you give them,

you typically give them a frame or something,

and then they're there, or I think it has a default as well.

But the way this works is it actually is,

it embeds your preview in a larger view

and then gives it a resized handle.

So you can actually, then, you know, within,

obviously you can't extend it out of the size

of your initial view, but you can make it smaller.

So this is really nice when you,

I suppose when you have a view and just might want to test a lot of individual sizes

and you can't really or you don't want to litter your preview with five, six, ten, twenty

individually resized previews. So I thought that was a really neat idea to make this possible

and to give you something to play around because the other option obviously is to run it in a

simulator but then you're back to the lower turnaround and this makes use of SwiftUI's

previews. Yes, I've not seen people use or reviews the interactive element of SwiftUI

previews like this before. So smart little idea. Oh and one other thing I wanted to mention,

I saw this in the readme further down. So there is obviously in order to use this you

need to import the package wherever you defined your previews, right?

You need to import preview_resizable and then there's an additional modifier on your view

available .preview_resizable and when you call that it makes your preview resizable.

But there's a little trick to avoid having to import preview_resizable everywhere and that is

if you embed somewhere within your module,

there's an underscore exported attribute for import.

And what that does is it pulls in all the public API

of a package that you're referencing

and re-exports its symbols

as if they were declared in your module.

And that then makes obviously everything available,

which means you don't have to import it again

in your module, right?

Because everything in your module

is available to your source code

without additional imports, right?

And that was actually the first time I sat down

and thought about how that,

what that underscore exported actually means.

I'd seen this a couple of times before,

but I never actually realized what it does.

And I found that quite interesting.

That it's sort of this, this is the first time

I've seen this being sort of advertised

as a useful little thing you might do.

There's a good tip there to put it in if debug guards,

so you don't compile this into your actual product,

because then you would obviously import all those symbols there,

which is probably not a huge deal, but something you would want to avoid.

So, yeah, there you go.

Preview of Resizable by Juan Duarte.

Great.

Well, that's all the packages I think we have for today.

So, should we wrap it up there?

Let's wrap it up.

Thanks for listening.

And thanks again, just to echo back to both our corporate sponsors,

stream and emerge and for everybody who supports us on GitHub. It really does make all the difference.

So thank you so much. And we will be back in a couple of weeks.

Yeah. See you in two weeks. Bye-bye.