Swift Package Indexing

I've got, well I've actually got three packages but not a whole lot of notes on the third one,

which is sort of a, kind of a Dave Verwer pick anyway.

I've got a Dave Verwer pick as well.

There we go.

In fact I've potentially got two Dave picks, which are, if you're listening and I don't know

what a Dave pick is, it's an interesting package that comes with some caveats normally.

And is not recommended, actually.

I know, I don't know whether it's, I don't know whether it's about whether it's not recommended

or not, it's just, it's there, there are subtleties to my talking about it. It's not just a,

oh this is amazing, you should use this.

Well let me, let me clarify, it's mentioned and the first thing you say is

you shouldn't be using or you won't be using it.

I do, I do have one of those today.

There we go, excellent.

I do have one of those today.

Welcome to the Swift Package Index.

Well it's, it's, it's rarely, this is, so this is actually, this is the thing with picking

dependencies, right? It's rarely a straightforward decision and that's why you need so much

information that we, we provide with the index.

Right, right. The not picking of dependencies is also a skill that needs to be honed.

And we're here to help.

Well, maybe, we're here, we're here at least.

We are here. There is an interesting post on the Swift forums, not sure if you've seen it,

it's by Doug Greger, a new sample, what's the post title? New sample tiny swing program

mixing Java and Swift. Did you see that one?

I, I, so this is a bit of inside baseball here. I only saw it because you sent me the link to it.

All right, well that, that qualifies it. It means you read my stuff.

I was really, I was really curious about that one. And obviously we talked about the announcement

last episode about the Swift Java interop, which was announced at the server-side Swift

conference in end of September. Really great announcement. Really exciting to see that

development. And Doug has taken what I believe is pretty much a, one of the classic or canonical

examples about Java development, like the UI development. It's like a, a little Celsius to

Fahrenheit converter, right? Just two text fields and a button to convert between the two.

A problem, a problem that we can only solve. There's no way we could solve that problem.

Well, the proper way of solving that problem would actually to just everyone be using Celsius.

I'm sure we also need some kind of microservices architecture in there somewhere.

And that could be Kubernetes deployed. I mean, certainly that would be the appropriate way to do

it. But in the absence of all of that, you'd, you'd obviously write a, a swing Java application

for it. Install Java, which was, which is actually the biggest hurdle in getting this running.

The props to Doug, the example worked flawlessly, but installing Java, which I haven't done in,

in like more than 10 years, well over 10 years. And thankfully it's actually quite easy to brew,

you can install it with brew. You still have to do some fiddling with the setting up the Java home,

like telling the, the OS where your JDK lives. That sort of stuff. I've, I was glad I still had

some memory of, of how that works. It's it, it, it works quite well. And then you effectively just

run Swift build and then you have a, a command to bring up the thing. But what Doug has done

is he's sort of started out the, with the original Java example, then replaced parts of it with

Swift and just initially the computation of converting from Celsius to Fahrenheit,

which is, you know, then handled by a Swift function, but also then the, the instantiation

of the UI components actually invoked from Swift, obviously calling up the, the, still the swing

objects, but they actually created in Swift and then the setup and done is there. It's,

it's interesting. It's like, it demonstrates a lot, even though it's such a small example,

you know, have a, like a proper easy function call. I mean, that's, you know, the first thing

you want to try and see, but it's also the easiest thing, right? Calling a thing that converts one

double into another is something that is, is not as mind bending as thinking about UI components

being instantiated across the bridge like that, and then handed back and forth. And that's,

that's really nice to see. It also gave me a bit of a flashback because I remembered that the very

first application I wrote for Mac OS in 2000, 2001 was actually Java. So you, I'm sure you

recall, I actually know you started using the Mac laters. You might not recall this

when the first Mac OS versions came out after the next acquisition. It came with Coco, which was,

you know, the Coco that we know today, but it came with your objective C sort of backend,

