Swift Package Indexing

There's one thing we should definitely talk about, and that's that we passed 300 packages adopting documentation this last week.

Oh, that's great news. I was meaning to take a look at that the other day, actually, but you beat me to it.

Yeah, I mean, I do have this little spreadsheet where I track over time the number of packages that we have and also the number of packages adopting documentation.

So we launched this almost nine months ago and we have now five and a half percent of all packages

opting into documentation hosting.

And now these are opting in, not ones that actually opt in via pointing to their own documentation.

So there's probably a few more that have documentation links on the site,

but that, you know, the docs, we aren't hosting the docs for them.

But I kind of thought back when we launched this,

I mean, we never talked about any goals or ideas we might have with respect to how many

we'd expect over a certain amount of time.

But I thought at the time, because I was, I had been tracking how many packages have

an SPI.yaml file in their project for quite a while now.

And that had been around 5%, I think, at the time we launched the documentation hosting.

And I thought it would be really amazing if we'd managed to get 5% on board within a year

or something.

And I think that's probably way more than to be expected.

So here we are, nine months and a bit.

I know actually that's eight months and a bit and it's five and a half percent.

I thought that's really great.

So adoption has been really great by authors.

The traffic is also great to see.

So this is not just the adoption.

People are using it.

So the traffic on the documentation pages is, I think, of the order of 10%, which is

significant.

And just in my own use, whenever I do backend stuff, because there's quite a few packages

that we're using that have documentation and host it with us, my way of looking up documentation

really is search for the package with my little Raycast shortcut that makes that really easy.

Go to the package page, click through to the documentation, and then that's how I browse

documentation for packages and I think that's a great sign that I actually want to use it

that way and for me, there's a couple of cases where I've opened pull requests for packages

that have their own documentation but didn't have a documentation link on our site so they

still host it themselves and I open the pull request to at least point the documentation

link to their site just to make it very easy and a common entry point in the documentation,

that's what I really like. I exactly know where to go and where to check whether there's

documentation and I think that's really great.

Yeah, no, I think it's remarkable that we've got that level of adoption.

To get 5% of packages just having documentation, it is a landmark, let alone for us to be the

host of 5%.

I think it's a real testament to the fact that people are actually using DocC.

And I think the more I use DocC, the more I like the tool.

It's a really nice documentation tool.

And I think that is proven out by the fact that people are really using it.

They're really adding documentation.

And then of course, for them to use us to host it is a cherry on the top.

But I think the DocC team deserve a lot of credit for what they've done.

Yeah, absolutely.

I think it's really easy to get started with documentation because it's interesting.

I think the difficult part in documentation is the hosting bit.

You know, we've sort of shipped this thing to take that pain away.

And once that's gone, it is really just a matter of, I mean, obviously

doing the legwork and adding the documentation to your

functions and methods and structs and classes and so on.

But also it's very easy to add like entry.

I think what's really important and key for documentation

is to have a little entry page that explains the package and

guides you to the symbols that are actually relevant, right?

A wall of symbols isn't really helpful as documentation.

Just a little markdown page that points to

getting started topics and you know these are the

the key entities that you need to know about

you know when you're using this when you're using this package.

I think that's really important and that's also very easy to do because

all it takes is create a markdown file, drop it in the folder structure and

And off you go.

And because it's so easy to do that part of it,

I think that really plays into Doxy's hands here

and in having so many packages

with documentation available.

- The one thing I'm a little surprised about

is how the word is spreading about this.

Because yes, we have a little note

on our add a package page that says,

once you've added your package,

don't forget we can build your documentation for you.

But apart from that,

we've not really talked about it very much.

And we've talked about it on the podcast,

But I don't see where the word is spreading,

and I'd be interested to know how the word is spreading.

I guess it must be in some level, word of mouth.

- Yeah.

- Because on a package page,

like if you add your package to the index,

if you look at that package page,

there's actually not much to tell you as a package author

that we would build your documentation.

You'd have to go and either go back to that

