Join us as we talk about the current state of Swift, Swift 6 concurrency, Swift-Java interoperability, and hear our regular package recommendations.
News
- New sample: Tiny Swing program mixing Java and Swift
- iOS Dev Weekly Issue 685 on the current state of Swift
Packages
- SwiftClaude by George Lyon
- JSONPatch by Peter Ringset
- SingaporeKit by Jia Chen
- swift-glob by Tuist, forked from David Beck
- GestureButton by Daniel Saidi
- StarCraftKit by Marcus Ziadé
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'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.