1
00:00:00,001 --> 00:00:06,880
I think the first thing I want to mention in this episode is I booked my ticket to the

2
00:00:06,880 --> 00:00:10,080
Server-Side Swift conference. Did you book a ticket?

3
00:00:10,080 --> 00:00:14,480
I did in fact book it. I booked the ticket, booked the hotel. The only thing I haven't

4
00:00:14,480 --> 00:00:20,160
booked yet is the flight. So looks like we'll finally meet. Fingers crossed.

5
00:00:20,160 --> 00:00:25,840
You're well ahead of me then because I haven't yet booked the hotel, but I do have a ticket.

6
00:00:28,000 --> 00:00:31,680
And yes, it will be nice to both be in the same place at the same time because

7
00:00:31,680 --> 00:00:37,520
you went last year and unfortunately I was not so well last year when the conference was on,

8
00:00:37,520 --> 00:00:42,080
and so I couldn't attend. And then the year before I was there, but you couldn't attend

9
00:00:42,080 --> 00:00:52,320
the year before. So we've nearly met at the conference twice now, but this year, this is the

10
00:00:52,320 --> 00:00:54,480
one. This is the one, exactly.

11
00:00:54,480 --> 00:00:55,600
Only took us five years.

12
00:00:56,160 --> 00:01:03,440
It only took us five years, exactly. But just for anyone who is interested, it's worth mentioning

13
00:01:03,440 --> 00:01:09,440
the details of the conference. Early bird tickets are still available. And if you have any interest

14
00:01:09,440 --> 00:01:14,880
in Server-Side Swift, which if you're listening to this podcast, you probably do, then the

15
00:01:14,880 --> 00:01:21,760
Server-Side Swift conference is 2nd to the 3rd of October, 2025 in London. And like I say, early

16
00:01:21,760 --> 00:01:28,400
bird tickets are still available. There's no speakers or schedule up yet. In fact, I think

17
00:01:28,400 --> 00:01:35,040
there's still an active CFP for the conference. So maybe you could even speak at the conference

18
00:01:35,040 --> 00:01:44,400
if you're listening to this. Yes, the CFP still appears to be open until June the 30th. There we

19
00:01:44,400 --> 00:01:49,200
go. So you may, if you have something interesting to talk about at the conference, submit yourself

20
00:01:49,200 --> 00:01:55,920
a CFP, but if not, then consider a ticket if you've interest in Server-Side Swift.

21
00:01:55,920 --> 00:02:02,320
Yeah. And if you're, as Dave said, if you're interested in Server-Side Swift development at

22
00:02:02,320 --> 00:02:06,240
all, just get a ticket. You don't need to wait for the speaker list because the speakers will

23
00:02:06,240 --> 00:02:14,000
be great. It was a great conference last year and the talks are, you know, they're certainly

24
00:02:14,000 --> 00:02:17,760
very important, but also everything around the conference is really great. There's a lot of

25
00:02:18,400 --> 00:02:24,720
time to catch up, socialize, meet people. I found it really great. Lots of people I'd only

26
00:02:24,720 --> 00:02:31,600
interacted with online that I had a chance to meet last year. And the few that I didn't

27
00:02:31,600 --> 00:02:40,080
manage to bump in, I hope to run into this year. And yeah, same for everyone else. I think it's a

28
00:02:40,080 --> 00:02:44,560
great venue too. We should mention this is happening at the Science Museum in London.

29
00:02:45,600 --> 00:02:51,760
So even if you don't want to talk to anyone at all, you can just roam the halls and look at the

30
00:02:51,760 --> 00:02:57,360
Lunar Lander and stuff like that. Look at old airplanes and stuff, but you should talk to people.

31
00:02:57,360 --> 00:03:03,200
Yes, you should. It's definitely, that's the best bit of any conference. The year before last,

32
00:03:03,200 --> 00:03:10,480
I actually did a small presentation at that conference and the venue is fantastic. Of course,

33
00:03:10,480 --> 00:03:18,000
the Science Museum is wonderful, but it was in the, or at the time when it was two years ago,

34
00:03:18,000 --> 00:03:24,240
it was in the IMAX theater there. And so my slides were projected onto an IMAX screen,

35
00:03:24,240 --> 00:03:27,120
which is the first time I've ever had that happen. So that was fantastic.

36
00:03:27,120 --> 00:03:30,960
Yeah, it's a great venue.

37
00:03:30,960 --> 00:03:34,880
You don't really know what big fonts are until you've had them projected on an IMAX screen.

38
00:03:40,240 --> 00:03:43,200
So that's that. I think there's also a couple of little bits of news from

39
00:03:43,200 --> 00:03:52,720
the project over the last couple of weeks. First of all, we shipped two new compatibility platforms

40
00:03:52,720 --> 00:03:58,720
for our compatibility matrix on every package page. So there was a blog post and we'll link

41
00:03:58,720 --> 00:04:07,280
the blog post in the show notes, but we have added both Wasm and Android to all of our

42
00:04:07,280 --> 00:04:15,120
compatibility checks. And it's been kind of interesting to see the results of those platforms.

43
00:04:15,120 --> 00:04:21,840
They are significantly more compatible already than you might expect. Now, obviously,

44
00:04:21,840 --> 00:04:30,960
whenever you have a package that relies on any of the kind of Apple specific platform UI kit,

45
00:04:30,960 --> 00:04:36,240
Swift UI, AppKit, any of those kinds of things, you're automatically going to fail compatibility

46
00:04:36,240 --> 00:04:44,000
with both Linux and Wasm and Android. But actually, I was pleasantly surprised to see that

47
00:04:44,000 --> 00:04:53,120
almost 19% of packages are already compatible with Wasm and almost 28% are compatible with

48
00:04:53,120 --> 00:04:55,440
Android already, which is kind of remarkable.

49
00:04:55,440 --> 00:05:03,680
Yeah, it's great to have those platforms in. It was really surprisingly easy to actually add them

50
00:05:03,680 --> 00:05:10,320
thanks to the Swift cross-compile efforts. So there's a... I think this was introduced with

51
00:05:10,320 --> 00:05:21,440
6.0, like the SDK support. And now with Swift 6.1, Android came on board as well. And it's really

52
00:05:21,440 --> 00:05:28,320
like you install these SDKs alongside your tool chain and that allows you to compile to the target

53
00:05:28,320 --> 00:05:34,240
platform. So I think what effectively it does is sort of the SDK is a bundle of artifacts you need

