1
00:00:00,001 --> 00:00:02,320
Did you enjoy WWDC?

2
00:00:02,320 --> 00:00:04,960
Oh, I did. Yeah, it was nice.

3
00:00:04,960 --> 00:00:11,120
It didn't last long because it got really busy when the Xcode public beta dropped

4
00:00:11,120 --> 00:00:15,040
because we were in a hurry to get started with the processing.

5
00:00:15,040 --> 00:00:22,400
So I stayed up to watch the State of the Union.

6
00:00:22,400 --> 00:00:27,920
And I think at the same time the beta came out or something like that,

7
00:00:27,920 --> 00:00:33,120
so I knew I was sort of on the fence whether I should start on it in the middle of the night,

8
00:00:33,120 --> 00:00:37,840
but then I decided against it. So it was a Tuesday morning start instead.

9
00:00:37,840 --> 00:00:43,680
So that sort of pushed everything towards the end of the week because we had some minor troubles

10
00:00:43,680 --> 00:00:48,800
getting up and running with the beta. But yeah, it was a bizarre week.

11
00:00:48,800 --> 00:00:52,640
There was the news on the one hand and then the busy period straight after.

12
00:00:52,640 --> 00:00:55,360
So it wasn't like a normal week, really.

13
00:00:55,360 --> 00:00:56,420
Sure.

14
00:00:57,760 --> 00:00:58,320
How about you?

15
00:00:58,320 --> 00:01:03,200
I think for me it was the best State of the Union ever, wasn't it?

16
00:01:03,200 --> 00:01:08,240
It was really nice.

17
00:01:08,240 --> 00:01:14,480
I'm referring, of course, to the fact that we got a call out from Ted Kramanek in the

18
00:01:14,480 --> 00:01:20,880
State of the Union, which is a huge honor and something that we absolutely didn't

19
00:01:22,160 --> 00:01:27,920
expect or assume that we would get. But it's a lovely thing to be mentioned in that session.

20
00:01:27,920 --> 00:01:31,520
Truly one of life's goals.

21
00:01:31,520 --> 00:01:41,840
So yes, it was really nice to see Ready for Special 6 get a mention.

22
00:01:41,840 --> 00:01:47,840
And that's what Sven was talking about when he was talking about getting the builds

23
00:01:48,640 --> 00:01:53,600
going on Tuesday morning. So I think it was actually, didn't we have a slight issue with

24
00:01:53,600 --> 00:01:58,080
one of the parameters changing so that we couldn't actually kick it off until Tuesday

25
00:01:58,080 --> 00:02:06,400
evening? But apart from that, the processing has gone extremely smoothly and we finished up

26
00:02:06,400 --> 00:02:15,440
all Swift 6 builds using Xcode 16 beta 1 yesterday. And just about an hour ago,

27
00:02:15,440 --> 00:02:20,000
before we recorded this podcast, those results are now live on the site.

28
00:02:20,000 --> 00:02:27,280
And I was kind of curious as to what these results, what this version of the results

29
00:02:27,280 --> 00:02:35,920
would look like, because up until now, we've been using Swift 6 nightly toolchains in Xcode 15.3

30
00:02:35,920 --> 00:02:46,080
and 15.4 so far. And then when Xcode 16 comes along, the SDKs have now also been updated

31
00:02:46,080 --> 00:02:54,000
to have sendable conformance in some places and just to the SDKs will be expecting Swift 6

32
00:02:54,000 --> 00:03:00,400
and the compiler is now a default Swift 6 as well. So I was very curious as to whether we'd see

33
00:03:01,200 --> 00:03:10,320
a significant jump up or down in compatibility numbers. The results are in and the amazing news

34
00:03:10,320 --> 00:03:18,240
is it's actually a very consistent increase in compatibility or data race safety between

35
00:03:18,240 --> 00:03:24,640
the last 15.4 build that we did and this 16 build that we did. So we increased from,

36
00:03:26,000 --> 00:03:38,320
excuse me, we increased from 1,359 packages that have zero data race safety errors to 1,477. So

37
00:03:38,320 --> 00:03:45,120
that's quite a large number of packages, well over 100 packages increase. But if you look at the slope

38
00:03:45,120 --> 00:03:52,000
is a fairly consistent slope from previously. So it's just rising. People are doing the work to

39
00:03:52,960 --> 00:03:58,320
get their packages compatible. The compiler is improving with more checks and less warnings

40
00:03:58,320 --> 00:04:03,760
where it doesn't need them. And everything seems to be going in the right direction.

41
00:04:03,760 --> 00:04:12,880
And actually I did a little calculation that this is almost 45% of all packages that are

42
00:04:12,880 --> 00:04:19,520
free from data race safety errors, which is kind of amazing given where we are.

