Swift Package Indexing

I think in terms of news, what would be great to kick off with is Swift Server.

So that's the conference that you went to, was it, has it been two weeks now?

Yes, it's been almost two weeks. We're recording on Wednesday, so it's been a week and a half at the moment.

And yes, I did, I headed down to London for the Swift on the Server conference,

which was the first time I've actually been to a Swift on the Server event.

I must admit I had a great time. It was a

really good conference. The venue was

incredible. It was in the Science Museum

in London and we had private use of the

flight gallery, which is where they have

all sorts of airplanes hung from the

ceiling and there was a Harrier jump jet

in there and there was a cross-section of

a 747, which was amazing. And so we had

that area for our lunch breaks and coffee

and tea and that kind of stuff. And then

for the actual conference we had the

IMAX theater, which I've never presented

on an IMAX screen before, so that was

quite an experience. Was it 3D? It wasn't

3D, and I did notice that they, because

I was actually thinking about this before the

talks, is that IMAX screen is so big that

that you can't really see the edges of the screen,

like intentionally.

You're supposed to get this immersive experience

of not being able to see the edges.

And so I was hoping that they wouldn't put the slides

full screen on the iMacs,

because you wouldn't be able to see all the slides,

but they were centered, but they were still enormous.

It was the biggest screen I've ever presented on for sure.

And that whole conference was great.

it was really good to hear various different bits of Swift.

I've been to a lot of Swift conferences,

but mainly they talk about iOS development,

Mac OS development, and it was nice to be at an event

that was talking about server-side Swift

that was focused on that.

- Yeah.

- A couple of talks that I wanted to kind of highlight,

really, I was really impressed with Andrew Barber's talk

on globally distributed server-side Swift.

And he was talking about his Swift cloud product

and running Swift code on an edge network basically.

So not on a server that you control,

just on a kind of managed set of,

I guess it's called serverless, isn't it?

That's what they call it, right?

- Yeah, like cloud functions.

- Yes, cloud functions or something like that.

- Terminology is killing me with that stuff, but yeah.

There's so much of it right here.

And my first instinct with that talk

was that it was very interesting,

but that it wasn't gonna be useful for Swift Package Index.

And then within three or four days of me getting back,

we're using it.

- Little did you know at the time, yes.

- Exactly, yes.

So I believe you're gonna talk a little bit

about that later, Sven,

because that's what you've been working on at the moment.

But yeah, that was a talk that had instant impact,

which was great.

I also really enjoyed Matthias Pepari's talk.

He's from Canonical, who are the people behind Ubuntu.

And he was talking about distributing Swift

or making Swift more easily distributable.

At the moment, there are the Docker images

that Apple produce, but if you want to put Swift

onto a Linux machine, the process for that is not as simple as apt-install-swift, which

I think it should be.

And Matthias thought it should be as well.

And so he was giving a talk about that, but also offering his help to get Swift to be

as easy to install as apt-install-swift-57 or whatever.

And that again was just, there was a really good community feel at the conference and

to have someone from Canonical come forward and say, "We would really love to help Swift

become a wonderful language on Linux as well," was inspiring.

And there were lots of great talks throughout the day.

Those are the two that kind of stood out for me.

But it was also nice to see lots of Apple representation there at the conference.

So there was, obviously, the sponsorship from Apple was quite unusual for this conference.

Apple stepped up and sponsored the conference, but also they attended the conference, which

is, if anything, even more important.

So they had several speakers at the conference, and also they had lots of representation there

in the audience, talking to people.

It was great to see.

I thought it was a whole, the whole conference was really good.

Well, and the big announcement, right? With the foundation open sourcing and splitting up into packages was announced at the conference, wasn't it?

Yes, that was Tony Parker who actually kicked off the conference with an announcement that Swift was going to be re-engineered as an open source Swift package.

which of course is an enormous announcement,

fantastic for the Swift language

and a great step forward for Swift Analytics especially.

Or should I say Swift on other platforms.

Yeah, I haven't actually encountered that personally,

the struggle with foundation,

but it does pop up often when people are doing server-side Swift.