add a package page,

Or is it mentioned on the information for package maintainers?

I don't think it is actually.

We should probably do that.

- I thought we had a link.

I'm not sure though.

- Oh, we do.

Yes, we do.

- One thing I think we could do, perhaps should do,

is because I think the SPI.yaml file is discovered.

Well, not the yaml file,

but the badges and the build system are discovered

by just having the badges on your package page, right?

So because it exposes it to GitHub.

So if you browse a package on GitHub and you see the badge

and you're interested in the badge, that links back to us.

So we have sort of extending our service surface in a sense

because on GitHub we're also exposed via the platform

support and Swift version support links.

And I think that spreads.

I know in the past, when I saw a badge

that I'd never seen before, I was curious,

well, how did they get coverage on this?

And then obviously when you inspect the badge, you see,

oh, this is this service that's being used to populate the data

and create the badge.

And I think that's how people discover the badges.

I think what we could do is also have a documentation badge

that links, you know, recreates our dock button

on our package page to also be available as a click target

on a plain and simple GitHub page,

which would then obviously if you don't have it

and you just recognize it and see it,

would also lead you to investigate how that badge is created

or how it's being used.

- And that badge would link straight through

to the documentation for that package?

- I suppose it could, yeah.

- Yeah, yeah, that's a good idea.

The other thing that we could do is,

as one of our nightly tasks,

we could start looking at every package in the index

and you could actually start to figure out

whether they had documentation comments

and if they did, open a pull request with an SBI YAML.

(laughs)

- Yeah, it would be, or look at least for Doc C,

the Doc C pages, I think that'll be a very strong

signal as well, yeah.

Yeah, that's another, we could at least prompt authors

to ask if they're interested in having it hosted.

- Exactly, I wasn't really meaning it

as a completely serious suggestion,

but you know what we could actually do

is we could start potentially flagging somewhere, not doing anything with the repository, but

flagging somewhere that after a build, if there appear to be some compatible documentation,

we could start flagging that to ourselves somewhere to maybe see if that's something

worth pursuing.

Yeah.

Yeah.

That's interesting.

Yeah.

There was another little thing slightly related to documentation that I worked on last week

that I thought might be interesting to talk about,

and that is a doc archive size histogram.

So we've talked about our doc uploader

for quite a bit in the past.

This is not about the doc uploader itself,

it's about the issue that we were addressing with it,

and that's that doc archives vary in size

quite significantly, and we'd seen a handful of repositories

that had lots of documentation, both in megabyte size

and file count, but we had no real good idea how many there really are.

What's the distribution across all these 300 packages with documentation?

How many are there where it's really small and how many are there where it's 100 megabytes or more?

So we had this task in the back of our minds for quite a while now to actually log that

and report it back to the server.

And we'd done that, so we have collected the data, but it doesn't stop there.

you just then want to visualize that somehow,

create a histogram so you can see the distribution of sizes

and file counts across the different packages,

know how many are there in the various buckets.

And that was really interesting

because I've done a lot of graphing and reporting,

graphical reporting in the past.

And my go-to tool has always been Python, Matplotlib,

and then sometimes Report Lab to create PDF reports

out of various graphs.

but it's always been this tool, Matplotlib,

pretty much all the time to create graphs,

Jupyter notebooks, which is sort of like

a Python playgrounds kind of thing

where you can interactively create little Python snippets

and create a little program that then creates graphs

or whatever it is.

I mean, Jupyter supports all manner of things

that you can throw into a Python script.

But this time around, I thought,

well, let's, we're in Swift land.

let's use Swift because SwiftCharts has been introduced last year at WWDC

and I hadn't actually used it for anything.

So I thought, well, I'm just going to throw this into a little SwiftChart real quick.

And I found there's actually a histogram class or struct that comes with the package.

So it's very easy to just take data and throw it into this thing,

add it all wholesale and then have created a histogram.

just give it the bin count that you want and the range that you want it to graph.

