Swift Package Indexing

A big piece of news recently was that the Swift language account, social media account,

is now on Mastodon and BlueSky. There was an announcement on the Swift forums. This is a

follow-up to a discussion that was also on the Swift forums where someone asked what the state

is of moving and apparently took quite a bit of effort to get this going. And it's great to see

that this is finally happening because I think I know there have been a lot of people, myself

included, who moved off of Twitter quite a while ago and were sort of cut off from any official

Swift language announcements. I mean, it wasn't hard to see or hear about stuff that was happening,

but it is kind of nice to have the official accounts in the places where people are, right?

And that has changed very significantly. To my knowledge, that doesn't mean that the Twitter

account has been abandoned. This is something I personally wish would happen too. Twitter has been

a platform that runs counter to the values Apple usually promote in and around the company. And

ever since the Musk takeover, I think it's very clear that this is going in a very different

direction. And I think it dilutes their message quite significantly. I don't think you can have

it both ways here. Promote these values and then be on Twitter. That's my personal opinion. I just

feel like I'm wanting to say that actually. And this is also something that Matt Massicotte

addressed in his blog post, Leverage, that he posted a few weeks ago. And I think you also

mentioned in Iowa's Step Weekly at the time. I did. Yeah. Yeah. And he wrote that in response

specifically to Apple recommencing their advertising on Twitter, which I think goes

even beyond just being present on the platform. It's actually giving money to the platform. I

think that's even a step beyond that. And I feel it's important that we make our voices heard here.

It's something I want to do on this occasion. I don't think it's a good look for Apple to be

present on Twitter in general, but particularly to give the platform money, as I said. And I

recall a time when Parler, for instance, was removed from the App Store because it violated

the policy. And I don't think Twitter is significantly different of a platform these

days. If anything, it's worse if you look at what's being posted there and by whom in particular.

I know these things aren't easy. There's probably a lot of pressure on the company to keep doing

certain things. But leadership is doing the hard bits, right? If stuff was easy,

there was no need for leadership. Personally, and I've also expressed this on Masternod,

I quite struggle with the fact that Apple is sponsoring Swift Package Index, which allows

me and us to work on this project that I love. But that same Apple is giving money to Musk. And

I think that's a bit of a bitter pill to swallow. I can rationalize this to a degree because I know

Apple is not a monolith. We're dealing with various different parts of Apple. And I suspect

there's lots of people, in fact, I know there are people at Apple who have different opinions

because I see them post them. And it's a huge company and there's always going to be different

ideas around how to do things. And as I said, I know there are certain pressures, but I think

it's important to not lose sight of what you actually want to be seen as standing up for.

And I think the association here is bad. And I wish all of Apple took a stronger stand in this

regard. So yeah, that's my little soapbox moment. - I mean, I agree on the Twitter thing, of course.

I wrote some stuff in iOS Dev Weekly, as you mentioned. I don't really have anything to add

to what you just said then. Well, what I will say is that it is great to see Blue Sky and

Macedon support for the Swiftlang account, to see them active there. And actually, the other

thing that's worth mentioning is that before the adoption of the two new social networks,

I know that the Swift team have been doing more promotion on social media. So they've actually

been using some of the package recommendations through the package page on the Swift website

to promote some of those packages through social media. And of course, now those are going to be

on all the platforms as well as just Twitter. So it is good to see that not only there is an

expansion of the platforms, but also that there's an expansion of the usage of those accounts as

well. - Yeah. And just to reiterate, I think it's great to see that adoption of Macedon and Blue

Sky and my little rant wasn't intended to sort of dilute that message. I think that's great that

it's happening. And I guess small steps, maybe there's a discussion to be had about taking it

further, but this is great to see. And I also have seen that the Swiftlang account has picked up some

of the links. I don't know about the change because I haven't seen what happened or is happening on

Twitter, but it's just great in general to see them show up in these places now. - Well, that's

the irony of it. I heard about this happening. I didn't see it happening because I also don't use

Twitter anymore. So I didn't see it through seeing the posts. I saw it through people telling me

that there were posts. - Right. Okay. - Which is a far more pleasant way to use Twitter in my

