Subscribe
Share
Share
Embed
All the updates, news, recommendations, and chat from the last couple of weeks of the Swift Package Index.
Show Notes
News
Packages
Creators & Guests
What is Swift Package Indexing?
Join Dave and Sven, the creators of the Swift Package Index open-source project, as they talk about progress on the project and discuss a new set of community package recommendations every episode.
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.