but also it came with a Java backend. So you could write a Java app that called into the Coco UI

libraries. And that's what I did because I knew some Java objective C I'd never heard of before.

And there were examples, they had like the exact, exactly like currently, or for a while,

when Swift came out, you had the, the dual facing, you know, they had Swift and Coke

objective C examples when you wrote an iOS or Mac OS app at the time you had objective C and Java.

Right. And that's what I did. That's a little bit before my time in on the backside, but,

but the only thing I do remember of that is that what was the web frameworks, web objects,

came with Java examples for a long time still after, after they dropped them from the Coco side.

Yeah, there was for quite a while, I think there was sort of, I'm not sure how,

how clear it was to everyone involved, which one would win out. I remember at the time also,

Java was just the thing, you know, it's like these days, you have to have AI at the time,

you sort of had to have Java in your, in your stack somewhere, you needed to be talking about

Java. And it was very much the thing that people thought would solve all the, you know, different

UI paradigms across different platforms and stuff. So it was quite interesting. It did,

I didn't keep it around for long, because it was, it was very clear, I can't point to exact

examples of what tipped me off. But when you looked at it, you knew, no, this, this is the one

you actually should be using. The other one is, is, you know, there were these little signs

along the side, you see, yeah, you can see this is it kind of works, but it's probably not.

It's probably not the one that's, that's going to stick around pretty much like also after a while,

it was clear that, you know, with Swift, newer stuff would be Swift only and Objective-C is kind

of on, on the way out. But it's, it was really interesting to see Java come up again in this

context and being used in a UI application. So really nice example there, we'll, we'll add links

to the show notes. Yeah, it's Java was a language that passed me by, really. I, my university

degree was to, it was before Java's time, we learned C++ and C on in my university degree.

And then when Java was kind of taking off, I was doing Delphi and Object Pascal. And then

from there into, into the web, basically. So Java kind of missed, passed me by. So it's never,

it's not something I ever really got any, any real experience with. I, I wrote, I think I wrote a

little applet once for some website that we did one time. But that was about it. Yeah, no, I only

encountered it in a, in a project later on as well. It's my, my university stuff was also C and,

and Pascal. Yeah, it was Pascal. I'm not sure we used Delphi, but some, some,

something that used Pascal and compiled Pascal. Some kind of Pascal. Yeah. Yeah. Very popular

back then. God, we're dating ourselves again. Let's, let's move on. Yes, yes. It is the old

person Swift broadcast again. Yeah. Talking of Swift, I did a little survey in iOS Dev Weekly

last week, which was kind of interesting. And I, it was, the survey was both about Swift and also

kind of Apple platform development. But, and I wrote about the results of it in last Friday's

email. So there's a kind of detailed look at it there, but I thought it was just worth mentioning

here as well. That both Swift and Apple platform development got, I asked her two questions at the

beginning, which is how do you feel about Swift and how do you feel about object, object Pascal,

not object Pascal. How do you feel about some Apple platform development? And there was a scale

of kind of pessimistic to optimistic from one to five. And both answers got well above average.

Apple platform development got a four out of five and Swift got a three and a half out of five,

which is, you know, it's a positive, it's a positive number. But what I noticed is because

people were also then asked later in the survey to leave comments about what,

about what they thought about these two technologies. And it, what was quite interesting

was obviously the people who felt pessimistic, one of the things that they brought up was

Swift concurrency and language complexity in general. But actually what was kind of interesting

was that also in the people who felt optimistic about the language, those same themes came through

regularly. And it was, it was the main feedback about the language, both from people who felt

pessimistic and optimistic. Interesting. Yeah. I, by the way, I really liked what you did in,

in Iostep weekly last week that you had the intro and then expanded on it later on.

Yeah, I got some good feedback about that. People, people liked it. Although at the same time,

I did get a higher than normal number of unsubscribes. So yeah, it's mixed.

Oh, that's a shame.