43
00:04:19,520 --> 00:04:24,400
- Of the ones we're testing we should add, right? That's towards the baseline.

44
00:04:24,400 --> 00:04:25,200
- Of the ones that we're testing.

45
00:04:25,200 --> 00:04:29,360
- Yeah. It's maybe worth calling out at this point because I was actually briefly confused

46
00:04:29,360 --> 00:04:38,480
when I looked at the, when we added the totals. We track 7,500-ish packages in total, but the ones

47
00:04:38,480 --> 00:04:43,760
we're showing in these graphs, we are running tests for all packages. So on the individual

48
00:04:43,760 --> 00:04:49,200
package pages, you will see, we'll be able to see the numbers, but in these graphs, we're only

49
00:04:49,200 --> 00:04:55,440
showing recently updated packages. So that's why the total number is 3,500, because those are the

50
00:04:55,440 --> 00:05:01,440
ones that have been sort of seen activity in the last, I think, what's the, is it a half year that

51
00:05:01,440 --> 00:05:05,120
we picked as a timeframe? - I think it was a year, modified

52
00:05:05,120 --> 00:05:13,920
within a year. - Yeah. And the reason to do that was to make sure that we sort of look at actively

53
00:05:13,920 --> 00:05:19,920
maintained packages, because when you want to look at trends, we wanted to have a set of packages

54
00:05:19,920 --> 00:05:28,480
that are reasonably likely to be currently updated, so they could actually see reaction to any of this.

55
00:05:28,480 --> 00:05:35,520
- The one number that did spike though was the, so on our second chart on that page,

56
00:05:35,520 --> 00:05:42,080
is the number of data race safety errors in total. So that's every package that we're testing,

57
00:05:42,080 --> 00:05:46,560
just count up the number of data race safety errors that it got and add it, add them all

58
00:05:46,560 --> 00:05:53,920
together. So you just get this huge number of total errors. And that spiked quite significantly

59
00:05:53,920 --> 00:06:01,120
up from 53,000 errors with the last run to over 61,000 errors with this run, which

60
00:06:01,120 --> 00:06:08,400
I'm not entirely sure of the reason for this, but I'm guessing there are, this is related to

61
00:06:08,400 --> 00:06:15,200
warnings that are coming in through the SDKs that need fixing in people's use of those SDKs.

62
00:06:15,200 --> 00:06:22,160
That would be my guess. - Yeah, I tried to have a look, but it was just too close to the recording.

63
00:06:22,160 --> 00:06:28,240
And what I've seen, so I looked at the SSWG packages and the Apple package list,

64
00:06:28,240 --> 00:06:32,880
because they are just smaller, so it's easier to compare package by package. And I've seen

65
00:06:32,880 --> 00:06:39,440
a general trend of warnings going down in individual packages, and then a couple of packages

66
00:06:39,440 --> 00:06:47,360
have huge spikes. And I can only guess that something's tripping up in these packages,

67
00:06:47,360 --> 00:06:53,680
or they hit certain scenarios where they suddenly get, like I've seen these jump by 100 warnings,

68
00:06:53,680 --> 00:07:01,440
and that took their total up when in general, the trend was to go down. And that's the problem with

69
00:07:01,440 --> 00:07:08,400
looking at these aggregates, right? You're going to, the distribution isn't equal, so you get these

70
00:07:08,400 --> 00:07:15,920
weird trends. It'll be interesting to maybe look at a couple of packages individually to see

71
00:07:15,920 --> 00:07:23,280
what the reason is there. We should maybe also briefly mention how we actually count, because

72
00:07:23,280 --> 00:07:30,000
that's also probably worth taking into account. So when we say a package is-

73
00:07:30,000 --> 00:07:35,280
- What's the famous phrase? It's the lies, damn lies and statistics, right?

74
00:07:35,280 --> 00:07:44,640
- Exactly, yeah. And because what we do is we run builds across all the platforms, right? We try to

75
00:07:44,640 --> 00:07:49,600
build a package for each platform. And then the question is, well, which errors do you count?

76
00:07:49,600 --> 00:07:56,800
And what does it mean a package is free from data race errors for every platform?

77
00:07:57,920 --> 00:08:03,600
And that's not what we do. So we say, and that can be argued, and that's just something we came

78
00:08:03,600 --> 00:08:13,200
up with for now. If any platform build has no Swift 6 concurrency errors, then it is free from

79
00:08:13,200 --> 00:08:20,080
data race errors. So that's not perfect, but we have to settle somewhere. And this is the decision

80
00:08:20,080 --> 00:08:25,840
we made. If there's one platform where you succeed, then that gives you the, in the top chart,

