Subscribe
Share
Share
Embed
News about Swift on Server, AWS Lambda arm64 performance, and package highlights from the last couple of weeks of the Swift Package Index.
Show Notes
News
Packages
- swift-markdown-ui by Guille Gonzalez
- KVKCalendar by Sergei Kviatkovskii
- Draftsman by Nayanda Haberty
- tart by Cirrus Labs
- SunKit by Sunlitt
- PreviewResizable by Joan Duat
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.
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.