I guess we don't have as much of a problem

because size isn't really an issue,

but especially with Wasm and stuff,

foundation can be quite big to deploy.

And we're not doing, I think the biggest problem

is like foundation stuff with formatters

and things like that, which aren't all available

on Linux as they are on the Mac OS.

That's the only thing I remember

where we had trouble with foundation being different

on Mac OS where we typically develop

versus Linux where we deploy.

We had a couple of issues there

where we're trying to do a string formatter and it wasn't available.

But yeah, that's great to hear.

To see that move into open source,

also being split up into smaller packages so you can pick and choose.

And I think it's also a huge implication for uptake in Swift within Apple,

dogfooding, having more libraries being written in Swift,

lower level stuff being now possible to be written in Swift.

Sounded really great.

I think it was a very positive conference and I liked, somebody posted one of my slides from when I was talking

and they said this was my favorite slide from the conference and it was a slide that was in my slide deck that just said

"The future is bright" and I obviously I agree with that because I said it but I do think that the future is very bright for ServiceSide Swift.

Yeah, and it was actually a really neat coincidence because as you were at the conference, I had started working on an improvement to our doc hosting system.

So what we do is we upload docs to S3 and we were having some issues because doc sets can be quite large.

And one way of fixing that, I was considering to use a Lambda function or like a Cloud function,

it's not necessarily AWS specific, but something where we can send a zip file which then unzips it and uploads it to S3 on its own time.

The issue we were facing that we are uploading 80,000 files, a gigabyte of data spread across 80,000 files,

and we were having some trouble with the number of files being uploaded within the time window we have available for our builders.

So our idea was to zip it all up, ship it somewhere and have that something deal with the intricacies of uploading that to S3 and the retries per file and all that sort of stuff.

And that's a nice thing to do in sort of a cloud function, right?

If that works, it's much nicer than having to deploy a machine that runs all the time when we're only doing this for like 250 packages at the moment.

Right.

And so I looked at AWS Lambda for that and there is the Swift AWS Lambda runtime of the package by Apple, which is really nice.

you can get started very easily to build a Lambda, run it locally even, play around with it.

Then comes the time, the moment of truth, when you need to deploy it.

When it hits you, you look at AWS and think, "God, there's so many things to configure.

How do I even start?" And there's a very nice blog post by Fabian Fett that describes it and

and a few others, but the description is quite lengthy.

And I thought, all right, well, let me at least look around

if there are other ways to maybe do this,

'cause I recall seeing some Cloud Function kind of thing

that wasn't AWS that seemed promising

in having a much easier way of deploying,

and that was Swift Cloud by Andrew Barber.

And that's also in the index, so I looked it up,

Swift Cloud on Swift Package Index,

And I just love when I develop stuff and actually use the index to define things.

It's always good to use your own software, right?

Yeah, absolutely.

Looked it up, pulled it down, looked at the docs, very nice.

You just create a package, write your stuff, and then there's a super simple deploy step via Swift Cloud, its web interface.

You effectively just push your repository, and when it's connected to Swift Cloud,

it looks at you define what branch you want to, or if you want to auto deploy and when you've set

it like that any push gets deployed and it's available immediately and it runs, it runs your

cloud function and I found that amazing like within five minutes I had it deployed in the cloud in a

publicly available URL that I could use curl with and interact with and that was just amazing

the experience.

And I would have loved to use it but there were a couple of problems that sort of prevented

it and we had a chat subsequently with Andrew and he recommended that for the time for what

we are actually trying to do especially because we're talking to S3.

Swift cloud isn't the perfect tool at the moment because then we also pay all the traffic

into S3 when we're actually, if we upload our zip file to a Lambda, we avoid all that

overhead of actually talking externally into S3s.

Yeah, because it's all like the Lambda and the S3, they're all running within the same

local network effectively.

And so we don't pay any traffic outside that.

So all we would have to do at that point is upload a zip file to AWS and have AWS pick

up that zip file, unzip it onto S3 and that's a relatively simple task in terms of AWS functionality.