81
00:08:25,840 --> 00:08:31,760
that gives you an entry. On the lower chart, when we look at the errors, we didn't want to sum up

82
00:08:31,760 --> 00:08:41,200
the errors across platforms because it's just, I don't know, it feels weird. We pick the maximum

83
00:08:41,200 --> 00:08:45,760
of all the errors per platform. So you're sort of judged by your worst platform there.

84
00:08:45,760 --> 00:08:55,520
And underlying all this, the build has to actually succeed to report back a count. So you don't need

85
00:08:55,520 --> 00:09:00,640
to worry that if your package is broken on a platform, that this would impact this number.

86
00:09:00,640 --> 00:09:07,200
In order for the Swift compiler to actually report back the Swift 6 error count, the build

87
00:09:07,200 --> 00:09:12,480
has to succeed. So all these builds are actually, all these numbers are based on succeeding builds.

88
00:09:12,480 --> 00:09:17,600
And I hope that makes sense. If you have any comments around that and suggestions how to

89
00:09:17,600 --> 00:09:25,440
maybe derive those numbers in different ways, let us know. That's what we came up with for now.

90
00:09:26,400 --> 00:09:30,880
So what you're saying is that if I wanted my package to pass all the tests, I could just

91
00:09:30,880 --> 00:09:36,560
take all the concurrency out of one platform. Exactly. Make your users happy.

92
00:09:36,560 --> 00:09:45,120
It's got zero data race errors, but it is terribly slow and hangs the main thread all the time.

93
00:09:45,120 --> 00:09:55,280
Great. There have also been some changes to the page itself. I've been making

94
00:09:55,280 --> 00:10:02,080
some changes to the charts. So as Sven mentioned, you can now see the totals on the chart. And this

95
00:10:02,080 --> 00:10:07,920
is actually from some feedback that we received. And it was great feedback, and I'm not sure why

96
00:10:07,920 --> 00:10:13,600
we didn't see this problem before we implemented this, but we have three different lines on each

97
00:10:13,600 --> 00:10:19,680
of the charts and they all have different totals. And we don't show or say the totals anywhere on

98
00:10:19,680 --> 00:10:30,880
the page, which is less than ideal. So we now show the totals. So there is a thin line across

99
00:10:30,880 --> 00:10:35,920
each chart in the color of the plot, and that shows the total. And you can also show and hide

100
00:10:35,920 --> 00:10:40,400
those as well if you want to go back to the old incorrect graphs or misleading graphs.

101
00:10:40,400 --> 00:10:47,280
So you can actually see kind of where we're heading now, how far are we? And you can see

102
00:10:47,280 --> 00:10:52,880
that kind of 45% is much more obvious when you can see that total line. We also have

103
00:10:52,880 --> 00:10:59,760
vertical lines on the charts now as well. So we can add events and there's an event that we've

104
00:10:59,760 --> 00:11:07,760
added, which is the release date of the Xcode 16 beta one. And then you can see like a week later,

105
00:11:07,760 --> 00:11:13,760
we have our next data point. So we've got some tweaks in there to the charts. We've also got

106
00:11:13,760 --> 00:11:17,920
some tweaks in there to the frequently asked questions. Everything now should be kind of

107
00:11:17,920 --> 00:11:26,000
up to date and ready to read. So I can't wait to see how this progresses throughout the summer.

108
00:11:26,000 --> 00:11:34,000
- Yeah, let's hope the trend, well, at least the zero data races, package trend continues and the

109
00:11:34,000 --> 00:11:39,520
other hopefully reverts back and goes back down because it was trending down nicely, the error

110
00:11:39,520 --> 00:11:46,000
account before, but let's see how it goes. - Yes, I don't think we'll see another event like this

111
00:11:46,000 --> 00:11:51,360
unless there is a significant change in the betas, which I'm not expecting.

112
00:11:51,360 --> 00:11:57,200
- Yeah, it'll remain interesting, an interesting race for data race safety.

113
00:11:57,200 --> 00:12:03,760
- Yeah. The last thing that we should talk about with the Swift 6 language mode

114
00:12:04,560 --> 00:12:11,040
stuff is that we have added one more link to the page, which is a link to the Swift 6 language

115
00:12:11,040 --> 00:12:20,160
mode migration guide, which is a document on the swift.org that explains a lot about data

116
00:12:20,160 --> 00:12:27,680
race safety and how you might want to think about migrating your code base, how to obviously the

117
00:12:27,680 --> 00:12:34,400
mechanics of enabling it and opting into Swift 6 language mode. And then some really useful

118
00:12:34,400 --> 00:12:40,640
information about common compiler errors and how to fix them or how to think about the problems

119
00:12:40,640 --> 00:12:48,080
that they are surfacing in your code. - Yeah, and we should also give Matt Mazzicotti a shout out