And then you can draw that into a SwiftUI chart.

And then that obviously is very easy to add into a SwiftUI canvas.

So effectively what I did is I threw these two charts together,

both the megabyte size histogram and the file count histogram,

and threw that into a canvas.

And that was really easy to do.

I mean, I was done by the time I'd probably be done setting up my Python environment again,

because I hadn't used Python in quite a while and it's always a bit of a pain setting up

Python virtual environments and then Matplotlib you typically need to compile because it has

C modules and all that.

So if you're not set up for this, it can take a bit of time to actually get started.

So this was really smooth and really great.

It looked fantastic.

So the output was really good.

And then I thought, well, A, I should post about this.

So I posted about this in Macedon, showed a little graph,

and there was, it was really interesting.

And people asked, well, can you actually

create a PDF from this?

And then I looked around a bit,

and obviously on Paul Hudson's

Hacking with Swift page there is a snippet

that explains how you create a PDF from a SwiftUI view,

which was also very easy.

So I have a playground with a button

to export a PDF of that view.

And that is effectively the same thing you can do

in Jupiter, all in Swift, really high quality.

In fact, I think the PDF is unique

in the sense that it is resizable.

So this is a, it's not a rasterized PDF.

You can actually select the text and zoom in

and you, yeah, really high quality zoom.

There's no stairs or anti-aliasing or anything,

which I think is the case with Jupiter.

So I was really, really pleasantly surprised

with the outcome of this little experiment.

And I can really recommend, if you have something to chart,

a simple and quick thing, give Swift charts a go and a Swift Playground because that might

be all you need.

What's also really great about this is if you've done any sort of data processing in

Python, it's really nice on one hand that Python doesn't have strong typing that you

can just throw data at it.

But once you reach a certain level of complexity with your data, it's also very easy to get

confused about which slice of data should I be looking at?

Am I actually looking at this dictionary or am I looking at the nested dictionary in the

dictionary?

Because beyond the first level of nesting, you get hopelessly confused about where you

actually are.

Whereas in Swift, you can strongly type all these things.

So you know exactly what object you're looking at.

You can be sure that value you're plotting here is a certain type because you've made

that type yourself and you don't get confused when you look at the data.

I saw you talking about this and I think you also mentioned that it was maybe not faster,

but a similar amount of time that it took you to create these histograms as it would

have done in Python.

Oh yeah.

I mean, if someone is set up to do this in Python, I think the effort is pretty much

the same, you know, because you have a very simple data structure that you pipe into a

histogram.

And it's a really great use of a Swift Playground, actually.

Yeah.

I love that.

you see the data, I mean, it's effectively just like Jupyter. And that's what I love about Jupyter

as well, because you get this immediate feedback. There's no build run loop, really. I mean,

under the hood, it is, of course, but it's hidden away. And it's so immediate that you don't really

notice it. That makes it a really pleasant experience. And you can even more so I think

in Python, because in Python, the results, you sort of need to rerun the sheet, if I remember

correctly, but in SwiftUI the view actually sits off to the side and if you modify the page a bit,

the page layout, and that's very easy to do then and has a really nice feedback cycle

where you have the view to the side that shows you the page what it looks like and gives you

this really good control over what your result is and the output. And obviously more so than

Matplotlib in SwiftUI, you have the full power of SwiftUI at your disposal, right? You can

you can overlay this thing with anything because you can have a ZStack and then

put stuff on top of your graph, next to your graph, all your layout commands are available to you.

And I think that's amazing. That's a really great environment to work on this kind of thing.

And is it worth talking about the results that you found?

Yeah, maybe briefly.

Or the generation of them that was interesting.

Well, I think we didn't talk about the results all that much because

But luckily, I mean, what it showed is a very steep drop off.

So really, we don't need to be that concerned about size per se, because it's effectively

just three packages, well, two packages where one has two versions, like the default branch

and the tagged version has a very large doc set and another package which only has a default

branch version, I believe.

So it's really only three doc sets that are large or a bit too large to be honest.