54
00:05:34,240 --> 00:05:39,920
to cross-compile like headers and additional libraries and stuff. And then you can run on

55
00:05:39,920 --> 00:05:44,720
your host platform and compile to the target platform. And because we've already been running

56
00:05:44,720 --> 00:05:50,960
Linux builds, it really meant just creating almost like a variant of the Linux build in both cases,

57
00:05:50,960 --> 00:05:57,200
because the builders are Linux-based in those cases, and you install the additional SDKs and

58
00:05:57,200 --> 00:06:05,440
you just compile to Wasm and Android. And yeah, it took some testing and stuff, but it was easy to

59
00:06:05,440 --> 00:06:14,160
add. And like every year, I just hope that at some point we'll even get to something similarly easy

60
00:06:14,160 --> 00:06:21,040
with the Apple platforms, because we still have to wrestle whole Mac virtual machines for all of

61
00:06:21,040 --> 00:06:26,880
those platforms. If those SDKs also had something like that, that would be amazing and make it much

62
00:06:26,880 --> 00:06:34,080
easier to run these compatibility builds across the board. The big one, of course, that's still

63
00:06:34,080 --> 00:06:42,400
missing is Windows. And that is something that we would both love to have on that compatibility

64
00:06:42,400 --> 00:06:49,760
matrix, which would take our number of platforms from eight to nine. But we do still have a couple

65
00:06:49,760 --> 00:06:57,760
of technical issues. The software that we've built to run the builds that we use for compatibility

66
00:06:57,760 --> 00:07:05,440
testing has a couple of dependencies that are not yet compatible with Windows. And so that would be

67
00:07:05,440 --> 00:07:13,440
quite a lot of work to work around those dependencies. But also, we would need to flesh

68
00:07:13,440 --> 00:07:19,280
out an entire Windows build infrastructure, which is something we don't have. And unfortunately,

69
00:07:19,280 --> 00:07:27,680
we're on the verge of losing our Microsoft Azure sponsorship. So it's also not something that we're

70
00:07:27,680 --> 00:07:33,600
able to kind of put a whole load more resources behind in terms of that build infrastructure

71
00:07:33,600 --> 00:07:39,200
right now. So it's definitely on our minds. We'd love to do it, but it's not in our short-term

72
00:07:39,200 --> 00:07:44,240
future, I don't think. Yeah. Yeah. Unfortunately not. It's interesting how often it actually comes

73
00:07:44,240 --> 00:07:50,880
up. Windows support is being requested quite frequently. The main dependency we're lacking

74
00:07:50,880 --> 00:08:00,080
is Swift Neo. And I do know that there's interest in actually porting that. I know the Vapor folks

75
00:08:00,080 --> 00:08:03,680
are sort of interested in that as well. They have lots of requests, surprisingly,

76
00:08:03,680 --> 00:08:10,320
for Vapor on Windows. And that's obviously a dependency for them as well. So I'm confident

77
00:08:10,320 --> 00:08:17,840
that'll see changes at some point. It can't be too far off. There's a lot of interest in Windows,

78
00:08:17,840 --> 00:08:22,560
and I think we'll get it sooner rather than later. Fingers crossed.

79
00:08:22,560 --> 00:08:28,160
Yeah, absolutely. And then, so we've actually published two blog posts in the last two weeks,

80
00:08:28,160 --> 00:08:34,960
which the second one was a little celebration of our five-year anniversary of the launch of

81
00:08:34,960 --> 00:08:41,440
the Swift Package Index. So we launched just before WWDC 2020, which if you remember,

82
00:08:41,440 --> 00:08:47,360
was actually a little delayed in 2020 because I think there was some global event happening

83
00:08:47,360 --> 00:08:56,480
or something like that, but I forget now. So WWDC was a little delayed, but we launched just before

84
00:08:58,320 --> 00:09:05,920
the conference in 2020. And we published a little blog post with some statistics and some

85
00:09:05,920 --> 00:09:14,080
kind quotes that people gave us about the Package Index with a couple of graphs showing how package

86
00:09:14,080 --> 00:09:20,320
growth has happened over the last five years and how much documentation we host and how many builds

87
00:09:20,320 --> 00:09:28,720
we do and all sorts of stuff. So again, I'll include a link in the show notes to that blog post.

88
00:09:28,720 --> 00:09:34,800
Yeah. Yeah. And on that occasion, thank you to everyone who's supporting and using the project.

89
00:09:34,800 --> 00:09:43,360
It's just amazing to see how much it's grown. We started with, was it 2,500 packages? It's 9,000

90
00:09:43,360 --> 00:09:49,360
now. I mean, of course, it's not a lot if you compare it to other ecosystems, but it's a lot

91
00:09:49,360 --> 00:09:57,040
of growth in those five years, has a lot of really interesting and fun packages and helps. I use it a

92
00:09:57,040 --> 00:10:03,840
lot, actually, the site itself to find stuff and not just because of the Swift Package Index, but

93
00:10:03,840 --> 00:10:10,960
just of work in other aspects of the project itself, but also sometimes when I try stuff,

94
00:10:10,960 --> 00:10:19,680
it's a site I use often. And interestingly for me, use has shifted to looking at the documentation

95
00:10:19,680 --> 00:10:26,960
pages much more. I think if I had to say what I use the site for has dramatically shifted towards

96
00:10:26,960 --> 00:10:31,760
documentation. And I think that that's really a testament to the efforts by the community to

97
00:10:31,760 --> 00:10:38,560
actually add documentation to their packages. I'm constantly amazed how high the ratio is of

98
00:10:38,560 --> 00:10:43,200
new packages that are being added with documentation opt-in and the quality of

99
00:10:43,200 --> 00:10:48,880
the documentation in particular. There's lots of packages that have good documentation and some

100
00:10:48,880 --> 00:10:57,120
have amazing documentation with tutorials and migration guides. It's fantastic work being done

101
00:10:57,120 --> 00:11:02,320
there. So yeah, thank you, everyone. Yeah, absolutely. Thank you so much for

102
00:11:03,600 --> 00:11:09,200
not only using it, but the people who also sponsor us through GitHub. That's incredibly

103
00:11:09,200 --> 00:11:19,040
important to this project being as successful and available as it is. So it's been a fantastic

104
00:11:19,040 --> 00:11:27,760
five years of running it. So thank you very much. Here's to the next five. And then some.

105
00:11:28,400 --> 00:11:34,160
Exactly. Yeah, exactly. Yep. All right. I think there's another big thing happening this week.