120
00:12:48,080 --> 00:12:54,560
here, I think because he's helped craft this guide along with Holly Baller. And he's also

121
00:12:54,560 --> 00:12:59,760
written a blog series about concurrency, Swift 6 concurrency, which is really interesting.

122
00:13:00,480 --> 00:13:05,840
And he's been really, really active. - He also was the person who reported the totals missing

123
00:13:05,840 --> 00:13:07,840
from the charts. - He's all over the place.

124
00:13:07,840 --> 00:13:15,120
- We owe almost everything to Matt this week. - Right, so shall we do some packages?

125
00:13:15,120 --> 00:13:20,800
- We certainly should. Yep. I guess it's fairly quiet in terms of news apart from all the Swift

126
00:13:20,800 --> 00:13:26,400
6 stuff. So we'll get to packages a little quicker this week. - Do you want to kick us off?

127
00:13:26,400 --> 00:13:32,080
- Yeah, of course. Yeah. My first package this week is, I love this package so much. I think it's

128
00:13:32,080 --> 00:13:44,960
so clever. It's called Blur Hash Views by Dale Price. And so if you're loading images off the

129
00:13:44,960 --> 00:13:52,080
web to display in your application, and you're not sure of how quick that data connection is going to

130
00:13:52,080 --> 00:13:56,320
be, you're going to want to put some kind of placeholder in. And Swift UI includes a whole

131
00:13:56,320 --> 00:14:03,360
load of methods to include placeholders, kind of standard spinners or loading indicators or

132
00:14:03,360 --> 00:14:07,280
something like that, kind of out of the box. You don't need to worry about it most of the time.

133
00:14:07,280 --> 00:14:14,080
Blur Hash Views implements a technique that is from a website called Blur Hash, which we'll also

134
00:14:14,080 --> 00:14:20,160
include in the show notes. And what it does is it looks at a picture. So this is offline processing

135
00:14:20,160 --> 00:14:26,800
before you get to the actual download. So if you have a set of images that you want to

136
00:14:26,800 --> 00:14:36,720
load into your application, you offline process them so that you get a short blur hash string

137
00:14:36,720 --> 00:14:45,120
to represent that image. And what a blur hash is, is let's say you had a portrait picture of a

138
00:14:45,120 --> 00:14:50,800
person, kind of head and shoulders portrait. If they were standing against like a blue background,

139
00:14:50,800 --> 00:14:56,320
then the edges, the top left and top right corners would both be that blue background.

140
00:14:56,320 --> 00:15:02,960
And then in the middle, you'd maybe have some kind of skin tone colors, and then whatever

141
00:15:02,960 --> 00:15:08,320
they're wearing, you'd see the colors of that in the bottom of the middle. And what it does is it

142
00:15:08,320 --> 00:15:18,240
kind of picks out color areas on the image, gives them RGB values, and then makes a blurred version

143
00:15:18,240 --> 00:15:24,880
with just vague hints of those colors in the right places on the image. And it creates this amazing,

144
00:15:24,880 --> 00:15:31,840
really effective effect of looking like a blurred version of the picture by

145
00:15:33,120 --> 00:15:39,120
representing it as a tiny amount of data. It's kind of 10 characters of data, something like

146
00:15:39,120 --> 00:15:43,840
that to make one of these blur hashes. So if you're in the situation where on your server,

147
00:15:43,840 --> 00:15:48,880
if you can process the image, figure out the blur hash and store that blur hash along with the image

148
00:15:48,880 --> 00:15:55,520
that you're going to be downloading, then that is a fantastic way to give better image previews

149
00:15:55,520 --> 00:16:01,120
to your asynchronous loading image views in any application, SwiftUI or

150
00:16:01,440 --> 00:16:09,120
UIKit or AppKit or any of the platforms, this is going to be completely compatible. So

151
00:16:09,120 --> 00:16:17,600
I really love this package. I think it's such a clever idea. And this is an implementation of that

152
00:16:17,600 --> 00:16:22,880
algorithm that you can use with SwiftUI.

153
00:16:22,880 --> 00:16:30,320
Nice. So what's the data you're getting back? Is that like coordinates, regions, and color codes?

154
00:16:31,040 --> 00:16:37,280
I think the blur hashes, I think they look a little bit like a hex string. Here we go.

155
00:16:37,280 --> 00:16:47,040
No, it's almost like a base64 string. So I'm kind of eyeballing it here, but it looks like about

156
00:16:47,040 --> 00:16:52,560
maybe 25 characters of base64, which is tiny.

157
00:16:52,560 --> 00:16:57,680
Okay. And the package comes with something that knows how to render that in a preview.

158
00:16:57,680 --> 00:16:58,400
Yes, exactly.