experience. - Twitter by osmosis. - Exactly. Yeah. By proxy. Yep. All right. Let's move on to

something else. One thing that I wanted to talk about this week was we've had a fairly long

standing issue with our ready for Swift 6 page that we did last year, which is the collection

and reporting of the number of data race safety issues that the Swift compiler is reporting

if it were in Swift, or that it would report if it were in Swift 6 language mode. And we display

that on every package page as an indicator of whether a package has data race safety errors.

And we also have this, we still have the ready for Swift 6 page on the site, which shows those

numbers over time, basically, as the Xcode releases happened over last summer. We have the kind of

historic view of the number of data race safety errors across the entire package ecosystem.

But of course, at this point now, the information on the package page is the most important thing.

And what we saw as we kind of looked into this in some detail, is that there are certain situations

where package authors are dealing with and potentially suppressing in completely legitimate

ways, data race safety errors. And the numbers that were coming out of the stats system in the

Swift compiler were not representing those suppressions correctly. I think that's pretty

much a reasonable summary of it. Yeah, maybe suppression is like, you mean like fixing or

addressing? Yeah, suppression is the wrong word. Yeah, suppression is the wrong word. I knew it,

as I was saying, I was saying the wrong word. I think specifically, like if you add

pre-concurrency imports, where you effectively indicate, well, this library isn't Swift 6 ready,

but I want to use it, I have to use it. And I know it's a legitimate use of that. And I think

the false positives there were that these certain errors were still being counted as errors,

even though they weren't actually showing up as errors when you run the build with Xcode and Swift

build. That's it. That's exactly it. So anyway, the good news is that we reported the error to the

Swift GitHub repository. And the great news is that that error has now been fixed. It's not entirely

clear whether that merge, so the fix has been merged, but whether it has been merged into 6.1,

which is now in beta, or whether we may have to wait for 6.2 for that to get through into an actual

tool chain that ships with Xcode and, you know, is in the Linux release as well. But the good news

is it's fixed. So we should, there is light at the end of the tunnel for being able to report

truly accurate beta race safety numbers, as you would see if you open the project in Xcode.

Yeah, yeah, I've made a note. So by next time, we'll know. And depending on the outcome,

well, maybe in general, we will run a new run with 6.1 is out, we sort of stopped doing the

every two week runs, because with the numbers, sort of uncertain, it didn't really make that

much sense to stress the system every two weeks with something where we knew a lot of packages,

where we're seeing issues. And yeah, it felt like, you know, not worth the effort,

without that error actually being fixed. So we know we get good numbers.

But it's going to be really great to see those numbers finally be something that people can rely

on. Where at the moment, I think we actually have a slightly softened wording on, I'm trying to find

a package with data race errors, and I can't find one. Isn't that great? I clicked on four packages

there and not a single one had data race safety errors. In fact, I'm clicking on more and none

of them have data race safety errors. That's just amazing. Let's keep rolling while you find one.

You should play some suspense music when you do the editing.

Exactly. This is remarkable. I'm still clicking and I can't find any. Okay, but I'm sure we

softened the wording slightly to say there may be data race safety errors or something like that.

I think GRDB is one because that's actually a false positive. So I think it should list an error.

If you want to check that one. Here we go. That's it. I'm loading it up right now.

Yeah, so it actually, maybe we didn't soften it because it does say has data race safety errors.

And that will be fixed. So it's great news. Excellent. All right. The other bit of news

regarding the Swift package index was that we have just finished the transition of moving all

of our tests from XCTest to Swift testing. So Swift testing is the new testing framework that

was announced at last WWDC and shipped with Swift 6. So that was the first version that had it.

Swift 6.1 has an additional feature in Swift testing, which we will want to be using. But

the initial transition is actually just needs Swift 6. So that was sort of one of the things

that we were waiting for. But also, you know, the obvious first question is, well, why would you even

want to do that? Because our tests were working. We have a lot of them. So why actually try and do

that? Ultimately, the reason is we want to try and run our tests in parallel. We have a lot of them.

They're using actual live database connections that run in the Docker container. And the idea

is to speed that up. So they are slow because of that. We have around 800 tests. And they take,