106
00:11:34,160 --> 00:11:39,520
You just mentioned it like five years ago. Yeah, five years ago, we launched just before

107
00:11:39,520 --> 00:11:48,320
WDC. The actual five year anniversary is probably exactly on the day this podcast episode will come

108
00:11:48,320 --> 00:11:59,200
out, which is in the middle of WWDC 2025. And yeah, we've had an interesting keynote yesterday

109
00:11:59,200 --> 00:12:06,160
on State of the Union, I think. Did you sacrifice any of your devices yet on the beta alter?

110
00:12:06,160 --> 00:12:15,440
Or did you? No, not yet. So we should mention that we're recording this on the Tuesday. So that's,

111
00:12:15,440 --> 00:12:21,680
yeah, as of today, we've only seen the keynote and the State of the Union. Although I did notice

112
00:12:21,680 --> 00:12:29,760
that it appears that every session video has been released yesterday. So I have a feeling.

113
00:12:29,760 --> 00:12:34,320
Yeah, I have a feeling that unlike previous years, whether you a few every day throughout the week,

114
00:12:34,320 --> 00:12:39,840
I think they've just dropped the entire set this year, which is great. But the only ones I've

115
00:12:39,840 --> 00:12:45,840
watched so far are the keynote and the State of the Union. And I haven't yet sacrificed any of

116
00:12:45,840 --> 00:12:54,560
my devices. The only thing I've done so far is install Xcode 26. Yeah, which is, well, actually,

117
00:12:54,560 --> 00:13:00,480
before we move on to what we thought of the thing, I read a blog post today by Daniel Seidey,

118
00:13:01,440 --> 00:13:10,960
who made the case as to why the unified OS versioning is a huge advantage to us as developers.

119
00:13:10,960 --> 00:13:17,920
And it's basically around all the availability checks for things like SwiftUI, where you might

120
00:13:17,920 --> 00:13:22,640
say before you declare a function or before you use a function, you might say when available on

121
00:13:22,640 --> 00:13:30,960
iOS 18, Mac OS 15, TV OS 18, watchOS 11 and Vision OS 2, you now will presumably just be

122
00:13:30,960 --> 00:13:39,920
able to say, yeah, you can now say, please check for OS 26. And that covers everything now, which

123
00:13:39,920 --> 00:13:47,680
I think that's one practical advantage for developers of the naming system changing.

124
00:13:47,680 --> 00:13:51,200
It will take us a little time to get used to that naming system change. But I think

125
00:13:51,200 --> 00:13:58,000
it's a good thing because generally, you do want to, when you're doing those availability checks,

126
00:13:58,000 --> 00:14:04,160
you do want to set everything with every platform at a certain year. So I quite liked that. And I'll

127
00:14:04,160 --> 00:14:09,920
include a link to that blog post in the show notes again. Yeah, no, I think that makes perfect sense,

128
00:14:09,920 --> 00:14:23,280
the change to years. The 2026 is a bit, it's not 2026 yet. I can see how they want to, not when it

129
00:14:23,280 --> 00:14:28,480
probably hits the mainstream, it's going to be 2026. But then I'd argue you should have probably

130
00:14:28,480 --> 00:14:35,680
also called it WWDC 2026, right? No, I think this makes sense to me.

131
00:14:35,680 --> 00:14:44,720
WWDC is very firmly in 2025. But the operating systems 26 don't actually release until September

132
00:14:44,720 --> 00:14:52,880
and October this year, at which point we are much closer to 2026 than we are to 2025. And so I think

133
00:14:52,880 --> 00:15:02,160
it does make sense that the majority of the time that iOS 26 will be available, not in beta, will

134
00:15:02,160 --> 00:15:13,280
be in the year 2026. Yeah, I mean, this is a lot like, you know, $9.99 pricing. It's like, it's

135
00:15:13,280 --> 00:15:19,680
targeting psychology more than anything else. I would have made the same decision given, given,

136
00:15:19,680 --> 00:15:25,840
if it was if it were a June release date, I would probably go with 2025. But given that we get access

137
00:15:25,840 --> 00:15:32,160
to it way in advance of the people who actually going to eventually use it. I think I think it's

138
00:15:32,160 --> 00:15:36,480
the right decision given it's September and October when they normally ship. All right.

139
00:15:36,480 --> 00:15:43,200
All right. I thought the conference was good. Yeah. The State of the Union was interesting.

140
00:15:43,200 --> 00:15:48,160
I actually I didn't quite make it to the State of the Union last night, but I watched it today.

141
00:15:49,520 --> 00:15:55,840
Interesting changes to lots of the frameworks. We've got the new changes to Xcode, which are

142
00:15:55,840 --> 00:16:06,160
good. One that I didn't expect was the Swift Assist feature to be in this year's version. I

143
00:16:06,160 --> 00:16:13,360
thought that might be a little further delayed. And also for it not to rely only on the Apple

144
00:16:14,720 --> 00:16:19,200
model for prediction. And actually it's more than prediction. It is.

145
00:16:19,200 --> 00:16:29,360
It's not quite an agent, but it is a chat that you can have with an LLM about your code that

146
00:16:29,360 --> 00:16:33,680
will also write code for you. But you can go backwards and forwards in that chat. It's

147
00:16:33,680 --> 00:16:39,360
definitely more than code completion. Yeah. And I didn't actually see that called out. Is that

148
00:16:39,360 --> 00:16:44,160
the Swift Assist equivalent? Because I don't think they mentioned Swift Assist.

149
00:16:44,160 --> 00:16:50,400
I think no, I don't think. I think the words Swift Assist were very deliberately not mentioned

150
00:16:50,400 --> 00:17:00,400
yesterday. At least I didn't hear those two words said at all. But from what was previewed as Swift

151
00:17:00,400 --> 00:17:05,920
Assist the year before, this feels like an evolution of what that was.

152
00:17:05,920 --> 00:17:13,360
Yeah. Yeah, definitely. It's great to see that they have the on-device models and stuff and

153
00:17:13,360 --> 00:17:18,480
that you can very easily interface with them. I played around with it a bit. Foundation models,

154
00:17:18,480 --> 00:17:29,840
it's super easy to use. I'd be interested to see the quality of it and what it can actually do.

155
00:17:29,840 --> 00:17:38,160
Again, I just did a trivial thing and it's hard to judge them from just a couple of things. You

156
00:17:38,160 --> 00:17:45,520
really need to gain experience with those to be able to judge them. But you can see how

157
00:17:45,520 --> 00:17:53,440
in the future with more advancements, this is a really interesting and compelling