159
00:16:59,120 --> 00:17:03,920
Okay. I was thinking, well, how would you actually represent that? I get it. Okay, great.

160
00:17:03,920 --> 00:17:04,720
Ah, okay.

161
00:17:04,720 --> 00:17:11,520
And it recreates the blurs and the regions. And all of this is made possible. So this is taking

162
00:17:11,520 --> 00:17:17,680
advantage straight away of our Swift 6 testing. Although it's not Swift 6 that it needs, but it

163
00:17:17,680 --> 00:17:27,520
needs the new functionality in iOS or MacOS or VisionOS, all the platforms, it supports all the

164
00:17:27,520 --> 00:17:33,200
platforms apart from Linux, but it needs the new functionality, which is mesh gradients. So there's

165
00:17:33,200 --> 00:17:39,840
a new mesh gradient in Swift UI, where you can say, here is my gradient. And at this point,

166
00:17:39,840 --> 00:17:44,880
represent this color, at this point, represent this color, and it will blend those colors between

167
00:17:44,880 --> 00:17:51,840
each other. So it's a lovely implementation of a very clever idea using a brand new piece of

168
00:17:51,840 --> 00:17:58,400
technology in iOS 18 and MacOS. What's it called? Not Sonoma, it's called?

169
00:17:58,400 --> 00:17:58,960
Sequoia.

170
00:17:58,960 --> 00:18:06,800
Sequoia. And of course, all the other platforms as well. I love it. I think it's just such a

171
00:18:06,800 --> 00:18:09,440
great platform. Sorry, such a great package.

172
00:18:09,440 --> 00:18:14,000
Nice. You actually just answered my next question, which was the representation,

173
00:18:14,000 --> 00:18:20,080
if that's gradients and with the mesh, that makes perfect sense. Now I got a way better

174
00:18:20,080 --> 00:18:23,440
picture now how that works. Very nice. That sounds great.

175
00:18:23,440 --> 00:18:26,240
It's a very effective, very effective technique.

176
00:18:26,240 --> 00:18:34,480
Nice. My first pick is a package called Decorative Text Kit by Christian Tietze,

177
00:18:34,480 --> 00:18:41,680
which I found really interesting. So Christian has created a DSL for programmatic text editing.

178
00:18:42,880 --> 00:18:50,320
So, for example, making changes to a text kit buffer without worrying about selection ranges

179
00:18:50,320 --> 00:18:56,320
or insertion point invalidation, that sort of thing. Now I've done very little with Text Kit

180
00:18:56,320 --> 00:19:03,840
itself, but I have an Xcode extension that edits the text, the Xcode text buffer. So I actually

181
00:19:03,840 --> 00:19:09,040
had to fiddle with that. And immediately when I read that line, you don't need to worry about

182
00:19:09,680 --> 00:19:16,960
reordering and selection invalidation. That really sparked my interest in the package because

183
00:19:16,960 --> 00:19:21,200
it's the sort of thing, right, if you edit something at the top and you have selections

184
00:19:21,200 --> 00:19:26,000
further down, you need to either update those regions or you need to go back to front to make

185
00:19:26,000 --> 00:19:32,080
sure you don't invalidate the earlier things that you're messing with. So I found this really

186
00:19:32,080 --> 00:19:38,400
interesting that he's managed somehow to come up with a decorative way of describing your edits

187
00:19:38,400 --> 00:19:46,080
and then let the system sort out how it manages all that stuff, all that headache of indexes and

188
00:19:46,080 --> 00:19:55,520
selection ranges and so on. So I found that really nice. I think it's text kit specific. So in my

189
00:19:55,520 --> 00:20:03,200
case, that wouldn't actually help with my Xcode extension buffers, but I imagine that might be

190
00:20:04,880 --> 00:20:09,440
possibly extended or to work more generally. I don't know. It might be interesting to

191
00:20:09,440 --> 00:20:15,040
see where this goes, but it's a really interesting package if you're using text kit.

192
00:20:15,040 --> 00:20:20,720
I'm so glad you've mentioned this one because I've been reading these blog posts that Christian has

193
00:20:20,720 --> 00:20:26,640
been writing and was never quite sure how to talk about it. So I didn't link to it and I always said

194
00:20:26,640 --> 00:20:31,920
weekly because I wasn't quite sure how to talk about it. So I'm glad you've mentioned it here.

195
00:20:31,920 --> 00:20:43,440
You've saved me a job. You're welcome. My next package is called Swiftly and it is a package by

196
00:20:43,440 --> 00:20:53,040
the new GitHub organization Swiftlang. So this is a, I think it's been around, it was under a

197
00:20:53,040 --> 00:20:58,560
different, I think it was under Swift server before it moved to Swiftlang. Is that right?