And the other interesting thing is that something that's so seamless that it's very easy to

forget about because what you're actually doing, you're not compiling a Swift executable

on ARM or x86 with the Swift compiler, normal Swift compiler 2 chain because what you're

actually doing in Swift cloud is using the Swift WASM tool chain to compile a WASM, I

don't know what you call it, is it an executable that then gets deployed into a WASM runtime?

I'm a bit hazy on how that actually works.

Me too.

But my understanding is this is sort of a, I think you can think of it as a VM that can

execute these WASM binaries, which are very efficient. I mean, it's not like JavaScript

that gets executed on the fly and sort of, what you call it?

Just in time compiles?

Hotspot compiled. It's an actual executable that's compiled ahead of time, in a sense.

So it is more efficient than that, but it's also not a normal executable that you could,

you know the same executable you would run on your ARM Mac or your x86 Mac and then would

just ship and have run in a VM in you know an AWS Lambda or something like that.

And the reason why that's important is and that's an issue I ran into, not every package

you might pull in as a dependency would necessarily compile in SwiftWasm.

So for instance, I was trying to compile SOTO in order to interact with S3 and that unfortunately

failed because a dependency that SOTO is pulling in, don't quite recall which one it was, didn't

actually compile on WASM.

I think it was even some C code that didn't compile.

There was other C code that it does compile, which is kind of amazing if you think about

it.

But this particular one, it didn't.

So there's maybe an argument to be made that we have a need for an additional platform

in the index to show what packages are/wasn't compatible.

But it's really interesting how much you can abstract that away and not even think about

it until the moment, you know, the moment of truth when it all bubbles up and the leaky

the abstraction sort of fails or the abstraction leaks and you see you get a

compile error that you're not expecting because your platform isn't quite the

one you thought you were running against.

I think there's an interesting conversation to be had around WASM compatibility because you're right that it would be

really useful to be able to, in this very specific situation, to see which

packages were compatible with WASM. But I think there's a little way to

to go before we should actually add that to the index in terms of clarification

and adoption of WASM itself. Because, so a lot of people, and Andrew was talking

about this in his talk, a lot of people think of WASM as a browser technology. So

I'm gonna run some Swift in my Safari or my Chrome and I'm gonna be

able to write Swift to modify the HTML DOM. And of course that's not what we're

talking about here. We're talking about running WASM as a server side through

still through a JavaScript interpreter,

but as a server-side process.

And really what you're talking about there

with compatibility is compatibility with that situation.

And I think if we stuck anything to do with Wasm

on the package of Bexite at the moment,

people would assume that was a browser-based Wasm,

which I don't believe is.

I think we would need a separate compatibility test

for that as I understand it.

And so I have a feeling that this is going to need

a little bit more time to propagate into the community.

And if this takes off, then absolutely we should do that.

But we're going to have to be very careful how we actually

represent that compatibility on the matrix.

Yeah, I think the target to test is the Wasm toolchain,

because that's the thing that everyone would use to actually

compile the Swift package with.

And obviously, there also, you have to look at versioning,

because a 5.8 Wasm Swift toolchain

might have different behavior than SWIFT 5.9.

But I think in that sense it's very similar to all the other flavors we're testing.

But you're right, I mean it's just very new and I guess it's also not a very common thing

that people would be looking for.

So the real estate on that page is pretty precious and we don't have that many columns

available to us.

We have to sort of be a bit careful how many things we show there.

Yeah, I've had some thoughts around that recently actually with how we represent that data and

as we get more platforms, because again, something else that came up at the conference was Windows

compatibility, which I think if we're going to tackle another platform, Windows would

probably be the next one we'd tackle.

And we're already getting quite tight for space in that area.

But also, the box for iOS is the same size as the box for Windows or WASM, which is nice

and equitable, but it doesn't represent the current reality.

And so I think we need to maybe rethink that area of the page a little bit, because also

the area of the page, even just for compatibility, takes up a large amount of space.

there's a lot of quite complex information to represent in that area. So

it's a tricky design problem but we'll maybe have a think about that

as we go forward. Yeah I wonder if there's a some rearranging that we