158
00:17:53,440 --> 00:17:58,240
thing to have that you don't need to reach out. You don't need to fiddle with API keys,

159
00:17:58,240 --> 00:18:03,360
that it runs on device without a network connection, without shipping your data off.

160
00:18:03,360 --> 00:18:09,440
That's just massive benefits. And if it has quality that's in the ballpark, I think

161
00:18:09,440 --> 00:18:14,800
that gives it a lot of weight. Even if it's not maybe the most cutting edge model, I think there's

162
00:18:14,800 --> 00:18:21,760
a case to be made that it's a trade-off you might want to make in those cases. Plus,

163
00:18:21,760 --> 00:18:29,520
you can still do the other thing if you really feel like you need the extra oomph, if it exists.

164
00:18:30,400 --> 00:18:38,160
I'm much more excited about the coding support than the foundation models, just simply because

165
00:18:38,160 --> 00:18:47,440
that's something I've been interested in for a little while in Swift coding and in non-Swift

166
00:18:47,440 --> 00:18:53,440
coding, actually. I did a little experiment at the beginning of... Oh, no, it was the end of last

167
00:18:53,440 --> 00:18:58,640
week, I think, that I did this. Are you familiar with Claude Code?

168
00:18:58,640 --> 00:18:59,920
- Yes.

169
00:18:59,920 --> 00:19:09,040
- Okay. So, Claude Code, if you're not familiar with it, is what they call an agent for writing

170
00:19:09,040 --> 00:19:16,480
code with one of these LLMs, in this case, Claude. And I was curious to try something with it.

171
00:19:19,440 --> 00:19:25,200
So, I actually got it to write me a Swift package this week, and that Swift package, I think,

172
00:19:25,200 --> 00:19:35,920
well, it is in the Swift package index as we speak. And what I did was I spent about an hour

173
00:19:35,920 --> 00:19:44,480
writing and refining with the help of some LLMs to help me do that, writing and refining a

174
00:19:45,840 --> 00:19:55,600
quite detailed specification for the package. And then using a technique that I learned from

175
00:19:55,600 --> 00:20:00,960
Peter Steinberger, who has been doing a lot of work with these agents at the moment,

176
00:20:00,960 --> 00:20:11,040
I found it very interesting to basically pass this specification between two LLMs. So, I took it from

177
00:20:11,040 --> 00:20:16,880
the one LLM and read it and made sure that it was correct and corrected a few things or added a few

178
00:20:16,880 --> 00:20:23,920
things that I wanted this package to do. And then I passed it to another LLM and said, "Please find

179
00:20:23,920 --> 00:20:30,160
me the weaknesses in this specification and ask questions about those weaknesses." And I took the

180
00:20:30,160 --> 00:20:35,920
response of that and also then added some answers to those questions and then passed it back to the

181
00:20:35,920 --> 00:20:43,680
first LLM and said, "Please integrate these changes into the spec." And ended up, after about an hour's

182
00:20:43,680 --> 00:20:50,560
worth of work with what was quite a detailed specification for a Swift package to pass

183
00:20:50,560 --> 00:20:58,160
a markup language called Critic Markup, which is an extension to Markdown where you can

184
00:20:58,160 --> 00:21:05,600
mark additions and insertions and substitutions in written text. So, you can do like a little

185
00:21:05,600 --> 00:21:11,680
brace and then plus plus and then a word and then plus plus and then the closing brace. And it knows

186
00:21:11,680 --> 00:21:16,000
that you want to insert that word into the Markdown document. Think of it a little bit like

187
00:21:16,000 --> 00:21:29,360
track changes in pages, but in a Markdown format. And so, I had it write this spec and then I gave

188
00:21:29,360 --> 00:21:35,040
that spec to Cloud Code. I just said, "Please implement this, including a full test suite,

189
00:21:35,040 --> 00:21:43,040
including DocC documentation, including Markdown files that include examples of DocC documentation,

190
00:21:43,040 --> 00:21:49,920
as well as just the documentation for the structures and classes themselves." And it went

191
00:21:49,920 --> 00:21:58,560
away and thought about it for probably 45 minutes, something like that, and spat out a package.

192
00:21:58,560 --> 00:22:02,800
And if you look at... So, I was actually watching it do its work for most of the time.

193
00:22:02,800 --> 00:22:13,760
And you could see that it was not only building and running the test suite, it was then kind of

194
00:22:13,760 --> 00:22:18,800
refactoring the code it had written for better testability and then writing a test then to test

195
00:22:18,800 --> 00:22:25,680
it and then running the test, make sure they pass, writing documentation. And after 45 minutes,

196
00:22:25,680 --> 00:22:34,400
I had a package that was working, just kind of remarkable that it needed literally no intervention

197
00:22:34,400 --> 00:22:43,200
from me at all. Now, I would want to test that package further. In fact, I hesitated before

198
00:22:43,200 --> 00:22:48,480
adding it to the index because I haven't used that package in Angular, but I have used it in

199
00:22:48,480 --> 00:22:54,080
a little demo application. And of course, the tests are there and the tests do what they say

200
00:22:54,080 --> 00:23:00,160
they will do because there's tests. So, it was very interesting to do that. And so, the reason

201
00:23:00,160 --> 00:23:08,160
I mentioned that is that what has shipped in Xcode 26 is a step towards that, but already,

202
00:23:08,160 --> 00:23:14,560
and this stuff is moving so fast at the moment, that already what was released yesterday is a

203
00:23:14,560 --> 00:23:19,440
little bit behind state of the art because that kind of stuff was a few months ago. And we are

204
00:23:19,440 --> 00:23:27,760
talking like literally just a few months ago, but it makes a real difference for the LLM to be able

205
00:23:27,760 --> 00:23:33,280
to interact with your tools in terms of, I think it's time to run the test now. So, I'm going to

206
00:23:33,280 --> 00:23:38,400
run the tests and I'm going to look at the output from those tests and see if they pass. And then

207
00:23:38,400 --> 00:23:42,400
if they don't pass, I'm going to look at the error message that it gave me and then rewrite the code.

208
00:23:42,400 --> 00:23:51,120
And so, it's a real huge step along that path, which, yeah, I thought it was a very... I wanted

209
00:23:51,120 --> 00:23:56,080
to experiment with it and I felt that was a decent experiment that I came up with.

210
00:23:56,080 --> 00:24:02,560
Yeah. No, it's remarkable the capabilities they've gained. I mean, we've touched on this a