And all the rest I think are below 100 megabytes, certainly below our 500 megabytes cutoff.

So there aren't any packages that we're currently tracking that are above our cutoff.

And we have special case the one, right, because it's Swift syntax to actually onboard it beyond

our normal cutoff.

So it has a special cutoff.

we're not dropping lots of packages due to that, which is good to know.

When are we getting Swiftcharts for the web? That's my question.

That's actually interesting because once you have PDF or a way to create PDF,

it's very easy to just create a PNG or whatever you want for the web, right?

Even an SVG, yeah.

Is there something to create SVG from SwiftUI?

Probably not directly, right? But maybe via PDF?

Might be an interesting little...

Potentially via PDF.

Yeah.

I don't think there would be anything directly for SwiftUI to SVG, but yes, maybe.

The next version of the site will be built entirely with SwiftUI.

So the only thing that I had for news this week is a little refactoring actually, but

it's not worth talking about it on the thing.

So whenever we add new pages to the site or new things to the site, there's always that

question of, does it need a bit more design?

Does it need a little bit more, like does it need any custom UI?

it fit in with the rest of the site.

And over time, we had a few little things that were all custom, that were all built

just in whatever, whatever mood I was in that day, wasn't a terrible mess, but we

had a couple of little things that were like that.

And at the end of the supporters page that we talked about on the last episode, I

noticed that again, I'd built one more little kind of box to click on, which would

take people out to our GitHub sponsors link.

And I thought, well, I wonder if there's a, there's a few of these across the site.

And so I did a little bit of refactoring on the design side of things and made

what I've called the panel button, which is a cross between a kind of panel of

information, and it also acts as a button in itself.

And we're now using those across the site in a few places, mainly on the

homepage and then once on the supporters page, and it's basically just a little

panel, it's not designed to be huge.

If you look on the homepage, the four panels that you see there, the podcast

link, the link to our supporters page and the two advertising sponsors links

that we have on the homepage there, they are now all power buttons.

And the reason I'm mentioning really is it's the kind of thing that now gives us

the ability to know that we have that design element that we can use potentially

elsewhere.

We don't have a formal design system.

The design side of things is really only me working on that.

And so I'm not dealing with teams of designers

who all need to be able to do something consistently,

but it is nice to occasionally come back and say,

what common elements are we doing common tasks with

and seeing if we can actually create some kind of standard

for that across the site.

And so that was a little enhancement that went live

since we last spoke about the supporters page.

- Right, I think that covers the news, doesn't it?

- It does.

Shall we do some packages?

Yeah, I can kick us off this week with a package called Yorkie.

And this may be a very UK centric reference, but the only Yorkie I knew

before now was a chocolate bar in the UK when I was a kid, it's

nothing to do with chocolate bars.

Instead, it is a, an SDK for building real time collaborative applications.

And the reason that this stood out to me is that a common conversation

between you and I and a common research topic from you and I has been for a

collaborative markdown editor.

And actually just to go off on a slight little tangent for a second, we have

actually found one recently that we have been using for a couple of little things.

And I quite like actually, it's called HackMD and that's, that's our current

best guess at it, but, but it's not perfect.

And so this Yorkie iOS SDK is for a tool called Yorkie and it's an open

source server that you can run yourself.

If you want to, you want to stand up a server yourself, you can run this Yorkie

server and it basically helps you create real-time collaborative editing.

I don't think it's specific on what the, the thing that is being edited is.

It is more of a mechanism to help you with that.

And I haven't looked into Yorkie itself more than that, but I did think, I didn't

I think it was maybe our next project idea to finally solve that markdown if it's a problem.

And maybe Yorkie is the way that we do it.

So the package got added to the package index this week and it stood out to me as something

interesting.

Nice.

Yeah, I've seen Simon, help me out, what's his last name?

Stuffring.

Stuffring, exactly.

He's currently porting Brunstone to the Mac.

So I think slowly but surely all the pieces are coming into play.