could do because I think over time our Swift version split is becoming less

and less important. I think there'll be an upcoming big one when it's

swift 6, but I almost wonder if it isn't at some point going to be 5.x and 6 and it's

effectively a swift version 2 column thing that we display at least on that page maybe

with a bit more detail in a click through where if there's even a need to split out

5x further, it's probably not worth it on that initial page. But at least, I mean, when

I look at stuff, the 5x are really not that important anymore. I haven't seen a package

in a long time where that sort of compatibility made any difference in my decision.

Me too, yeah. I think 5.6 was a big one really. I think 5.6 introduced a few things that people

started using straight away and so I quite often see no compatibility with 5.5 and 5.4,

but 5.6 and above is almost always. I very rarely see a difference between 5.6 and 5.7.

Yeah, might actually be an interesting thing to query because we can and we have in the

the past checked what packages have you know steps in there.

Yes.

Package would be compatible with 5.6 but not 7.

That sort of stuff.

So yeah and otherwise what was really nice with the, so that was actually my first experience

working with AWS Lambdas or any sort of cloud functions and I was quite impressed with the

quickness with which you can trigger AWS Lambdas.

I mean, you shouldn't be surprised because it's in the marketing, but when you actually

go into the AWS Lambda console and click on test, it just immediately executes that thing.

And that's quite astonishing because you get billed for like 300 milliseconds of compute

for that single function call.

And that's kind of remarkable if you think about that, the whole mechanism.

It is remarkable and I think

more remarkable is that what

you're saying is that you read some

marketing and it was true. Well I'd say I

didn't actively read it, I just you know

subliminally infiltrated my brain

I guess. That's how well that works, yeah.

So yes, in the last couple of weeks have

been, for you at least, a lot of cloud stuff.

For me, I have been investigating a problem that we've had for a little while without

Google results, and I've made some progress with it, which is good.

So we have a situation where we have a sitemap on the website which tells Google...

So a sitemap basically is an XML file that has a list of URLs in them, and against each

URL you have a frequency with which you would like Google to check for changes

on that page. And a sitemap is really important for a site like Swift package

index because there is no one page on our site that links to all packages

because most of what you do is through search. We need to tell Google what our

full set of package pages is because it's not going to find them just by

browsing, which is what it normally does. So normally it finds your site, it

follows every link on every page, and effectively that's what it considers

the entire surface area of your site. A side map, of course, is a list of URLs

where you can say, if you didn't find it, here's all the URLs we would like you

to start at. And what we do is we give Google all of the package page URLs so

that it knows about every package, but then we let it explore from there. So

So from there it can click on the release information

and it can click on the build information,

that kind of thing, and it can explore from there.

And it has been successfully doing that so far.

The problem we have is that it stopped doing that

with documentation, and we're getting very inconsistent

Google coverage on our documentation.

So some packages have their documentation completely indexed

and there's no problem at all.

packages, the documentation is not even in the Google index. It's decided not to

index that page whatsoever. And there are solutions to this where you can go into

the Google Search console and you can say please go and index this page now.

But I've resisted doing that because that's not a solution for the

future. We can't have anything that relies on me logging into a web

page and clicking a button. - There's no way for you to spend your Monday. - There's no way for

me to spend my life. Yes, exactly. I can do less damage if I only have to do that, but

it's certainly, there are better uses of my time, I think. So, this is the problem. I

think what all I've done so far is describe the problem. I've figured out, I think, what

the problem, the underlying issue is, and it's all to do with our support for versioned

documentation. So, one thing that Google does not like is it does not like repeated information.

So if you took somebody's website and made a clone of it and hosted it on the web, hoping

that you would grab their Google search results, Google has lots of safeguards within it to

stop you doing that.

And effectively, what we're doing with our version documentation is exactly that.

We're taking a copy of a documentation site and re-hosting it and saying, "Look, Google,

here's another copy of this site.

love us now. And what it actually says is it says no we won't.

But doesn't it doesn't it realize that it's the same domain? I mean I would imagine that

would sort of short circuit that process, no?