198
00:20:58,560 --> 00:21:03,440
Do you know that? It was. Yeah. It was. Yeah. And it's now moved to the new GitHub

199
00:21:03,440 --> 00:21:11,920
organization Swiftlang, the official Swift programming language organization. And this is a

200
00:21:11,920 --> 00:21:18,640
Swift tool chain installer and manager written in Swift. And the reason I think it's probably

201
00:21:18,640 --> 00:21:22,320
worth mentioning at the moment, because this has been around for a little while,

202
00:21:23,280 --> 00:21:30,080
is I'm not sure this is ready for kind of prime time yet, but you may have a better opinion on

203
00:21:30,080 --> 00:21:34,320
this than me Sven, because I think you're a little closer being a member of the Swift

204
00:21:34,320 --> 00:21:39,200
server work group, right? Yeah. And actually when I said at the start, I do in fact have

205
00:21:39,200 --> 00:21:43,360
three packages. It's now reduced to two because that was one of my picks.

206
00:21:46,480 --> 00:21:54,560
Yeah, you're right. I think it's absolutely ready for prime time in the sense that it is

207
00:21:54,560 --> 00:22:01,440
ready for prime time on Linux, which is the first platform it actually targeted. The big drawback

208
00:22:01,440 --> 00:22:07,520
up until recently, well, actually, in fact, it's not supporting macOS just yet, but there's a

209
00:22:07,520 --> 00:22:12,480
pull request open to add it. So that should land very soon, which is the reason I

210
00:22:13,600 --> 00:22:18,720
picked this again. I actually had picked it before, but I think it's really worth calling

211
00:22:18,720 --> 00:22:25,680
out again, because it's been actually also mentioned a couple of times, I believe, at WWDC.

212
00:22:25,680 --> 00:22:34,240
And because it's going to add macOS support really soon. And then it's really, I think it's going to

213
00:22:34,240 --> 00:22:39,840
become the tool to do, especially things like we've been doing, like installing nightlies.

214
00:22:39,840 --> 00:22:45,760
That's going to be much easier. And all that stuff. Sorry, but I didn't mean to hijack your

215
00:22:45,760 --> 00:22:51,280
package. No, no. I think if we share a recommendation, we should share the description

216
00:22:51,280 --> 00:22:57,760
of it. The other reason I mentioned it is that this is truly a collaboration between the work

217
00:22:57,760 --> 00:23:01,120
groups as well, because one of the reasons I wanted to talk about it was we've been doing

218
00:23:01,120 --> 00:23:08,880
some work through the Swift website work group to organize all of the backend data about nightly

219
00:23:08,880 --> 00:23:12,880
Swift versions and where they are and what, you know, all the names of them and the dates and all

220
00:23:12,880 --> 00:23:21,680
the rest of it are all organized through JSON files in the Swift website. So Swift.org repository

221
00:23:21,680 --> 00:23:29,600
on, again, on the Swift, the new Swift lang organization. And so this is a wonderful tool

222
00:23:29,600 --> 00:23:36,560
because it's been developed by, I think, Swift server work group originally. It uses, I think,

223
00:23:36,560 --> 00:23:42,720
the majority of the same people doing their work on the Swift website. But it's a real testament to

224
00:23:42,720 --> 00:23:47,120
how an open source ecosystem kind of comes together to thrive like this. There's nothing

225
00:23:47,120 --> 00:23:52,720
proprietary here. There's nothing that is being used with secret data. This is all just open source.

226
00:23:52,720 --> 00:23:59,040
Open source JSON files, which I am a big fan of. I've used open source JSON files into lots of

227
00:23:59,040 --> 00:24:04,240
projects in my time and Swift package index uses an open source JSON file. I think they're a great

228
00:24:04,240 --> 00:24:13,760
way to get data out there as a quick and easy API. So yeah, this is just a great package. It will be

229
00:24:13,760 --> 00:24:18,880
something that will be useful for a very long time because we'll always have nightly versions of

230
00:24:18,880 --> 00:24:28,400
Swift. And yeah, I'm pleased to see it thriving. Yeah. And by these JSON files, you are referring

231
00:24:28,400 --> 00:24:38,800
to the metadata that Swiftly is using to discover Swift. Yeah, exactly. It's worth calling out

232
00:24:38,800 --> 00:24:45,760
briefly. So originally Swiftly was developed by Patrick Freed. It's been recently maintained by

233
00:24:45,760 --> 00:24:52,000
Adam Fowler and it's now via its transition into Swift lang, it's going to be actively maintained

234
00:24:52,000 --> 00:24:59,120
by folks at Apple. I believe that's my understanding. I mean, Adam is surely still