The people who took time to write liked it and the people who didn't just unsubscribe.

Well, just, just, you know, these people liked it harder than the others did.

Yeah, it's, it's a, it's a theme and I wonder how much of it is sort of self-fulfilling. I,

I've mentioned this before and I'll happily say it again. I think a lot of this discussion around

Swift getting more complex is just people having to face the inherent complexity there is.

People complain about C++ being complex and other languages being complex. And

there is just something that we're dealing with as we write software for now systems that have

10 cores. I mean, it's not rare. I mean, that's like common to have six, seven, eight cores. So

you are dealing with multi-processor systems and accordingly are sort of

herded down the path of dealing with that. I mean, when I, we're going back in that territory again.

When I started programming, I actually managed to talk our professor at the time into buying us a

dual core Pentium at the time. Like you actually had two processors. There were like two separate

cards on the thing and that was rare. So in lots of ways, there was no complexity of that sort to

deal with. Yes, of course the systems were multitasking and they did stuff and you sort of

all the underpinnings were already there. But I think these days you are just, you're leaving

much more on the table if you ignore that and don't deal with it at all. But that complexity

is there. You need to synchronize somehow when you deal with data, right? It's just because Swift 5

doesn't deal with the warnings effectively that Swift 6 flushes out. Doesn't mean the problems

aren't there. It's just, you see them maybe rarely because you don't look at crash reports or

you don't make the connection necessarily. You think it's someone else's bug, but

stuff is there and some part of the system has to deal with it. And you are part of that system

having to deal with it. So in a sense, it's like complaining about the weather. I mean,

you know, you got to get a bit thicker coat. It's just no way around it. Yeah. I think one thing

that I, in my, when I was writing about it on Friday, the one thing I added to it is obviously

that we've said many, many times now is that you don't need to opt into Swift 6 language mode

immediately. But I think there is also a downside to that, which is that people don't like feeling

like they're being left behind. And maybe this is clear, but I'm not sure it's clear to me.

Certainly I can't think whether it's been said off the top of my head is, is there any

estimation of how long these language modes will stick around? I mean, is staying on an old

language mode indefinitely? Is that, I don't think that's a possibility, but I don't think

it's clear when you'll be kind of moved towards making that decision, whether you like it or not.

Honestly, looking at lots of packages, I get the feeling like the packages themselves are going to

age out before Swift 5 mode disappears. I mean, like Swift 4 mode is around and no one is writing

packages in, you know, that requires Swift 4 anymore. And there were also big steps in the

past that sort of, you know, were hurdles. And I don't think that's a concern. I mean,

not in the sense I understand that people have that worry, but I think it really bears repeating.

That's not the thing you need to worry about. I think that the thing people need to worry about

is whether the cost of not using what Swift 6 mode offers is a loss, right? Are you not

leaving something on the table by not using these tools to make it easier and safer? I mean, easier

is sort of, it's only going to be easier in hindsight. You know, once you've paid sort of

the price of learning how to actually use it, then, you know, then that, you know, the balance

shifts a bit. Actually, something I want to bring up in that sense, because you see this a lot in

social media, it seems like it's often people well regarded in the community that spearhead

these discussions about Swift complexity and stuff. And there's a really interesting

observation I made a while back, there was a well known podcaster and Swift author,

I don't want to name him, although it's probably going to be obvious who it is,

because I don't want to throw shade, but he was very reluctant to move to Swift. He complained

about it. It's super complex and hard. And, you know, it was very clear that the problem of

switching wasn't the language, but his discomfort of trying the new thing and feeling like stepping

back. And it's very easy to feel that way, right? There's something you're really familiar with,

you know exactly how to do and you're asked to forget that or sort of not use it and use

something else instead and relearn your skills. And then at some point, you realize, well, I'm

going to have to move because I can't be using I can't keep object using Objective C anymore,

there are APIs coming out that aren't Objective C native. And while it still might be possible to