It does but it's still a problem in that you're uploading two copies of this effectively.

I mean yes between versions there will be some differences in documentation but also

potentially no differences in documentation. So it does see this as a problem and I've

I've confirmed that you can, in the Google Search console, you can dig into why it's

not indexing.

And it's not as simple as just reading the message.

Like, there was a little bit more to the investigation than that, but I think this is the problem.

And what it wants is it wants a canonical...so in the HTML, you can put a meta tag in the

head and you can say this is duplicate but it's duplicate of this document and

this document is the canonical version. And that's what we need to do

to fix it. So what we'll do is on the as we render the documentation pages we can

insert into the and we already do this for our style sheet and that kind of

thing. We can insert into that head section of each page a new meta tag that says the

latest, the canonical version of this documentation is our latest stable version of the documentation.

And I haven't yet implemented that, but I'm pretty sure that that will be the solution

to this problem.

Yeah, nice. And the doc sets that actually did show up, was that perhaps because they

were referenced in the packages readme or, you know, like externally too?

No, so it's a little more, and this is part of what was so confusing about this problem

is it is inconsistent. And what good, like, when you have the entire internet to index,

Everything you do is, you do your best with it, but nothing is perfect.

And so what Google does is sometimes it does index this stuff and sometimes it doesn't.

I think it's partly because we've got so much duplicate stuff that at some point it just,

it said, "Hold on a minute, there's a whole load of duplicates in here.

I'm not going to bother indexing anymore."

And so you end up with this situation where maybe the first things that it indexed were

okay, but then over time it decided not to trust us quite as much.

And that's also why we need to fix it.

That Google robot is surprisingly human.

I mean, if you think about it, I've spent a bit of time over the last couple of weeks

thinking about Google, and that is such an old bit of code now, I'm sure.

It gets constant, constant iteration.

But for such an important job, that Google bot that crawls the web, I think there probably

are some fascinating edge cases inside BancoBase.

It's also completely, I'm sure nobody is able to understand the entirety of that bot.

Oh yeah, that must be remarkable.

Just to imagine the scope of that thing.

Yeah.

And also, what's always fascinated me about Google is the storage of all of that information

so that you can, you know, if you imagine the sheer quantity of data that that search

engine is indexing and it brings back results in 0.1 seconds, 0.01 seconds, it's remarkable

how that piece of software works.

Yeah, that's remarkable and scary.

You know, for anything you do yourself, you think like, "God..."

There are many things that Google does that I'm not a big fan of, but the underlying search

engine technology I have nothing but absolute respect for.

Shall we do some package recommendations?

Yeah, let's do it. We're already half an hour in, so we probably should.

We are, we've talked a lot today, yeah. I will kick us off this week with a package called RichTextKit by Daniel Seide.

And this is a rich text editor that works with both UIKit, AppKit, and SwiftUI.

And while I haven't tried it, it looks kind of interesting.

So the most impressive thing about it is that this is a cross platform.

And again, we're using the definition of cross platform that includes iOS and MacOS.

This is a cross platform implementation of a rich text editor.

So if you're building an application for both, with SwiftUI, for both Mac OS and iOS, you

can use this package.

And if I just click through to the documentation here, it's actually come from a commercial

product.

So there's a product called Aribi Writer, which it says on the documentation is out

soon.

If you actually go through to the website, I believe it is already out.

So this is an application with spell checking, text to speech, and a smart keyboard is how

they describe it.

And this package has been extracted from that.

So I always think that if a package has come through that has made it into a commercial

application where the purpose of the application is to be that thing, I think that's got to

be worth checking out.

Yeah, definitely.

That tells you a lot. It's going to be, because it's so central, it's going to be maintained

and going to have a bright future ahead of it.

And again, great documentation. The documentation is not hosted on the package in Next, but

it is DocC documentation hosted on GitHub pages. And it looks great. I think if you're

in the market for a rich text editor, you should at least certainly check it out.

Yeah, in particular because my understanding is that SwiftUI probably needs something like this right now.

I think the built-in versions aren't capable enough to cover lots of slightly extended use cases.