I also saw Joe Heck blog posting, blogging about CRDTs again.

So I think the stars are slowly coming into alignment that hopefully someone will put

it all together and create a really innovative and nice marketer, editor that allows you

to collaborate and work on documents across the web with comments and all that.

I'm not super happy with HackMD.

The main problem for me is that when you lose connection,

you can't even edit it locally.

But yeah, especially a native client would be really great.

So maybe this is the tool to go for.

Interesting, your key.

- A native client would be great,

but it has to support, table stakes for me is

that it has to support commenting and that kind of thing.

There's a lot of work in adding those kind of features

and a lot of collaborative editors don't go that far.

And so, yeah, I agree that HackMD has its limitations,

but it's certainly, it's the best I've used so far.

But there is, I think there is actually

a serious opportunity here for somebody

to build a tool like this.

I do not think this is a solved problem.

- No, I really hope so.

I mean, let this be, once everyone's done

with their Macedon clients, let's do this.

Right, so that's my first package.

Excellent. My first pick is called Potent Codables by, well, it's just Outfox, which

is a company. And this is a package to deal with, well, codables, encoding, decoding of

data. And obviously the big days of custom codable implementation is sort of gone since,

that are over since Codable shipped with Swift.

- Yeah, I had to check the date for a second there.

- When did Codable ship?

Was that Swift, just Swift 5?

I don't know, it's been, or Swift 4 even,

I don't remember, it's been in the language so long,

and it's the go-to way of really, you know,

dealing with data encoding and decoding.

But there are cases where you need something more,

and this is a package that gives you more.

So one example that immediately springs to mind

is something we had to do recently.

So we have two different JSON files.

I mean, different in the sense the content is different,

but the schema is the same.

So they have the same shape and we need to merge them together.

Now we know one top level key

and all the entities below that key,

we want to merge together.

But because we don't know the rest of the document structure,

we can't really write out the codable to read those in,

merge them and write them out again, right?

If we only define that one top-level key that we're interested in,

we'd be stripping out all the other data that's part of the thing.

So Codable doesn't really work here.

What we're using right now is the normal JSON serializable, I think it's called,

the foundation class that deals with JSON encoding and decoding just generically,

and not with any...

where you don't need to define the struct up front,

you can just load it in, look for your keys, and then merge it.

And this package does the same thing.

It also interfaces with Codable, so it's a bit of a mix of both.

And it also comes with support for both JSON, YAML, and other formats.

So if you have this particular mix of requirements,

this might be an interesting package for you, for instance,

if you need to write both JSON and YAML.

You could use just this package rather than, you know,

use the normal Foundation Codable and then, you know, YAML for YAML encoding.

And obviously it also supports a couple of other formats that might be interesting to you.

It also promises easier implementation of custom serialization formats, so if you have needs for that,

this might be interesting to you.

It does come with extensive docs, so that's always nice.

And it supports all platforms that we are testing for, so all of Apple's platforms as well as Linux.

So this looks like a really nice package if you have encoding, decoding needs that go a bit beyond

of what Foundation or Swift as a language provides.

And that's potent codables by Outfox.

- I think it's also a great confirmation

that the problem of passing data

between systems will never be solved.

- Yeah, and you know, the default format JSON,

which pretty much is the default, has its problems, right?

If you slot the most space saving of formats around,

so if that's your constraint,

this package has other options,

I think there are specifically binary formats that are specifically made to be a little

bit more compact.

Although I do feel we're in a pretty good state these days where JSON has become really

a standard for doing this kind of thing and everyone's kind of settled on it and it feels

like a relatively calm situation for data import and export between various systems,

whether it be manual or real time.

We do feel like we're in a reasonable position

at the moment.

- Yeah, I mean, I think Jason will get you a long, long way.

And then the beauty of Codable is

that you can just swap it out, right?

If it's a detail of how you serialize

your data structures mostly,

and allows you to just swap it out for something better

if you have special needs around size