I think in CI, they take 10 minutes. It's off the order of minutes.

No, it's like, yeah, 10 to 15 minutes, I would say.

Well, a lot of it is the build. So that's why I hesitate. The whole thing, the whole CI runs 20

minutes. But a lot of that is actually the build. Because in the CI system, that's quite slow. It

might be 10 minutes build, 10 minutes test run. But even locally, where I think the most important

is the full test suite right now on my machine runs in two and a half to three minutes. And that

is quite significant. When you've done something, you know, you kind of want to have a quick check.

That's not a quick check anymore. And the idea here is to just run the tests in parallel and

cut down that time significantly. Now, in principle, that would be possible with XCTest. But

there are a couple of shortcomings with XCTest that make that harder. And I did a little exploration

before I embarked on this whole thing. And I concluded, it's not actually worth the time

trying to fix that in XCTest. It's actually better to just transition and then do it properly in

Swift testing. Because obviously, that's the thing that's going to carry us forward much further than

XCTest ever could. And it also has obviously a lot of other nice things about it, you know, like

better asserts, expect macros, give a nicer printout. And it's faster, actually, the test

discovery is faster. Also, like Linux and macros tests actually run in the same way now. Lots of

little things and bigger things that come together that make this worthwhile. But also, there is one

piece of sort of a tool that really makes that feasible at all. And that is something I mentioned

before on the podcast, I think I even had as a package pick. And that is Swift Testing Evolutionary.

That's a package that was driving this transition. And I'll get into it a bit more. But I just want

to describe the sort of where we started off. So we had our test suite is, as I said, quite

significant, we have 105 tests, like test classes, which turn into test suites and Swift testing,

with overall 798 tests. So that's the individual test methods on XCTest, which get turned into

these at test attributed functions. And inside of those we have 2300 asserts. That's what gets

turned into these expect and require macros after conversion. And you can imagine, I mean, you can

you can potentially manually transform 105 test classes into suites, that's sort of not something

crazy. You could conceivably convert the tests, you know, because that's maybe doable with

replace, you know, some some replace magic. But all the asserts is just that would be madness.

And this is where this tool Swift Testing Revolutionary comes in, because it does that

for you, it actually uses Swift syntax to look at the test structure and rewrites all the code,

it rewrites the test suites, the test functions into the attribute test functions, and it rewrites

the asserts. And that's a critical piece. And it does a really, really good job. There are a couple

of cases where it doesn't quite work. It's mainly around where you have where you try to test

exceptions or not. Yeah, exceptions and have throwables that you want to assert. So there's

a bit of syntax weirdness that you have to deal with manually. But the vast majority of these,

I'd say like 95% of these assert conversions, it does automatically. And that is just huge,

because that really makes that feasible at all. Because otherwise, if this tool didn't exist,

I don't think I would have done that transition, certainly not within the time it took in the end.

So I started this in on February 5, and I finished on March 5. And this was not a full time project.

This was, you know, as I went along, I did, every day, I did a couple of test cases that I converted

and tweaked. Obviously, I picked a difficult one up front to see, you know, which bits are

potentially hard to convert. And there was a bit of upfront work I had to invest because

there are a couple of structural differences between XC testing and Swift testing. They're

mainly around sort of I pattern, which is resource acquisition is initialization. By that I mean,

when you use a database connection, for instance, in a test, you typically set that up in a test

setup function. And then you tear down in a test tear down, you know, because we have a Docker

container that we run against, and we don't want to have tests, cross talk where one test would

leave around stuff that the next test then sees and, you know, it would affect the results.

So what we do is we do a schema setup, and then a schema wipe at the end of the test or at the

start of the next test. And that is something that works a bit differently between the two

mechanisms. And that was a piece that really required a bit of redoing. But once I'd done

that, it was really quite easy and mechanical to convert the tests over. So if you're planning to

do this yourself, I'd really recommend pick a test that you know is sort of complicated deals with

some external dependencies, stuff like that maybe is is testing something very complicated,

convert that. And when when that's working, when you know it convert work on that one, then do the

rest because after that, it'll be really, really easy and quite mechanically especially if you use

Swift testing revolutionary to do the the automated bits for you.