235
00:24:59,120 --> 00:25:07,840
going to work on it, but I think he is busy with his other open source packages, one of which I'll

236
00:25:07,840 --> 00:25:14,400
be talking about in a minute. So I think he's actively working to help hand it over. Yes,

237
00:25:14,400 --> 00:25:18,640
I can see that. I should have mentioned that as well. Patrick is by far the biggest committer on

238
00:25:18,640 --> 00:25:26,880
this and has had consistent activity on it for the last year or so and only recently has other

239
00:25:26,880 --> 00:25:33,520
people taking it on. So it's definitely worth a shout out to Patrick for his work on this.

240
00:25:33,520 --> 00:25:43,600
Right. My second, third kind of pick is the package I just alluded to by Adam Fowler. It's

241
00:25:43,600 --> 00:25:54,080
called Hummingbird, which to my surprise, I don't think I have picked before. And I was really

242
00:25:54,080 --> 00:26:00,800
reminded that we should be talking about it because it was also mentioned in a WWDC session.

243
00:26:00,800 --> 00:26:09,760
The session on Swift on servers was actually used to create a little service there. And Hummingbird

244
00:26:09,760 --> 00:26:17,600
is a lightweight, flexible, modern server framework written in Swift. And it's very

245
00:26:17,600 --> 00:26:24,000
imminent that the version two is going to land, which is fully async await. So Adam's been working

246
00:26:24,000 --> 00:26:31,360
on a big rewrite on this and this should come live very soon. It's actually also, I should

247
00:26:31,360 --> 00:26:37,760
mention this, it's going to be demoed in the upcoming Swift on server workgroup meetup,

248
00:26:37,760 --> 00:26:43,760
which is going to happen in, I think, in a week's time. Let me just quickly verify this.

249
00:26:43,760 --> 00:26:53,760
It is going to be happening next Thursday. No, sorry, next Wednesday, June the 26th.

250
00:26:53,760 --> 00:26:59,280
And we'll have a link in the show notes there as well, where Adam and Johannes will be

251
00:26:59,280 --> 00:27:06,480
demoing Hummingbird. If you are confused what Hummingbird, how Hummingbird is different than

252
00:27:06,480 --> 00:27:10,480
Vapor, I think, and if you know Python, otherwise this might not be helpful, but

253
00:27:10,480 --> 00:27:18,000
my sort of mental map is Hummingbird is sort of the flask, is a core framework with some specific

254
00:27:18,000 --> 00:27:23,680
extensions that you can pull in to do more stuff. So it's leaner off the bat, has fewer dependencies

255
00:27:23,680 --> 00:27:28,880
to start with, and then you pull in other things. And Vapor is sort of the Django that comes with

256
00:27:28,880 --> 00:27:36,320
everything included and you have pretty much everything there at the start and you're ready

257
00:27:36,320 --> 00:27:42,160
to go. So that might be, if you're undecided which one to pick, if you're just starting out

258
00:27:42,160 --> 00:27:47,520
with Swift on server, that might be worth considering. - And because we're an equal

259
00:27:47,520 --> 00:27:51,920
opportunities podcast, if you're a Ruby person, that would be the difference between Rails and

260
00:27:51,920 --> 00:28:01,760
Sinatra. - There you go. Excellent. - Do we know what it would be in JavaScript? - I do not know.

261
00:28:03,040 --> 00:28:09,760
I don't know. My server-side frameworks and JavaScript knowledge is limited. - No, I've

262
00:28:09,760 --> 00:28:17,680
never actually used one. I've done Python a fair bit and some Ruby way back, but... And I hadn't

263
00:28:17,680 --> 00:28:23,760
heard of... What is it called? Sinatra? No, it was something... - Sinatra, yeah, is a lightweight

264
00:28:23,760 --> 00:28:31,360
version of... And again, you can bring modules in to bulk it up, you know. - Yeah. Nice. So there

265
00:28:31,360 --> 00:28:39,840
you go. That's Hummingbird by Adam Fowler. - Wonderful. My final package for this week is

266
00:28:39,840 --> 00:28:49,760
called Contrast Kit by Mark Battistella. And Contrast Kit is a library that helps you deal

267
00:28:49,760 --> 00:28:55,920
with color contrast between foregrounds and background colors with a specific focus on

268
00:28:56,960 --> 00:29:03,040
keeping your text accessible no matter what base color you're going to be using. So

269
00:29:03,040 --> 00:29:12,720
there is a point at which white text on certain colors looks better than dark text on certain

270
00:29:12,720 --> 00:29:18,480
colors. So as the brightness of a color increases, there will be some kind of point where it flips

271
00:29:18,480 --> 00:29:23,600
from being more readable with white text on top to more readable with dark text on top.