211
00:24:02,560 --> 00:24:09,600
couple of times. We have slightly different points of view on the whole AI stuff, although I think a

212
00:24:09,600 --> 00:24:16,960
lot of it is also aligned. I think it's... Initially, my main complaint was that it doesn't

213
00:24:16,960 --> 00:24:22,160
actually work or didn't seem to work, but I had to revise that a bit. I tried independently. I

214
00:24:22,160 --> 00:24:29,440
tried actually something just before Peter Steinberger came out with his blog posts and

215
00:24:29,440 --> 00:24:36,720
the video about trying this. I had just tried Z, the Z editor has integrated...

216
00:24:36,720 --> 00:24:37,780
Yes.

217
00:24:38,560 --> 00:24:48,960
...Claude thing and I used it to write a script. When we ran the Android and WASM compatibility,

218
00:24:48,960 --> 00:24:56,800
we did a comparison against the skip tools page where they list... They had run a compatibility

219
00:24:56,800 --> 00:25:06,800
test themselves as well. And I wrote a little script to compare their list of results versus

220
00:25:06,800 --> 00:25:12,160
our list of results. And you can imagine writing a script like that is not a big task. And it took me

221
00:25:12,160 --> 00:25:19,440
a little less than 20 minutes to do it and compare the results and verify that it is okay.

222
00:25:19,440 --> 00:25:27,760
And even before I started, I thought maybe that's something I should try, compare how I do versus

223
00:25:27,760 --> 00:25:35,840
how Z with Claude does. And obviously, if I was to do that, I had to do it myself first because

224
00:25:35,840 --> 00:25:40,400
what's the point watching the thing and then it's then harder to do it yourself when you have a

225
00:25:40,400 --> 00:25:45,280
finished thing. But interestingly, once I'd finished writing the script on the same day,

226
00:25:45,280 --> 00:25:51,200
I pulled up Z and then I was looking at the prospect of describing to the thing what I wanted

227
00:25:51,200 --> 00:25:57,840
to do after I'd just done it. And I couldn't even find the energy to start writing a prompt

228
00:25:57,840 --> 00:26:04,720
to tell it what I wanted to do because I had it, I had just done it. So I said, "No, I'm not going

229
00:26:04,720 --> 00:26:08,160
to do this. This is silly." But then the next day I was sort of fresh and I thought, "All right,

230
00:26:08,160 --> 00:26:15,600
let's let's let you know, fresh new day, let's go and do it again." And I honestly, I'll admit,

231
00:26:15,600 --> 00:26:23,040
I didn't think this would actually work at all because from everything I'd seen, these sort of

232
00:26:23,040 --> 00:26:28,720
wander off and do stuff. And like a Swift script, this wasn't even a package. This was a Swift

233
00:26:28,720 --> 00:26:35,680
script. I think I might've turned it into a package. I don't remember. Anyway, it wasn't

234
00:26:35,680 --> 00:26:40,000
a trivial thing. I mean, it wasn't a super complex thing, not anything like what you've done or what

235
00:26:40,000 --> 00:26:46,960
Peter has done. But still, I thought this would be too complicated for this to understand what I want

236
00:26:46,960 --> 00:26:51,440
because there were a couple of things that were kind of tricky. Like the two input formats were

237
00:26:51,440 --> 00:26:57,840
adjacent, but they were different. They weren't structurally the same. Not even, you know, one

238
00:26:57,840 --> 00:27:06,880
was an array, the other was an object with leaf items and stuff like that. So it was more than a

239
00:27:06,880 --> 00:27:13,600
absolutely trivial task. And I didn't think it would manage. And it did manage. And it managed

240
00:27:13,600 --> 00:27:20,480
in a form that was acceptable. I had no complaints. I ran a couple of additional

241
00:27:20,480 --> 00:27:23,360
iterations, told it, "Look, we should refactor this a bit and this a bit."

242
00:27:25,120 --> 00:27:34,560
I was done after 10 minutes. So I was faster with the thing. I think the only thing

243
00:27:34,560 --> 00:27:42,400
where I benefited from having done it before myself was that I caught a couple of edge cases

244
00:27:42,400 --> 00:27:49,040
while I was doing it. And that's the problem I have with these tools. I wonder how much of an

245
00:27:49,040 --> 00:27:57,120
edge you lose thinking about your problem deeply when you're not actually doing it. I noticed when

246
00:27:57,120 --> 00:28:03,040
I ran the results after I manually compared them that the numbers seemed low. And I realized that

247
00:28:03,040 --> 00:28:08,720
the URLs that were compared were actually, they had different casing. And that's a rather trivial

248
00:28:08,720 --> 00:28:13,360
thing to realize and know, but also because we've had this situation in the past. So all of our

249
00:28:13,360 --> 00:28:21,120
comparisons with URLs are always lowercase and then compared for that reason. And so I spotted

250
00:28:21,120 --> 00:28:26,640
that. But I also, I think I spotted that faster because I had actually just written the map and

251
00:28:26,640 --> 00:28:33,840
the comparison. And you are in the vicinity of the issue when you're in that mindset.

252
00:28:33,840 --> 00:28:37,600
I think if I just sit down and, "Oh, I want this compared." And then I look, "Oh, right."

253
00:28:37,600 --> 00:28:42,560
You're more tempted to accept what you get. And I had the same effect with, it's sort of like the

254
00:28:43,440 --> 00:28:48,960
the complaint dialogues. And you start clicking on accept. Like also when it wants to confirm,

255
00:28:48,960 --> 00:28:54,480
"Can I run this tool?" Initially I had it always to confirm. And then at some point you give in

256
00:28:54,480 --> 00:29:00,640
because you have this, your resistance gets worn down. "Why do I always need to accept?" "Yes,

257
00:29:00,640 --> 00:29:04,240
you're just going to run Swift Build again." "Okay." So I click accept. And then at some

258
00:29:04,240 --> 00:29:08,640
point I said, "Well, just run it. Just God damn it. Just leave me alone and run it."

259
00:29:08,640 --> 00:29:19,280
And that's the thing that I fear most with the actual use of the tool is that my vigilance and my

260
00:29:19,280 --> 00:29:27,760
awareness of what I'm actually doing is going to, it's like taking over a self-driving car.

261
00:29:27,760 --> 00:29:32,160
You're never going to be able to take over when actually it gets critical, right? Because you're

262
00:29:32,160 --> 00:29:42,720
not in the system. You have no state of the operation. Like what state is the system in?

263
00:29:42,720 --> 00:29:49,520
Then you're supposed to jump in and take over. And that's what I find so hard. And I feel like