use them, I'm very clearly, you know, going down the wrong path. So he started writing parts of

his app in Swift. And lo and behold, week by week, it seemed to be getting easier. And after a while,

he spoke quite favorably about Swift. And he made that transition, he made that change, he trained,

he retrained in Swift, and I would actually get his his really his common body actually post stuff

where he says, this is really nice. Look, look how Swift is succeeding here. I think if you presented

him today with a choice, which one do you like better? Which one do you think is easier? Which

one is is, is better at dealing with the complexity of your software? I'm pretty confident he'd say,

it's Swift. But it's really hard to see that before the transition, this is only something

you see after you've you've paid that price of, you know, that ramping up cost into, into the new

system. And I think that's largely a communication problem and and education problem for all of us to,

to take the plunge. And also, I think on the tooling side, they are, I mean, we know this,

right, there are rough edges still around how warnings are presented, how many there are,

some of them can actually go away, because the compiler can be smarter. And I think,

because of that, it's really important to stress that the switch to Swift six mode is not something

you need to do immediately, you actually are on the leading edge of the adoption curve, if you're

doing it now, oh, completely give yourself the time, because stuff will improve all on its own

without you doing anything. And if you do this in a year's time, you'll have a better time.

By all means, if you feel like it's interesting, and something you want to do now do it because

you will benefit already. I mean, we have benefited in our project from from doing it.

But it's you're not, there's no FOMO here, you're not losing out on anything by waiting. In fact,

you're you're gaining, you know, just letting other people do the adoption is helping you

indirectly. And I think that's the part that is missing a bit. And I suspect a lot of that

negativity around Swift and concurrency is, is a bit of fear, you know, there's a big change

coming. I don't really know what it's about. I see these people who are really, you know,

advanced struggling with it. How would I have a chance? I mean, I have those same thoughts. Like,

I, I look at Matt Massicotti, who we'll probably be talking about in a minute.

Again, making changes and struggling with some of that stuff and posting stuff. And I read his

posts, I think, Jesus Christ, I would never figure this out. But the good thing is, I don't have to

write, I can just give myself the time and wait. There's no, there's no one sitting there and

asking me to make this change tomorrow. I think, I think everything you've said there is, is,

is good. But also, in some way, doesn't matter, because the perception is, is the reality. I mean,

people, there is a, there is a definite feeling of this. And it's, it's not something that should be,

I don't think any changes are needed or anything like that. But it's certainly something that

we should be aware of, because it can, this kind of thing can, can become how, how people externally

see the language as well. - Yeah, absolutely. Yeah, that's why I'm saying it. I think it's,

like, communication-wise, it's really important to, to try and, you know, maybe not counter,

it's like, it's more, it sounds more like an argument, but maybe stress that there's no,

the time-critical part isn't as time-critical as you think it is. And to more pitch

this is not a chore. This is actually, you're, you're opting into a, a mechanism that helps you.

And I, I often miss that from the discussion. The, the upsides of making this change aren't,

aren't what's typically presented. - I would push back a little bit there. I think,

I think, I think it's clear that there are advantages to adopting data-based safety in

Swift 6 language mode, but they are not super obvious changes in all cases. In fact, in most

cases, they're not super obvious changes. And this is not, this is not a problem that the language

was really struggling with any more than any other language struggles with this. And yes,

it's better, but it wasn't, this was not something that people were going, "Oh, I wish that somebody

would solve data-based safety." And I think that's where some of it comes from. - Yeah, that's a fair

point. But I think that's also because we don't immediately associate issues with, with the source

there because it's so disconnected, right? This is like, this is like someone pushing a change on

Wednesday and, and, you know, two weeks later it crashes in production. You don't make that

immediate connection. And these crashes we, we often seen, it's really hard to trace that back.

- It often is, yeah, exactly. Yeah. Yeah. But if you think, and that's, but that's in a, that's in