and perhaps speed as well then.

- Great.

My second package is Typography Kit by Ross Butler.

And this is not a new package at all,

but it did just have a major new release three days ago.

So it's been in development actually for five years,

which is a long time for any package,

but it's a little bit like what we were talking about

with the design system for the package index, actually.

It allows you to create standard look and feel

across your application using custom fonts,

but also supporting dynamic type,

which is something that has become easier over the years,

but certainly five years ago,

I don't think it was even possible five years ago,

certainly this solved a big problem at the time.

And this week's release of it adds colors into the mix.

So you can still specify a custom font

and have it react to dynamic type changes

and look at a standard look across your application,

but you can now also add standard colors for text

and standard secondary primary and secondary colors for text

and fallback colors, things like that.

And I think that's a nice extension.

You know, it's quite easy when you create a package

to want to keep adding stuff to it.

But sometimes that can be the wrong choice,

but I think this looks like a really solid extension

of keeping it within what the original package

was intended to do, which is create a standard look

feel for your application. And typography

and colors definitely go hand in hand

and so I thought this was a great extension

of that. Really nice, yeah. And I see it has

support for SwiftUI as well, right? Which

is really nice. And UIKit. Yeah,

I mean, you know, five years that was

probably. Of course, five years there was

no SwiftUI.

My second pick is called, it's also about text, it's called Rich String Kit by Robbie Moyer.

And this is a decorative DSL for building rich text in Swift, as the description says.

And that's really nice, I mean the selling point really is, just if you look in the readme,

it gives you a NS attributed string definition,

you know, to create a short paragraph of text with certain styling,

you know, a font of a certain size, a bolded font element, a logo attachment.

And I'm trying to read through this Swift attributed string declaration of it,

and I find it really hard to pick out what the actual embellishments are.

There's a range that does something else strong.

So that's, that is emphasized.

If you read by comparison the TSL or Result Builder made attributed string,

you can just read it, you know, that you see a plain text part,

then there's a Swift label with an attachment,

a foreground color change and a bold system font being applied.

And that's a really nice use case for Result Builders making something

very easy and readable and extensible by extension.

because the declaration reads really well and emphasizes the parts that you're actually configuring.

So all the machinery of setting up the different data structures that you need are hidden away

and you can really focus in on the data that you're actually presenting.

Yeah, I think when we first got result builders,

everybody wanted to use a result builder for everything and suddenly everything was a result builder.

But there are some good, there are some really solid good use cases and this sounds like one of them.

Yeah, so that's Rich's string kit by Robbie Moyer.

Fantastic. So my final package for this week is that number kit, which is by Frederick Jack.

And this is a package that I think is one of those where it's the perfect use for a package,

because if there's one thing that I never want to do, it's write a formatter or a validator

for validating VAT.

It is one of those tasks that I am extremely happy that somebody else has picked up.

And that's what Frederick has done with this.

So I have in the past, and in fact, I do still use this on the iOS dev jobs website.

I have integrated the online VAT number checker.

There is the EU run a VAT number checking API service that you can use and you pass

of that number and it will not only check whether it's valid, it will check whether it's real,

which is a great service, but that obviously requires an online connection and all the rest

of it. What this does is it takes an enormous number of countries, in fact I think all of

the European countries, and has all of the rules for their VAT numbers. It's the kind of thing that

not everybody's going to need this package, but if you need it this is going to save you so much

time because one of the things that is difficult about this is just finding all

the different formats for these numbers. Yeah. Does it also check online? Does it

have the option to validate it like fully or what is that other scope? I

don't believe it does. I think this is purely a validation library and not an

actual check. Right. Interesting. So it's the kind of thing that this

this actually popped onto my radar a little a couple of weeks ago and I was

toying with whether to even mention it because it is so niche but it's the kind

I love packages like this because I never want to write that code.

Yeah.

So I want to give my thanks to Frederick for solving that problem.

Yeah, I think that's a perfect use case for dependency, right?