264
00:29:49,520 --> 00:29:56,400
I really fear the losing capabilities and losing ownership and control over the system as a whole.

265
00:29:56,960 --> 00:30:05,760
And I do realize that we've had this before. Every tool sort of removes you a bit from control.

266
00:30:05,760 --> 00:30:10,480
People used to hand roll assembly, right? I have no idea how that actually works.

267
00:30:10,480 --> 00:30:17,760
That's why I was interested in actually doing it. I wanted to do that experiment because I felt like

268
00:30:17,760 --> 00:30:22,480
I can't just sit there and complain that these things don't work if I've actually never tried

269
00:30:22,480 --> 00:30:27,040
it in earnest. So I wanted to understand because I don't think people like Peter

270
00:30:27,040 --> 00:30:32,480
are making this up, right? And he's not the only one. There's others who've been using this. And I

271
00:30:32,480 --> 00:30:41,040
think there's a scale. There's people who just blindly quote unquote vibe code and just have no

272
00:30:41,040 --> 00:30:47,600
sense of what's going on. And there's people like Peter who are, he's an expert, right? And he's,

273
00:30:48,480 --> 00:30:53,520
if you give me a jackhammer, all I'm going to do is ruin whatever I'm doing, right? It's not the

274
00:30:53,520 --> 00:30:58,720
right tool for me, but there's people like Peter, you can hand a tool like that and he'll use it

275
00:30:58,720 --> 00:31:04,720
responsibly and get amazing results out of it. So I think there's this aspect as well.

276
00:31:04,720 --> 00:31:10,800
- It's definitely, there's definitely a skill to using these tools. That's a hundred percent

277
00:31:10,800 --> 00:31:17,600
correct. And I've been using it for the kind of script that you were writing to compare those

278
00:31:17,600 --> 00:31:24,240
results that you talked about. I've been using it for that kind of task for many months now. And I

279
00:31:24,240 --> 00:31:28,720
was a hundred percent convinced that it was extremely good at writing that kind of code.

280
00:31:28,720 --> 00:31:35,760
This is the first time that I've ever told it to write something from start to finish. And I think

281
00:31:35,760 --> 00:31:41,840
your point about the edge cases and the things that you discovered while you were

282
00:31:43,440 --> 00:31:48,960
writing your own version before you asked the AI to write it. I definitely found that with this

283
00:31:48,960 --> 00:31:54,640
project through the specification phase, like the very first version of the specification,

284
00:31:54,640 --> 00:32:03,680
when I read through it, it didn't make sense because I hadn't thought, and I'll be specific,

285
00:32:03,680 --> 00:32:10,480
otherwise it's going to be very difficult to talk about. Critic markup has the ability to nest

286
00:32:11,200 --> 00:32:18,080
critic markup inside critic markup. And actually when I told it to write the spec the first time,

287
00:32:18,080 --> 00:32:21,920
I didn't realize that was even a thing, but it figured out that that was a thing in critic

288
00:32:21,920 --> 00:32:27,680
markup. And then it just started making up how that should work, right? And because I hadn't

289
00:32:27,680 --> 00:32:32,720
told it otherwise, but I hadn't, well, I didn't know that it was able to be nested. And so I

290
00:32:32,720 --> 00:32:39,520
hadn't thought about that at all. And so in the revision to the specification, I made some rules

291
00:32:39,520 --> 00:32:43,920
about what should happen with the nested markup. And actually what I said is that it shouldn't

292
00:32:43,920 --> 00:32:50,560
support nested markup and it should just, anything inside a markup piece should just be treated as

293
00:32:50,560 --> 00:32:56,560
the output. So that if there was nested markup, then it would just verbatim echo that as the

294
00:32:56,560 --> 00:33:03,840
original text. But that thinking through of that specification process was really, really important.

295
00:33:03,840 --> 00:33:09,040
And I think that's why it took me longer to write the specification than to write the code.

296
00:33:09,040 --> 00:33:15,920
Yeah. Yeah. Yeah. I mean, it's certainly a shift in skillset. I'm not sure if I'm,

297
00:33:15,920 --> 00:33:20,960
I'd be happier writing specs than writing code. That's the other thing. I mean, that's probably,

298
00:33:20,960 --> 00:33:27,040
that really depends on where you land in, in what parts of the system you like. Like I love writing

299
00:33:27,040 --> 00:33:32,480
tests for instance, and that's, I'm probably in the minority. So we all have different aspects

300
00:33:32,480 --> 00:33:37,280
of a system that we like. Right. And I also find that's why I'm so a bit worried about offloading

301
00:33:37,280 --> 00:33:45,040
these parts to the LLM is I often write a test and then I think of adjacent tests as I'm writing

302
00:33:45,040 --> 00:33:53,120
that test. And I feel like I fear that if I don't write tests, I lose that branching out and

303
00:33:53,120 --> 00:33:59,600
discovering edge cases that way. It might still happen in other ways. I'm just worried about that.

304
00:34:01,360 --> 00:34:08,320
So one of my biggest complaints about this whole AI, and I resist to call it that still,

305
00:34:08,320 --> 00:34:15,840
the LLMs is the aspect that I didn't trust them to work well enough. I think there's still areas

306
00:34:15,840 --> 00:34:23,200
where they're too blindly deployed and taken for truth when the results, especially when the

307
00:34:23,200 --> 00:34:28,000
results aren't verified and the person, the operator isn't actually able to verify them

308
00:34:28,000 --> 00:34:32,800
and then still they accept the results. I think that's a huge problem. And then the other big

309
00:34:32,800 --> 00:34:38,160
problem is the provenance. Where is all this knowledge coming from? And we've discussed this

310
00:34:38,160 --> 00:34:44,880
in the past. And we see the effects actually on this with package index. We're getting hammered by

311
00:34:44,880 --> 00:34:53,600
AI crawlers since end of last year and they come in waves and they're just slipping up all the

312
00:34:53,600 --> 00:34:59,520
data they can find. And it's not theirs. It's not their data. I talked to my partner over the weekend

313
00:34:59,520 --> 00:35:06,880
and I came up with this description. It's like people are using steroids and everyone else is

314
00:35:06,880 --> 00:35:13,200
getting acne, right? Because they are using all the data's out there and boosting their own systems.

315
00:35:13,200 --> 00:35:19,440
But everyone else is paying the price. If I actually insisted never to use an AI system,

316
00:35:20,080 --> 00:35:28,720
LLM system to help my work, I'd still be affected. And not just the down the line effects because