You pretty quickly run into the issues where you need to wrap something and if this does it for you, that's probably really helpful.

And also I think once you get into wrapping, then you start to progress into a single platform

wrapper rather than a cross-platform wrapper.

And I think what they've done there is think about this, because I'm guessing their application

is cross-platform.

So I think they've had to consider that from every aspect.

So I think it's the kind of thing that, because it's in a product, it will get regular maintenance.

And if you can leverage that to save yourself some time, I think that's great.

And it's also worth giving that company a bit of credit for taking what is at the core

of their commercial application and open sourcing it.

That's always nice to see.

Yeah, very nice.

Right, I've got actually a set of packages that I wanted to list, and that's born out

of my work on that documentation uploader. What I needed there to work with that is something

to zip and unzip and I didn't want to shell out to the command line in particular. It's

always kind of hacky plus in the Lambda that's not an option and I wanted to use it on both

ends. So I was looking around for zip and unzip and as I said earlier it's just great

when you can use the index. I'm always happy when I can use the index for stuff. So that

was an opportunity plug zip in also platform called on Linux. So for people

don't know you can actually filter in our search on a platform. So to make to

select packages that support that platform and I knew that I needed Linux

support. It's probably just worth focusing in on that for a second because

that's potentially something that people haven't done with the package index is

once you search for something you can then and there is a little bit of help

underneath the search field after you've searched.

But you can just say, so for example,

I would imagine your query for this was

zip space platform colon Linux.

And that will filter search results

that contain that keyword either in a tag

or in a, sorry, in a keyword or in the description

or in the package name.

And then filter it by confirmed platform compatibility

with Linux.

- Exactly.

Yeah and that turned up a number of results and good results.

So for instance I zeroed in on three at the start.

That's Zip by Roy Marlestein, Zip Foundation by Thomas Zirkling and SW Compression by Timothee

Zolomko.

And yeah, these were amongst the top hits.

And then I clicked through, just describing the mechanism a bit, how I picked and how

I chose the packages.

And things I looked for was, you know, how long has it been around?

And these are all, these have all been around for a long time, seven years, five years,

six years.

All active fairly recently, 10 months ago to even just hours ago.

Releases also within that time span.

So already I had three packages that were very promising.

The first two have more than 30 contributors, even the last one, SW Compression, a bit fewer,

that's just four contributors, but still around for six years.

And then what I did is I tried them out in a playground just to get a feel for the API

and I could even plug in my zip file and unzip it in the playground to see how that would

go, what the options are on the, you know, if I need any, I don't need passwords and

stuff.

But it's a sort of thing that's really nice to do with just the tools that we have available

to play around and without having to set up a package, import it and do all that.

I could play around with the API and just choose.

And then I picked, I ended up picking Zip by Roy Marmelstein.

And the main reason was it's the one that can be built without any dependencies.

Now the others don't have package dependencies per se, but they do have an OS level dependency

on Zlib.

So it needs to be installed on the OS side.

So on Linux you need to have the development libset dev installed and the zip package avoids

that by shipping the C sources for zip within the package and just build it. And that's really nice

because then I don't need to worry about the lambda image to have that installed. It's just

a nicer process for my use case. But yeah, it was a really nice experience to do all that,

play around and have it ready for use. I love that story because it shows real practical use

of the Swift Package Index.

And the fact that you didn't just take the top package, obviously, you had a look at

several prominent packages that were highlighted by the index and actually analyzed using the

features that we've built, like how well-maintained is it?

How long has it been in development?

And you also mentioned the contributors, which we talked about last episode.

And I also have been really appreciating having the author names right there.

But yeah, I thought it was such a great story of just a real practical use of using the

software that we've built.

And I'm happy that we have a zip package that we're happy with as a result of it.

Just think of the amount of time that saved us.

Yeah, yeah, definitely.

I don't think writing is an algorithm, is anything you want to be doing.

Great. My next package recommendation is a very catchily titled DSF Quick Action Bath

by Darren Ford. So this is, well, a little bit of background first. I think I personally