This is the stuff you just want to have someone else deal with.

But it's also, you just get all of the changes for free whenever there are updates to these

formats, which is fairly rare with VAT numbers, I think, but still.

Yeah.

Right. My third pick is called Swifty Creatives by Yuki Kuvashima.

So I'm just going to read the description. It's a bit hard to describe what this package does.

Creative coding framework for Swift. Built on Apple's metal. Inspired by processing.

Oh wow. Okay.

This probably doesn't tell you much, but if you look at the readme, it demos what it does.

and the description in general is a bit sparse,

but I find it really interesting just for the demos that it shows.

Think of the kind of package where you can define geometrical structures

and then animate them or create procedurally variations of them.

And this is sort of what the examples demonstrate.

The first one is lots of different cubes, rectangles arranged

and they're rotating, they're semi-translucent.

It looks really interesting.

You can imagine all sorts of use cases for this kind of thing,

whether it be an animated logo or a loading spinner or certain explorations.

Maybe you want to show disk size breakdowns with these boxes, that sort of stuff.

Graphing, there are some examples that show 3D bar graphs are probably the greatest

graphing tool in the world. The applications for those are really...

they're probably more for demonstration purposes than actual use, but it shows what the library can do

And there are various other examples on that page.

And it goes, you know, it's just rotating text,

showing a nice little tree.

It's a bit like Fractal where a tree structure

is being created.

I think these are called Lindenmayer systems.

And one interesting thing about this package is

it also has two example projects that it links to,

which in themselves are interesting.

The first one is about this tree that I just talked about,

this Lindenmayer system,

which is an app where you can configure

creation parameters, so the color or the, I guess the number of nodes, and you know, the branching, you control how many branches it creates.

And it gives you various, very different shapes of the tree that it creates.

Interesting tool just to look at, and I presume

I can imagine you're building that or playing with that, it's also quite interesting.

And the other example is called Stable Fluids, and this is a sort of

plane and I guess you can use touch input to poke the plane and the plane is effectively a fluid and then it

Sort of swooshes around and creates waves and stuff and it's it's really interesting what this package

Apparently allows you to do with this sort of stuff and it's based on metal

So I suppose it's quite performant. I think does its its name justice Swift creative

I can see someone who's good at this sort of stuff

to create really interesting visualizations.

- Well, and that's the thing with processing is that,

I mean, processing has been around for a long time now.

And I'm sure that when the people who created processing

first created it, had no idea what it would be used

to create in the future.

And if you look at some of the things

that people are doing with processing these days,

it is unbelievable.

And you can create beautiful, beautiful art, all animated and doing whatever you wanted to do.

And so this feels like if there is a, if it was inspired by processing and certainly looking at these two examples,

there is potentially a very bright future ahead for possibilities of a package like this.

Yeah. And just a quick word, one other note that I made, it looks like this gives you a language

sort of similar to core graphics, where you can create your primitives and structure them,

just that it uses metal for rendering and it has a SwiftUI interface.

So you can create this, I think these objects are called sketches,

so you can create a sketch and then plug that sketch into a SwiftUI view

with certain camera and drawing configurations and it'll do its thing.

So it looks really interesting.

There we go.

So I think that just about wraps it up for another episode of Swift Package Indexing.

Was there anything else you had before we finish?

No, that's it. I think we should perhaps mention as part of our outro a couple of links maybe.

So we have a Discord, we'll put a link in the show notes.

We also have an account on Mastodon, the Swift Package Index at mas.to, m-a-s dot to.

And we'll put that link in the show notes as well.

And I think we should maybe also give a shout out if you have any suggestions, comments,

questions about the podcast, hit us up. Maybe you have packages to recommend. That might be

interesting. And we should also say hello to the few people who heard our promotion of the Discord

last time, came into Discord and said that they even heard it on the podcast. So hello to you all

who did that. Yeah, that was great. Stop by, say hi. All right, well, we'll talk to you in a couple

of weeks. See you in two weeks. Bye bye.