a highly concurrent Swift on the server application. If you think about your average iOS application,

this was not the big problem. - Well, I guess, but I mean, it's also not something that's even

harder to see there because it's not your device that's going to crash, right? - Sure, sure.

Anyway, good, good, good to hear what people are thinking about it. And, and, and as you say,

going forward, it's only going to get better from here. You don't have to do it immediately. So,

but I thought it was interesting to bring those, bring those results to the podcast too.

- Yeah, absolutely. Yeah. And I think it's, it's also important not to just,

just gloss over it, right? Because if people voice that concern, it's, it's a, it's a concern that

needs to be heard and discussed and, and, and of course, it can drive a bit of change around tooling

and communication to, to make it clearer what the, what the stakes are. - Shall we do some package

recommendations? - Yeah, let's do some packages. - Okay. I will start us this week and I'll start

us with a package called Swift Claude, which is predictably an API wrapper around Anthropx

Claude API, which is one of these LLM providers. They are kind of on par with ChatGPT and OpenAI

as, as the kind of market leader. And this is a predictable wrapper around the API, but there

was something in it that struck me that I hadn't seen before and I thought was worth a mention.

And it was that you can, apparently in the Claude API, you can supply functions in your code

and let the AI decide when to call them, which is something I hadn't come across before. And you can

do this via the API. So you can define a, an API within your Swift code and using a, a property

wrapper, you can mark that as something that the API should be aware of. And it will communicate

the details of that API up to Claude. And then Claude will decide, depending on what, what it's

doing with your prompt, will decide what, when to call that function and what parameters to call it

with. So you can kind of have the LLM decide to call, call back to code in your application,

which I thought was very interesting and a great implementation through property wrappers here into,

into Swift is really a very trivial, a very trivial mechanism to

transmit the details of your API up into the Claude API.

Interesting. Is there like an example given how you would use that?

There is, there is, but it's a, it's a very abstract example and not actually that useful

unless, unless it's referring to something that I don't know about. So the, the example that's in

the readme file is there's a struct called turbo encabulator, which I don't know what an encabulator

is. And it says it turbo encabulates its input. And the parameter is a number of marzl vein count,

which I also don't know what those are. I think they're made up. I think, I think it's just a

completely abstract. I think it is. I think it's just completely abstract, but it's, it's so

obscure that it made me think, I wonder if this is a thing that I just don't know about.

And, and then in the conversation, the prompt says, I'm creating a demo showcasing your ability to

use tools. Can you invoke the turbo encabulator tool with some made up input? So I have a feeling

it is purely just a, an abstract example. Right. Yeah. Okay. Interesting.

And of course it also supports all the other things that all of these API support. So it

supports full text responses. It supports streamed text responses. So you can show the output as you

receive it from the API. It has image, UI image and NS image compatibility. So you can include

images with your, with your prompts and you know, all the other things that these, that these API

wrappers all, all do. But I thought the, the tool use was, was worth, worth a mention.

Nice. Yeah. Interesting that these, I guess all the LLMs and their providers are covered by,

by Swift packages now, aren't they? I've seen quite a number of them.

Pretty much. Yeah. Yeah. There's, there's certainly ones for all of the major kind of

commercial ones. And then there's also ones for things like Llama and a lot of the other

ones as well that are kind of some of them are non-commercial too.

Okay. My first pick is called...

Oh, and I didn't say who that was from. It was from George Leon.

Nice. Okay. My first pick is called JSON Patch by Peter Ringset. And this is an interesting

package dealing with JSON Patch objects. Have you heard of JSON Patch objects before? I hadn't.

I have.

You have. Oh, okay. So...

I've not used them, but I have heard of them.

Interesting. Yeah. So this was new to me. So this is actually an RFC and it's an RFC to,

like a spec to modify JSON objects. And effectively it's like little specification

for little JSON snippets that define operations on a JSON object, like add, remove, remove and