I'm a big fan of software that has great keyboard support.

I am a big fan of, at the moment,

and for the last couple of years,

my preferred keyboard navigation tool has been Raycast

for launching applications and launching shortcuts

and that kind of stuff.

And what Raycast does is it brings up a window

in the center of the screen where you can trigger that

just like you can with Spotlight Search

and just type something in.

But I'm a big fan of that whole process of just bringing up some kind of keyboard input,

spotlight type keyboard input, and being able to just type a couple of keystrokes to get something done.

In fact, there was an application called Details Pro, which is an iPad application for designing SwiftUI user interfaces.

It's not code-based, it's more like a design tool

where you could build up HDACs or VSTACs

and put buttons in and put labels in

and that kind of stuff.

And recently, they added a keyboard navigation type

interface like this, where it puts a bar

in the center of the screen.

You type something in, so for example,

in that application, and I know I'm going down

a rabbit hole here, but bear with me a second.

So let's say in this application you have a label

and you want to take that label and wrap it in a HDAC

because you're about to put something next to it.

You can bring up this keyboard navigation,

just type wrap, and it will say wrap in HDAC,

wrap in VSTAC, and it's a really nice way,

quick way of navigating around the application.

Again, things like Raycast or Alfred,

or even back in the day, Quicksilver,

have been productivity tools

that I've been a great fan of for many, many years.

And of course, Spotlight, you know,

Apple also have this within both iOS and Mac OS as a spotlight.

Back to the plot,

Darren Ford's package is an easy way to bring that kind of interface

into a Mac OS application.

So it is Mac OS specific.

And you could very quickly build up something that has a text field where

you can enter some text and then have a dropdown list of things that you provide

to do actions within your application.

And the main reason I want to recommend this

is because I love this type of interface

and anything that makes it easy for people

to implement this kind of interface,

I'm going to be a big fan of.

- Yeah, yeah, really nice, really nice.

I also use these extensively.

I've actually, I've started mapping Command + P

to those kind of command bars because I never print.

So Xcode's quick open is command P

because it's sort of a similar interface.

So then I know in every app

that has that sort of command interface,

I just hit command P out of habit.

- Oh, that's interesting.

Yeah, I think this is great

and anything that encourages people

to think more about keyboard navigation

in macOS applications is a good thing.

It has AppKit and SwiftUI support, but only on macOS.

also has great readme, good documentation, it's great.

- Nice.

Right, my second package is one that we

probably mentioned before, I think you recently

wrote about it on IOSF Weekly as well, and that's Lottie.

But apart from it being a really nice package

to create animations, there was a 4.0 release recently,

like two weeks ago, I think it was just after we recorded our last episode.

And the thing that caught my eye in that was,

they moved, they changed how they,

how they, where they do their rendering.

So in versions prior to 4.0,

they were using the CPU to run their rendering engine.

And they've moved this to use core animation now.

And they've been actually doing this under the hood.

So starting from version 3.4, they had an opt-in flag where you could switch your rendering over from the CPU-based rendering over to the graphics card-based rendering, the core animation-based rendering.

So they actually shipped this quite a while ago, but had this behind a feature flag and tested it.

and the nice thing is this is completely API backwards compatible so you actually need

to do nothing other than upgrading to 4.0 and the effect is quite remarkable.

So there's a blog post and we'll have a link in the show notes that shows an example where

the CPU utilization drops from around 15% in that example to zero, like literally zero,

you see no effect of the animation running in instruments.

I thought that really nice, where just upgrading a package will give you that sort of benefit.

And that's, 15% can mean, you know, other stuff that you're doing is blocking your, you know,

causing dropped frames and stuff, because, you know, 15% just might be a bit, you know,

you might not have those 15% available.

Yeah, it's a really significant performance increase.

And to drop it so low is remarkable work.

Yeah, yeah, really nice.

And in particular that is, there's really just no effort required.

Just, you know, upgrade and that's it. Fantastic. I love that.

So you're right, I did write about this on iOS Dev Weekly,

and one of the points that I made there again was about effort,

not in effort in upgrading between this,