272
00:29:25,040 --> 00:29:32,640
And I remember learning about this years ago now, that that point is not just 50% of the way

273
00:29:32,640 --> 00:29:39,040
through the brightness scale. Your first instinct might be to say, well, if it's more than 50%

274
00:29:39,040 --> 00:29:46,320
brightness, then it's dark. If it's less than, it's light. But it's not that. There is a calculation

275
00:29:46,320 --> 00:29:52,240
that you can do to figure out when that point occurs. And of course, if you're

276
00:29:53,760 --> 00:29:59,280
hovering around that point, nothing's going to be particularly legible because if it's right on the

277
00:29:59,280 --> 00:30:06,720
cusp of being one or the other, then neither are probably very good. But what this package does

278
00:30:06,720 --> 00:30:15,520
is it takes all of that out of your hands and it says you can get any color. And then there are two

279
00:30:16,480 --> 00:30:23,680
methods that I'm just looking up the names of now. There are two methods.

280
00:30:23,680 --> 00:30:32,800
One is called highest rated contrast level. And the other is called double A large contrast level.

281
00:30:32,800 --> 00:30:40,400
And they are different levels of contrast. So highest rated would be, give me the best color

282
00:30:40,400 --> 00:30:44,880
that you can get that is going to be most accessible on whatever this background color is.

283
00:30:44,880 --> 00:30:53,360
You can also lighten or darken any color by a certain shade. So you can kind of go through

284
00:30:53,360 --> 00:31:00,880
from an almost white version of any color to an almost black version of any color in gradations

285
00:31:00,880 --> 00:31:10,720
of kind of 5% of the color spectrum, which is just a really useful package. And especially

286
00:31:10,720 --> 00:31:15,120
to just be able to say, well, it doesn't matter what background color this is. I know that my

287
00:31:15,120 --> 00:31:20,800
text is going to be accessible if I use this package. - Nice. That sounds really useful.

288
00:31:20,800 --> 00:31:27,920
- Works on all the platforms, supports Swift 6, and it is safe from data races.

289
00:31:27,920 --> 00:31:33,360
- Nice. We've got a new call out. - Actually, I'm not sure we actually,

290
00:31:33,360 --> 00:31:39,840
yeah, I'm not sure we actually mentioned that. We've talked a lot about the Ready for Swift 6 page.

291
00:31:40,560 --> 00:31:47,680
But we've also gone live this morning with a feature that on package pages, there is now an

292
00:31:47,680 --> 00:31:53,120
additional piece of metadata, which is whether this package that you're looking at is or is not

293
00:31:53,120 --> 00:32:00,240
safe from data races. So that's just above the keywords on the package metadata section of the

294
00:32:00,240 --> 00:32:07,120
page. And you'll see a little checkered flag, which I must admit, I'm quite pleased with how

295
00:32:07,120 --> 00:32:13,200
that icon came out. I drew that from scratch and it came out much better than I expected it to.

296
00:32:13,200 --> 00:32:18,320
- Yeah, I love that. I love that little flag. Yeah, that's a great shout out. I'd completely

297
00:32:18,320 --> 00:32:23,280
forgotten about that because that's probably a thing as a package author, you want to know, right,

298
00:32:23,280 --> 00:32:30,720
where do I land in that plot? And this is where you can see. If you hover over the thing,

299
00:32:30,720 --> 00:32:36,560
you actually see the error count. We don't have, at the moment, we don't have a better way of giving

300
00:32:36,560 --> 00:32:44,000
you more detail. We might be adding that in perhaps the build details page at some point,

301
00:32:44,000 --> 00:32:49,440
but for now, that's where you can check what the error count is for your package.

302
00:32:49,440 --> 00:32:54,800
- And I think I would guess the reason that this is safe from data races is it has no concurrency.

303
00:32:54,800 --> 00:32:58,080
I can't imagine why this would need concurrency.

304
00:32:58,080 --> 00:32:59,840
- That's an easy way to get there.

305
00:32:59,840 --> 00:33:06,000
- That is the easiest way. It's my trick that I mentioned earlier, just take all the concurrency

306
00:33:06,000 --> 00:33:08,960
out. It's easy. - Or just put it all on main actor.

307
00:33:08,960 --> 00:33:12,560
- I don't know what all the fuss is about. - There you go.

308
00:33:12,560 --> 00:33:23,040
- Right. And with that, I think we'll wrap it up here, call it an episode, and we will be back

309
00:33:23,040 --> 00:33:27,040
in a couple of weeks or a few weeks with another one. We'll do it all again.

310
00:33:27,040 --> 00:33:32,240
So until then, I will see you in a few weeks. - See you then. Bye-bye.

311
00:33:32,240 --> 00:33:33,040
- Bye.