317
00:35:28,720 --> 00:35:36,240
people use LLMs to create fake news and whatnot. We see all these effects already like society-wide,

318
00:35:36,240 --> 00:35:44,800
but actually tangible effects where our system is getting hammered by AI crawlers and our systems

319
00:35:44,800 --> 00:35:51,920
are running hotter. We probably have to pay more for plans that are traffic related at some point,

320
00:35:51,920 --> 00:35:59,040
if not already, because of that. So we are bearing a cost and it's not the companies that are

321
00:35:59,040 --> 00:36:04,640
actually benefiting from the sales of these AI subscriptions eventually that are actually paying

322
00:36:04,640 --> 00:36:12,160
for it. And that's not even talking about the intellectual property that's getting copied,

323
00:36:12,160 --> 00:36:18,080
like the copyright violations that are happening. And I'm just wondering how that's going to play

324
00:36:18,080 --> 00:36:25,440
out. I think the IP issue is much more of a problem outside of code actually, because

325
00:36:25,440 --> 00:36:36,080
for example, in art and writing and all of that stuff, because the majority, if not all of the

326
00:36:36,080 --> 00:36:44,400
code that's being slurped up is open source. So there is very little IP. Although I had a big

327
00:36:44,400 --> 00:36:49,840
issue with this when they first came out, which was they were clearly trained on all open source

328
00:36:49,840 --> 00:36:55,680
code regardless of open source license. And so that includes a whole load of GPL code. And

329
00:36:55,680 --> 00:37:04,160
at what point does that GPL code not get covered by the GPL anymore?

330
00:37:04,160 --> 00:37:04,400
Yeah.

331
00:37:04,400 --> 00:37:10,320
It doesn't. They are way past the point of verbatim spitting out bits of code like they

332
00:37:10,320 --> 00:37:14,800
did at the very beginning, which is how we know it is chained on GPL code because it would spit

333
00:37:14,800 --> 00:37:23,120
out GPL licenses occasionally. But we've moved way further down the road and they're no longer

334
00:37:23,120 --> 00:37:33,280
working in that way at all. But there's definitely a huge IP issue with books and with art and with

335
00:37:33,840 --> 00:37:40,400
all sorts of other data that is harder to talk about with code because so much of it is open

336
00:37:40,400 --> 00:37:48,000
source. Whether that difference in the licenses is important or not, which I still believe it is,

337
00:37:48,000 --> 00:37:54,960
but I think it's harder to talk about that with code than it is with the other ones.

338
00:37:54,960 --> 00:38:02,080
Yeah. I mean, I get the point that legally it might be okay. I mean, but we've already had,

339
00:38:02,080 --> 00:38:08,080
we talked about this in the past quite a bit. Open source is being a pillar of software

340
00:38:08,080 --> 00:38:13,920
development and it's not really compensated for the value it generates. And there's yet another

341
00:38:13,920 --> 00:38:22,320
facet to it where it is yet propping up another pillar of the industry and is not getting

342
00:38:22,320 --> 00:38:28,960
compensated. Instead of actually turning back and helping out with one aspect of it, there's yet

343
00:38:28,960 --> 00:38:35,680
another front being opened where the value is siphoned off and is powering big tech companies.

344
00:38:35,680 --> 00:38:46,880
It's just not all right. It's really not okay. And the problem is all the mechanisms to control

345
00:38:46,880 --> 00:38:53,120
it are much, much slower than the development. There's no way any legal system or any regulatory

346
00:38:54,000 --> 00:38:59,440
body is going to be able to act fast enough before everything has happened already. The

347
00:38:59,440 --> 00:39:07,760
development is so fast. The EU doesn't even have the first meeting about legislation by the time

348
00:39:07,760 --> 00:39:16,800
this is irrelevant. Like you say, it's irrelevant now because they've moved on to probably not GPL

349
00:39:16,800 --> 00:39:21,520
covered code, even if they have, I mean, they might not have, who cares? No one cares at this

350
00:39:21,520 --> 00:39:25,920
point. I think that code is still there. It just no longer verbatim spits it back.

351
00:39:25,920 --> 00:39:30,480
Yeah. They've just suppressed the signal or the means of discovering it.

352
00:39:30,480 --> 00:39:34,960
I'm not sure it's even suppressing. Anyway, what we should actually do is because we're already

353
00:39:34,960 --> 00:39:40,240
40 minutes into recording the podcast and we haven't recommended a single package yet. So I

354
00:39:40,240 --> 00:39:45,760
think we should probably put this on hold because this is a long discussion that we will never find

355
00:39:45,760 --> 00:39:51,920
the end of, especially because we do have disagreements about some aspects of this.

356
00:39:51,920 --> 00:39:56,560
We're aligned on some of it, but we do also have disagreements. So I'm not sure we'll ever get to

357
00:39:56,560 --> 00:40:05,120
the end of this conversation. So let's do a reduced brief package recommendation section

358
00:40:05,120 --> 00:40:09,920
so that the podcast isn't an hour long. So let's just do one package each this week.

359
00:40:09,920 --> 00:40:11,840
That sounds good. Let's do that.

360
00:40:11,840 --> 00:40:21,440
I will kick us off. Yeah. My only package this week is a package called package-swift-lsp,

361
00:40:21,440 --> 00:40:31,200
which is by Kattouf, Vasiliy Kattouf. And it is a language server protocol implementation for

362
00:40:31,200 --> 00:40:39,200
Swift package managers, package.swiftmanifest files. So if you're not familiar with LSP,

363
00:40:40,480 --> 00:40:45,680
I'm not familiar with the internals of it, but I know how to use them. They are a way that

364
00:40:45,680 --> 00:40:56,240
code editors and other tools can interface with this LSP to find out what characters or text is

365
00:40:56,240 --> 00:41:02,800
available in the syntax of whatever language it is, in this case, the language of a package manifest

366
00:41:02,800 --> 00:41:09,680
and suggest the characters that may come next. And it's used in VS code. It's used in the Zed

367
00:41:09,680 --> 00:41:16,080
editor that you mentioned earlier. And I believe it's also used in Xcode for code completion as

368
00:41:16,080 --> 00:41:26,960
well. And the package Swift LSP is an LSP that has been integrated now into both Zed and VS code,

369
00:41:26,960 --> 00:41:33,680
but unfortunately not Xcode yet because there's no way to integrate third party LSPs, I don't think,

370
00:41:33,680 --> 00:41:42,240
into Xcode. That will give you code completion on the syntax of a package manifest,

