Join us as we chat about the Swift team joining Bluesky and Mastodon, data race safety numbers on Swift Package Index Package pages, Swift on Raspberry Pi, and of course our usual package picks!
News
News
- Swiftlang: Social media expansion to Mastodon and Bluesky
- Leverage by Matt Massicotte
- Issue: Ready for Swift 6 false positives
- Issue: False positives reported in Sema.NumSwift6Errors via -stats-output-dir
- https://swifttoolkit.dev/posts/r-pi by Natan Rolnik, assisted by Jesse Zamora
Packages
Creators & Guests
What is Swift Package Indexing?
Join Dave and Sven, the creators of the Swift Package Index open-source project, as they talk about progress on the project and discuss a new set of community package recommendations every episode.
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.