Yeah, that's great. I mean, I, I did look at some of the the the results of the conversion. And I

think it was a curious choice to just replace every assertion with expect true to equals true.

The good news is the test path pass really fast now.

Yeah. Yeah. And not only that, it also gives you more.

I think you missed my joke. Every expectation is replaced with true equals true.

But everything is super fast.

I end up with Sorry, I missed this joke. It was

well, you can you can add a laugh track. I was so focused on the next thing I was gonna say.

Apologies. The other bit that's really nice about a it makes it really easy to to actually write

expectations because it's you just need to expect and then you write it as you normally would you

don't have to think about well, is it? Yeah, like exit he assert equals is it equals accuracy? Well,

actually, is actually bad example, because that's a bit of a gap in in XC, in Swift testing right now.

But what it does is, for many types, it will actually give you really detailed printout if

something is not equal. And that's that's a problem often when you have complex types where you,

they might be equatable. And you the exit he assert equals macro works, the old one, it will show you

there's a you know, it fails properly. But then the output is, is effectively, it doesn't tell

you anything because you just effectively just see what this fails and the the printout is is useless.

And this is where expect macros are, are better because it can drill into a lot of stuff like

arrays and dictionaries and actually pull out the details and give you more information about the

text failure without you actually having to actively instrument that in more detail yourself.

Right. So yeah, it's that's, it's, it's great. I'm, I'm really looking forward now to tackle

the the actual objective in making our tests, which is the parallel parallel. Yeah. And I've

hit a couple of additional problems now as you do. But I think we can at least move some of them

to run in parallel fairly soon. There's a bit of legwork still to do, but I'm quite hopeful that

this will work out. It has worked in principle for one test, the problem is a bit to to do this

for the whole test suite when you run parts of it in parallel and parts of it really need to

still run sequentially, I'll have to figure out if how to best address that. But I'm hopeful that

this, this will work and then then speed things up. Yeah, that's great. Great to see. And I'm happy to

happy to see that Swift testing has been such a positive enhancement. I don't think there's any

kind of steps backwards with Swift testing. I think it's looking great. Yeah. Yeah. And if you

do the transition and you have any questions, there's a great Slack channel on the swift.org,

the official Slack Swift dash testing, where Jonathan Greenspan, for instance, is very responsive

to questions. And, you know, just pop in that channel if you encounter any any difficulties.

There are a couple of rough edges still that are being ironed out right now. But overall, it's

really pleasant to work with. And if you run into any issues, people there are really super helpful

and will get you will get you going. All right. I think there's just one very short other piece

of news, right? There is indeed. Yes. And that was a blog post that was announced on the Swift

forums, I think just earlier this week or in the last week. Swift on Raspberry Pi building

natively and cross compiling by Nathan Volnick, assisted by Jesse Zamora. And that's sort of our

our ongoing topic of Swift in unusual places. Maybe not that unusual. I think Raspberry Pi

has sort of been a supported platform for quite a while. But this is really great post that gets you

started. You know, like if you have a Raspberry Pi and nothing else, you it'll it'll walk you

through how to set the thing up even not just about Swift, but just Raspberry Pi in general,

what images to flash onto the thing and then how to get Swift onto it. Get a program running,

compile stuff there directly, but also do the cross compilation, which is super useful. And

because the Raspberry Pi can be slow to compile Swift stuff. I mean, obviously, it's it's not a

machine comparable to a Mac compiling stuff. And that's, that's great. Now, I think it was Swift 6

that introduced proper cross compilation was possible before, but now it's a properly supported

setup, which means on your Mac, you can you download and prepare a specific tool chain for

cross compilation, and then you pass a flag to the compilation command and you get a binary that is

that you just SSH or SCP over to the Raspberry Pi and run there. And that's that's that. So you

can cut down on compile times quite a lot, especially if you have a beefy Mac, that should

help a lot to get you going on your Raspberry Pi projects. So yeah, give that give that blog post

a look if you're into that sort of thing. That's great. Okay, should we do some package

recommendations? Let's do it. Yeah, I shall kick us off this week. And I'm going to start with

a double a double recommendation. They're actually quite different packages, but they're both