replace operations on properties. Like you could add a new property, remove one or replace one,

or replace the value and stuff like that. Think of as a diff mechanism on a JSON object. And

this is like a Swift package that deals with that. So you can specify these operations in Swift and

then generate these patch objects and also apply these patch objects to an existing JSON object

that you have in your data and stuff like that. So really interesting. And I think this is also

interesting in combination with HTTP patch requests, where you would not send the whole

object again, but have a patch operation on an existing object. And then you can

streamline your APIs to be passing around these rather than having big objects passed around

when they change and stuff like that. So yeah, quite interesting. That's JSON Patch by Peter

Ringseth.

Very cool. My next package is called Singapore Kit by Jia Chen. And this is a package that is

very specific. So it is a package that makes it easy to use Singapore government data within your

SwiftUI projects. And again, comes with a property wrapper. And that's the reason that I'm highlighting

it really is this property wrapper effectively gives you a Singapore property wrapper that you

can pop before any variable. And if you pass a key path into that property wrapper of one of the

bits of data you would like, for example, like relative humidity or air temperature or rainfall

or air quality or UV index or a whole load of other bits of data, and then declare a variable

after that property wrapper, it's going to automatically pull that data in and assign it

into that variable for you. And it reminded me of something that we're just switching across to

in the Swift package index now. It reminded me of the dependencies package and property wrapper

from Pointfrico, which I think works in a... I don't know how it works behind the scenes, but

to the end user, it works in a similar way is that you kind of say, this is a piece of data that I

would like to bring in as a dependency to this type that I'm working with right now. And that is

literally all you have to do. And it's a very powerful way of working with something like this.

Now, I'm not sure what's happening behind the scenes, whether there are network requests being

made. And that is the disadvantage of something like this is that it is completely opaque,

how it's actually working. Is there any caching happening here? Or is this setting off network

requests, which I presume it is. But I do like the syntax of this. And I think it's something

that I'm seeing more and more often at the moment. Interesting. I wonder if that would work because

a property wrapper can't be async, can it? So I'm curious how that works.

I don't think it can. But I am looking down further in the readme now and I am finding that

the relative humidity, for example, this is just an example that's in the readme file,

comes back as a enum, which can be loading, failure or success. So it clearly is async

because there is a loading state. And you are tasked with dealing with that loading state in

your code. Interesting. Yeah, I guess that's kind of similar because the dependency system

you mentioned is also very similar to the environment system in SwiftUI. So I'm guessing

that's just to give people an impression that's what the API looks like effectively, isn't it?

Yes. I should have thought of environment. I think it's just because we've been working

with dependencies recently. Exactly. It's the thing that came to mind. But I like it. And I like

that something, I guess this is a very specific use. The Singapore kit is only, you're only going

to need that if you're writing an app that deals with Singapore data. But I do like the technique.

Well, it might be interesting if you're building something similar for a different data domain or

a different domain in general. Sure. Take a look at it.

Interesting to inspect how it's done there. 100%. Yeah.

My second pick is called Swift Glob. And it's by Tourist, but forked from the similar

project by the same name by David Beck. And Tourist have taken this over. I think the other

project has sort of not been maintained anymore. And it does what it says on the tin. So this

gives you a Glob API for file name lookup. And by Glob, I mean, like the star thing, like the

star.swift to match on all the Swift files in a directory. It also supports the double star slash

syntax. So you have all the subdirectories and then it searches through those. I think it follows

the, I think there's a standard around Globing how the syntax works and it's allegedly.

Right. Yes. Compatible with that general standard. But this is like a really nice API,

because to my knowledge, there is nothing like it currently in foundation. So you'd have to do your

own, you know, get all the entries and then filter on them. And this just deals with that. And you

can write really expressive file filters in your application if you need that sort of thing.

Yeah, nice, nice API, very focused and easy to use.

Great. Now it's time for my Dave recommendation.