but to be able to take a tool like Adobe After Effects,

which is a really comprehensive animation tool,

and also industry standard animation tool.

So you've got an enormous pool of people

who are skilled with creating animations in After Effects.

And then to be able to have,

and I know there are some limitations,

you know, it can't do everything

that After Effects can do, of course.

But to be able to take vector animations,

export them to a common format,

and then have those able to be used in iOS apps,

on the web, in Android apps,

I love the idea of this because these little animations can be really effective in your

applications user interface and to create them purely through code, of course it's possible.

Of course it is.

But you suddenly have a person who is not skilled with creating animations having to

create animations and to allow people who have the skills with animations to be able

to use their tool and then use that within your application.

I think it's, I love everything about this package.

- Yeah, that's a great point.

It just makes it so much more accessible

to create these things and spread it out, right?

It doesn't have to funnel through,

you know, that one person who does the coding necessarily.

- Yeah, and even if you are doing the coding

and you can do an animation,

it's going to be more difficult to express

what you were intending with just a pure animation.

Now, animations for moving things off the screen,

moving things on the screen, you know, hiding a piece of UI

or bringing it back with an opacity fade

or something like that, sure, write that in code.

But as soon as you get into anything

that's actually animating multiple things

or, you know, things interacting with each other,

I think there's a clear advantage

to using a tool like this.

- Or experimentation, right?

You're not going to-- - Exactly.

- You know, to quickly try a few things.

I can't see that being very efficient if you code around,

unless you randomize it.

- It takes a long time to write good animations.

Okay, my last one is a quick one,

and it's by Wilhelm Hox,

and it's called Array Builder Module.

It uses a result builder,

in fact, I can summarize this

in literally one sentence.

It uses a result builder to build arrays.

So you can have a result builder style syntax

like you have with SwiftUI,

and every element that goes into that result builder

ends up in an array.

And there's not a lot to say about this package,

but I thought it was worth mentioning.

- Yeah, it's interesting.

I saw that.

I think it has a compelling use case

because you might be tempted to think,

come on, let's maybe not take result builders too far.

But in certain scenarios,

it makes it easier to declare an array

where you include elements equiditionally

and you don't want to build up a temporary array that you then modify in subsequent steps.

So that's actually a nice use case.

You're right and I think that's the key thing.

And I think if there's anything to criticize about this package is that in the readme file,

some of the examples that are in the readme file stretch what you should be doing with

result codes a little bit.

And I understand how that happened because you want to show off what this can do, but

you end up with is fairly obscure, but I think there are good uses for this. And as you say,

the conditional nature of putting elements in an array, I think, is the main use of this.

Nice. Right, I'll be quick on my third and last one as well. This is not actually a new

package it's a fork of Swift backtrace and I wanted to highlight that and it's by Nathan

S. I could not find Nathan's last name it's not fully spelled out anywhere that I could

find. So as I said it's a fork of Swift backtrace. Swift backtrace is a package that you can

include so this is very server side Swift specific that you can include to make sure

that if your program crashes you get a proper backtrace in your logs that you can then inspect.

And the nice addition here is it tidies up the stacktrace you get out so it adds

colors and splits off the path info it makes it just nicer to read. A simple addition that I

hope might get upstreamed into the actual Swift backtrace package, but even that package isn't

isn't going to be around forever because there's actually an effort to be made,

as an effort being made to bring Backtrace

support into the actual toolchain. And I hope this would also make it into

that package, but I wanted to mention it because until that actually

happens, Swift Backtrace is still a package that's being used in

server-side Swift projects and that might be one you might be interested in using

to make those a little nicer. - That's great. - So yeah, there you go.

Swift Bacterias, a fork by Nathan S.

Wonderful.

Well, let's wrap it up there, shall we?

I think the schedule over, because obviously we're heading into the holiday period at the

moment, but I think the fact that we record on a bi-weekly schedule means that our next

one would be released on the 5th of January, and I believe we should be okay to do that.

So we're actually not going to take a holiday break this year.

Exactly, yep.

I guess see you all in the new year.

Yeah.