brand new and both by the same author. So the author is Robb Böhnke. I'm sorry for butchering

that pronunciation. I think I might help you here because I think I think I was gonna ask

for your assistance because you're German. Okay, sorry, Rob. They're from Robb Böhnke.

And the first one is called AtRandom. And it's a property wrapper that you can use specifically,

I'm sure you can use it for other things. But specifically, it's designed for use within

animation code in SwiftUI. So let's say you wanted to grab a random number to start or affect

some animation by a certain random number. So it's not exactly the same every single time.

You might choose to store that in a state variable because you might want the same random number

every time. But instead, you could use this random property wrapper, and it will create a

persistent random number. So it will be the same random number every time you come into your

into the function. But it will be random on that initial set, I guess it's the property

wrapper version of a C static. So that's really not a not again, not something you're going to

use every day. But I did like the idea of that. And the more you work on SwiftUI code, the more

the state variables can kind of explode, especially with things that are not necessarily

really important to store as state variables like this. So I like that. And the second package from

the same person is called visualized touches. And I've seen a couple of these over the years.

But I really like this one. And it's also compatible with SwiftUI, which is great to see.

So when you're recording a demo of your application, or a tutorial for your application,

or something like that documentation, or whatever it is that you need a screen recording for,

you can, it's useful to be able to show where your fingers are touching on the screen. And Rob

has developed a view modifier for SwiftUI, that you can just add visualize touches on the end of

any SwiftUI view. And it will represent wherever you're touching on your device with two very

beautifully drawn kind of circles to show each fingers kind of placement on that view. Not

something you'd ever want to ship. Because you wouldn't want this happening when people were

actually using your application. But really great for preparing demos and tutorials, like I said.

Yeah, that's such a great thing to have. I always love it when that's actually available.

Sometimes I see people posting screen recordings of their iOS devices. And I really struggle to

see what's actually going on, because I really miss that information. You know, there's no mouse

cursor or anything to guide your eye, to guide you where to look. And I feel like often stuff is

happening and I have no idea what's going on. So I really love that sort of that extension and

videos that actually have that as a tool to guide you. Great packages.

Yeah. And it's, they're just, the touches that get visualized, it seems strange to call them

beautiful because it's just a couple of circles, but they're actually really, they're really nicely,

they're really nicely done. So that's Visualize Touches and AtRandom by Robb Böhnke.

Great. My first pick is a package by, well, who other than pointfree co,

repeat offenders. They keep publishing great packages. I think you also had this

on our Dev Weekly, apologies for mentioning it again. It's SharingGRDB

and this is sort of a double mention also because a while ago,

pointfree co released their package, Swift Sharing, which is perhaps best described as

an observable style macro that allows for a configurable backing store.

What that means is that you can annotate a property in your typically Swift UI project,

let's start there, to be backed by some kind of a store like user defaults, the file system,

whatever, it could even be a server that you connect to. The interesting bit about Swift

Sharing in general is that it's not Swift UI only, and that's how it's different to observable.

You can use this to drive your view models or it's also cross-platform, so you can use it on

Linux for stuff there, for instance. And Sharing GRDB is an extension on top of Swift Sharing,

and it gives you a SQLite-backed store powered by GRDB. And that's a library we talked about

in episode 43. And it's probably the most prominent SQLite library in the Swift ecosystem,

I'd say. So this sort of marries the two packages and gives you the power of Swift Sharing backed by

GRDB as the persistence layer. And all that GRDB gives you on top of this, obviously, available.

And SQLite in general is just a very powerful exchange format too,

meaning you could use this, for instance, also as a file format to ship stuff around.

It's very compelling for that. It's very easy to use and certainly more performant and more

structured than a JSON file or multiple files that you might be moving around here, because

you can use SQLite to then run queries and stuff. You can even run subscriptions on changes. You get

notified if stuff changes in the database and then get notified. And Sharing has a mechanism for that

too. That's what Observable is about, to feed views by updating the database. You can then fan

out and update views automatically. It's quite powerful. Look at it if you are in need for that.

Also worth mentioning is Sharing GRDB back deploys to iOS 13. So that might be a really good