My final package this week is called gesture button by Daniel Seide. And it's a SwiftUI button

that as the readme says, the gesture button is a SwiftUI button that can handle many different

gestures. So it is just a button, but you can also add functionality on is pressed, press action,

release inside action, release outside action, long press action, double tap action, repeat

action, blah, blah, blah, blah, blah, lots of these, you know, even dragging and dropping

and things like that. And it is a, an encapsulation, I think of all of the different things

that were possible with the old UI button that maybe all of them haven't come across to

SwiftUI yet. So if you want to do something slightly non-standard with a button, then

this is the kind of package that is going to help you do that. My, my, my caveat to this is

don't do weird things with buttons. And the reason I'm talking about it, because obviously if I just

don't, if I just believe that you just shouldn't ever do weird things with buttons, then I just

wouldn't talk about this package, right? But it is worth talking about because there are

situations in apps all the time where you do just want to do something extra, a little bit extra

with a button. Maybe it does drag off the screen. Maybe it does have a long press or something like

that in addition to the short press or something like that. I can't think of any specific examples

right now. And this kind of package is going to be better in those situations than rolling your

own stuff at that point. But resist the temptation to go crazy with buttons because it is a common

user interface gotcha to have buttons that don't behave like buttons and people expect to be able

to just tap on a button and have it do a thing. And playing with that expectation is very risky

in terms of whether people will be able to use your application. So I do like the package,

but I also think you should be very cautious with your use of it.

Yeah, I think that's great advice.

All right. Well, my third pick is a Dave pick as well.

And it's a package called StarCraft Kit by Marcus Ziedde. And I, this is super niche.

You're really unlikely to ever use this, but I just saw the description. It says StarCraft Kit

aims to be the go-to Swift package for developers working with the StarCraft 2 Pro scene. And I

thought, well, it succeeded in that mission because I think it is the go-to Swift package

for that purpose. It is number one in that list. But I also thought it's great that there are

these packages being now served in the Swift ecosystem. Like, is this like super niche? I

think. I mean, I know StarCraft is still big given that it's a... God, how old is that game? That's

like 20, 30 years old? Yeah, it must be 30 even.

No, I mean, StarCraft, the original StarCraft is that old, but I presume that's not StarCraft

they're talking about.

Well, StarCraft 2 is also old.

It's not new. It's certainly more than 10 years old.

But I know there's a tournament scene around that. But still, to see a package like that

pop up is quite nice. I think it's really great to see that even these niches are now being served

in the Swift ecosystem. That's why I thought I'd highlight it. It has a text user interface.

I think there's a tournament site and data that you can crawl through and inspect and stuff and

list and all sorts of stuff. Just have a look at it if you're interested in StarCraft and see what's

going on there.

I did have a look at this. And in fact, it was on my shortlist of packages to talk about this

week, but it didn't make the final three for me. But yes, I thought it was great to see this. I

think it uses... There's an API that it uses called PandaScore or something like that. I was

reading the readme. And so it has... There's a web API behind the scenes where it's getting all

this stuff from. But you're right, that this is the premier StarCraft stats package for Swift.

- Nice.

- Yeah, I think it's great to see all sorts of packages. You're right, I do like to bring

the occasional obscure one that you might never use. Well, I've done many retro computing ones

in the past. And is StarCraft 2 retro yet? I don't know. When does it become retro?

- Oh, I'm sure it is. I'm just checking. The original StarCraft came out in '98. StarCraft 2,

the expansion came out in 2010. So it must be... Oh no, 2010. So yeah, it's not the 20 years that

I gave it.

- Right, so 14 years.

- Yeah, but still.

- Yeah, old enough though.

- Yeah.

- Right, let's wrap it up there. And we will be back in a few weeks with more news from

the package index and package recommendations or not recommendations as the case may be.

But until then, we will say goodbye for now.

- See you next time. Bye-bye.

- All right, bye-bye.