371
00:41:42,240 --> 00:41:53,440
including package completion. So you can add a dependency for a package, start typing the URL,

372
00:41:53,440 --> 00:41:59,440
and it will suggest a valid package based on the characters you've typed. And that data is actually

373
00:41:59,440 --> 00:42:05,680
coming from the Swift package index list of packages file. So they actually give us a little

374
00:42:05,680 --> 00:42:13,200
thank you in the acknowledgements of the readme file. They acknowledge both Matt Massicotti's

375
00:42:13,200 --> 00:42:18,480
language service protocol, which was the foundation for their project, and then

376
00:42:18,480 --> 00:42:24,320
the Swift package index for providing a great package data for URL completion. And so if you

377
00:42:24,320 --> 00:42:32,560
are writing a package manifest with Zed or VS code and have the extension that they have provided,

378
00:42:32,560 --> 00:42:38,400
you get fantastic completion within package Swift file, better than Xcode.

379
00:42:38,400 --> 00:42:44,560
>> I think that's really remarkable, that these editors in a couple of cases are eclipsing Xcode

380
00:42:44,560 --> 00:42:48,160
because they're so extensible, right? That's really fantastic.

381
00:42:48,160 --> 00:42:57,120
>> And no AI at all involved in that one. >> It was actually my pick, first on my list

382
00:42:57,120 --> 00:43:00,560
of picks. So there we go. >> I'm sure luck to you.

383
00:43:00,560 --> 00:43:06,880
>> Yes, yeah. And that's actually via this package while trying it out. That's how I

384
00:43:06,880 --> 00:43:11,200
ended up using Zed again. I had looked at it in the past. That's how I ended up actually in that

385
00:43:11,200 --> 00:43:19,040
whole LLM experiment writing that script. Funny, funny little sequence of events.

386
00:43:19,040 --> 00:43:27,520
>> I've been using Zed recently for the HTML and CSS work on package index, actually, because

387
00:43:27,520 --> 00:43:35,440
you definitely don't want to do HTML and CSS work in Xcode. It's not what it's designed for.

388
00:43:36,800 --> 00:43:41,840
But I used to use, well, I still do use Visual Studio Code for that, but I've been giving Zed

389
00:43:41,840 --> 00:43:47,760
a try and it's very good. It's an editor written in Rust, actually, and it's extremely good.

390
00:43:47,760 --> 00:43:54,400
So what package are you going to pick? >> So in my pick, I'm going to talk about LLMs.

391
00:44:00,160 --> 00:44:08,640
My second pick is a package called Probing by Kamil Strzelecki. And this is a really interesting

392
00:44:08,640 --> 00:44:18,240
package. It essentially gives you a debugger-like execution control via checkpoints in your code.

393
00:44:18,240 --> 00:44:25,920
So what you can do is you can sort of like encode, write probe points that you can advance to.

394
00:44:26,640 --> 00:44:33,120
Like imagine setting a breakpoint, except you spell it out, like stop here. So you have named

395
00:44:33,120 --> 00:44:42,160
scopes. And then in a test, you can actually advance to that point as if you hit continue,

396
00:44:42,160 --> 00:44:46,320
and then you hit the breakpoint. And then you can run asserts on the state.

397
00:44:46,320 --> 00:44:51,600
And I found that really interesting, that that's possible and the mechanics of it.

398
00:44:53,440 --> 00:44:58,800
I haven't dug super deep into it. I've tried the example that it ships with. So there's an example

399
00:44:58,800 --> 00:45:04,240
that fully demonstrates the capabilities. It's a little test package with an application that

400
00:45:04,240 --> 00:45:11,280
has probes put into it, and then tests that exploit those probes to advance to this position,

401
00:45:11,280 --> 00:45:18,240
and then run asserts on the state. But there's one area where I can immediately see this being

402
00:45:18,240 --> 00:45:23,520
super useful. And we've had this actually a couple of times where something failed,

403
00:45:23,520 --> 00:45:30,160
and it only failed in CI. And especially at the time, our CI ran really slow. So it took like 15

404
00:45:30,160 --> 00:45:37,600
minutes. And you really just wish you were able to attach a debugger to a test and see what's

405
00:45:37,600 --> 00:45:43,920
going on. Because you might know it's failing in a method, or a test fails, and that test calls a

406
00:45:43,920 --> 00:45:50,480
method. And that method is quite large. It might call other methods, and you can't pinpoint where

407
00:45:50,480 --> 00:45:55,520
it is. So your only chance is really, if you can't reproduce it locally, your only chance would be

408
00:45:55,520 --> 00:46:00,640
to actually try and refactor the big method into smaller ones that you then test individually. And

409
00:46:00,640 --> 00:46:07,680
you can imagine how much work that would be. But with this, you can actually put probes in. You

410
00:46:07,680 --> 00:46:13,280
don't need to refactor, you just put in probes. And then in your test, you can run to the probes,

411
00:46:13,280 --> 00:46:18,720
and then you can run asserts on the internal state at that point. And then you can break

412
00:46:18,720 --> 00:46:25,760
down the big method into smaller bits and pinpoint the problem much easier. Or actually,

413
00:46:25,760 --> 00:46:31,200
just much easier, it would actually give you a chance to do it without a local reproducer or

414
00:46:31,200 --> 00:46:35,920
this big refactoring. So I think that's a super interesting package for that sort of thing.

415
00:46:36,960 --> 00:46:40,960
So if you have that situation, or are generally interested in that,

416
00:46:40,960 --> 00:46:45,040
give that a look. It looks really, really interesting.

417
00:46:45,040 --> 00:46:51,440
Well, we're slightly shorter than normal package section. We should wrap it up there, because

418
00:46:51,440 --> 00:47:01,360
we have now been going 48 minutes. So we should wrap it up. I think we'll have more to say on

419
00:47:01,920 --> 00:47:10,800
WWDC and the changes coming in Swift 6.2 and any other stuff that gets announced this week that we

420
00:47:10,800 --> 00:47:16,640
haven't yet watched the videos for in our next episode. But we should leave it here for today,

421
00:47:16,640 --> 00:47:23,200
I think. Yeah, let's stop it there. Thanks, everyone. And see you next week. Next time,

422
00:47:23,200 --> 00:47:28,320
rather. Next time, yes. In three weeks, something like that. All right. Take care.

423
00:47:28,320 --> 00:47:29,680
Bye. Bye-bye.

424
00:47:29,680 --> 00:47:30,560
Bye-bye.