alternative to Swift data, because that is not available to my knowledge that far back. Well,

certainly it isn't, but I don't actually know what the cutoff is for that. So if you have needs for

persistence and Observable style stuff, give this a look. It looks really, really compelling.

That's great. And yes, I did mention that in the newsletter too. It's a great looking package.

My final package for this week is kind of a fun one. I think I am getting a reputation for

maybe making my last package a fun one each week. Maybe that's going to stick.

But it's called AmplifyUILiveness. And it is a wrapper around a Amazon AWS service that can

determine the liveness of a face. Are you looking at a real live human being or are you looking at

a photograph or a simulation of a human being? And it will determine whether, well, it will try

and determine, I don't know how accurate it is, I haven't tried it, but it will attempt to determine

to determine the liveness of the face that you present to it. And so this is actually from,

the package is from AWS Amplify themselves in their organization. And yeah, I just,

I love that idea. I think it's such a, it's a very 2025 problem.

You know what my immediate first thought is, how easy is that going to be to defeat with a photo

and some AI stuff happening on a photo to make it? Well, I think that's the point of it. I think

that's exactly what it is intended to defeat. Oh, really? Okay. Interesting.

And I'm guessing the kind of use for this would be, I know that my bank, every time I need to

log in to my bank's app, if it's somehow found itself, you know, maybe after a major version

upgrade on iOS or something like that, you have to actually record yourself a little selfie video

and send it. And I believe that what they're doing is a human checks it because it's like 15 to 20

minutes before it kind of gets back to you. So I'm guessing that's a human sitting there and

saying, is this the person that is supposed to be? And I'm guessing that this might enable at

least like a pre-check or something like that. I wouldn't want to use something like this for a

positive signal, but it would be great to use this as a negative signal. So this might screen out all

the obviously fake ones or something like that. Yeah. Interesting. Yeah, that's an interesting

package. I hadn't seen that. There we go. I'm going to find the obscure packages every few weeks.

Well, I have no surprise for you because my second pick is also one, apologies again,

I sort of had this on my list as well. And I didn't feel like chucking it because

you mentioned it on our stuff weekly. It's Spices by Simon Støvring.

Do you get all your package recommendations from iOS stuff weekly?

I shall send you messages when I make my picks and make sure that they happen before you publish.

So what was the package? Sorry.

The package was Spices by Simon Støvring. And that's a, as you know, a lovely library to create

debug views and menus from a spec for your app. It's iOS only, I believe. And essentially what

you do, you annotate a Spice store entity with @Spice attributes, like the properties on it.

And then effectively, that's it. That's all you do. Off you go. And it generates a whole view,

a debug view that you can bring up in one way or another. Typically people do it with a shake or

secret gesture or something like a three finger tap, whatever you do. And then you get a really

nice rendering of all the settings that you've added to this Spice store, like Boolean flags or

pop-ups, which API service you might want to connect to, like a QA environment or a staging

environment, that sort of stuff. Stuff that's typically in dev settings for a device.

And have a look at the readme. It has a great little video showing how easy it is to get up

and running with this. And I think it's also a great use of a third party library in this context.

You know, we often talk about when would you use something or how careful do you have to be with

bringing in dependencies? And I think this is a super low risk thing to do because push comes to

shove. Your product release would not depend on this, right? Because it's a pure testing tool.

Obviously it might be an important testing tool, but it's probably not a show-stopping testing

tool if something were to go wrong with this, or for some reason a new Xcode version had troubles

with it and you wouldn't be able to build with it and you had to take it out. That wouldn't be

breaking your bill. So I always like it when dependencies come in that way and give you this

escape hatch of, well, if everything goes pear-shaped, you can at least not use it and

still have a product that you can release. I think in that sense that's a fantastic library to use

and make your dev environment nicer very easily because it's super simple to use.

That sounds great.

Yeah. So there you go. Spices by Simon Støvring.

Fantastic. And we'll call it there, I think. So we will be back in a couple of weeks, well,

a few weeks, with more package recommendations and more news from the world of Swift and Swift

packages. But until then, I think we will see you next time.

See you next time. Bye-bye.

All right. Bye-bye.