1
00:00:00,001 --> 00:00:03,600
I've got, well I've actually got three packages but not a whole lot of notes on the third one,

2
00:00:03,600 --> 00:00:08,160
which is sort of a, kind of a Dave Verwer pick anyway.

3
00:00:08,160 --> 00:00:12,080
I've got a Dave Verwer pick as well.

4
00:00:12,080 --> 00:00:12,560
There we go.

5
00:00:12,560 --> 00:00:21,280
In fact I've potentially got two Dave picks, which are, if you're listening and I don't know

6
00:00:21,280 --> 00:00:27,040
what a Dave pick is, it's an interesting package that comes with some caveats normally.

7
00:00:27,760 --> 00:00:29,920
And is not recommended, actually.

8
00:00:29,920 --> 00:00:34,720
I know, I don't know whether it's, I don't know whether it's about whether it's not recommended

9
00:00:34,720 --> 00:00:41,360
or not, it's just, it's there, there are subtleties to my talking about it. It's not just a,

10
00:00:41,360 --> 00:00:42,880
oh this is amazing, you should use this.

11
00:00:42,880 --> 00:00:48,160
Well let me, let me clarify, it's mentioned and the first thing you say is

12
00:00:48,160 --> 00:00:51,360
you shouldn't be using or you won't be using it.

13
00:00:51,360 --> 00:00:56,240
I do, I do have one of those today.

14
00:00:56,240 --> 00:00:57,520
There we go, excellent.

15
00:00:57,520 --> 00:00:59,040
I do have one of those today.

16
00:00:59,040 --> 00:01:00,720
Welcome to the Swift Package Index.

17
00:01:00,720 --> 00:01:08,960
Well it's, it's, it's rarely, this is, so this is actually, this is the thing with picking

18
00:01:08,960 --> 00:01:14,160
dependencies, right? It's rarely a straightforward decision and that's why you need so much

19
00:01:14,160 --> 00:01:16,640
information that we, we provide with the index.

20
00:01:16,640 --> 00:01:21,040
Right, right. The not picking of dependencies is also a skill that needs to be honed.

21
00:01:25,680 --> 00:01:26,800
And we're here to help.

22
00:01:26,800 --> 00:01:29,760
Well, maybe, we're here, we're here at least.

23
00:01:29,760 --> 00:01:38,160
We are here. There is an interesting post on the Swift forums, not sure if you've seen it,

24
00:01:38,160 --> 00:01:45,120
it's by Doug Greger, a new sample, what's the post title? New sample tiny swing program

25
00:01:45,120 --> 00:01:48,080
mixing Java and Swift. Did you see that one?

26
00:01:48,080 --> 00:01:55,360
I, I, so this is a bit of inside baseball here. I only saw it because you sent me the link to it.

27
00:01:55,360 --> 00:01:58,080
All right, well that, that qualifies it. It means you read my stuff.

28
00:01:58,080 --> 00:02:08,320
I was really, I was really curious about that one. And obviously we talked about the announcement

29
00:02:08,320 --> 00:02:14,880
last episode about the Swift Java interop, which was announced at the server-side Swift

30
00:02:14,880 --> 00:02:20,560
conference in end of September. Really great announcement. Really exciting to see that

31
00:02:20,560 --> 00:02:28,000
development. And Doug has taken what I believe is pretty much a, one of the classic or canonical

32
00:02:28,000 --> 00:02:35,200
examples about Java development, like the UI development. It's like a, a little Celsius to

33
00:02:35,200 --> 00:02:40,560
Fahrenheit converter, right? Just two text fields and a button to convert between the two.

34
00:02:40,560 --> 00:02:45,760
A problem, a problem that we can only solve. There's no way we could solve that problem.

35
00:02:45,760 --> 00:02:49,680
Well, the proper way of solving that problem would actually to just everyone be using Celsius.

36
00:02:49,680 --> 00:02:57,120
I'm sure we also need some kind of microservices architecture in there somewhere.

37
00:02:57,120 --> 00:03:01,600
And that could be Kubernetes deployed. I mean, certainly that would be the appropriate way to do

38
00:03:01,600 --> 00:03:08,800
it. But in the absence of all of that, you'd, you'd obviously write a, a swing Java application

39
00:03:08,800 --> 00:03:13,680
for it. Install Java, which was, which is actually the biggest hurdle in getting this running.

40
00:03:13,680 --> 00:03:21,040
The props to Doug, the example worked flawlessly, but installing Java, which I haven't done in,

41
00:03:21,040 --> 00:03:28,880
in like more than 10 years, well over 10 years. And thankfully it's actually quite easy to brew,

42
00:03:28,880 --> 00:03:34,560
you can install it with brew. You still have to do some fiddling with the setting up the Java home,

43
00:03:34,560 --> 00:03:41,920
like telling the, the OS where your JDK lives. That sort of stuff. I've, I was glad I still had

44
00:03:41,920 --> 00:03:49,600
some memory of, of how that works. It's it, it, it works quite well. And then you effectively just

45
00:03:49,600 --> 00:03:54,560
run Swift build and then you have a, a command to bring up the thing. But what Doug has done

46
00:03:54,560 --> 00:04:00,560
is he's sort of started out the, with the original Java example, then replaced parts of it with

47
00:04:00,560 --> 00:04:07,920
Swift and just initially the computation of converting from Celsius to Fahrenheit,

48
00:04:09,120 --> 00:04:15,920
which is, you know, then handled by a Swift function, but also then the, the instantiation

49
00:04:15,920 --> 00:04:23,840
of the UI components actually invoked from Swift, obviously calling up the, the, still the swing

50
00:04:23,840 --> 00:04:30,080
objects, but they actually created in Swift and then the setup and done is there. It's,

51
00:04:30,080 --> 00:04:33,920
it's interesting. It's like, it demonstrates a lot, even though it's such a small example,

52
00:04:33,920 --> 00:04:38,160
you know, have a, like a proper easy function call. I mean, that's, you know, the first thing

53
00:04:38,160 --> 00:04:43,840
you want to try and see, but it's also the easiest thing, right? Calling a thing that converts one

54
00:04:43,840 --> 00:04:51,120
double into another is something that is, is not as mind bending as thinking about UI components

55
00:04:51,120 --> 00:04:55,600
being instantiated across the bridge like that, and then handed back and forth. And that's,

56
00:04:55,600 --> 00:05:03,520
that's really nice to see. It also gave me a bit of a flashback because I remembered that the very

57
00:05:03,520 --> 00:05:12,960
first application I wrote for Mac OS in 2000, 2001 was actually Java. So you, I'm sure you

58
00:05:12,960 --> 00:05:16,560
recall, I actually know you started using the Mac laters. You might not recall this

59
00:05:16,560 --> 00:05:24,000
when the first Mac OS versions came out after the next acquisition. It came with Coco, which was,

60
00:05:24,000 --> 00:05:31,120
you know, the Coco that we know today, but it came with your objective C sort of backend,

61
00:05:31,120 --> 00:05:38,160
but also it came with a Java backend. So you could write a Java app that called into the Coco UI

62
00:05:38,160 --> 00:05:45,600
libraries. And that's what I did because I knew some Java objective C I'd never heard of before.

63
00:05:45,600 --> 00:05:50,160
And there were examples, they had like the exact, exactly like currently, or for a while,

64
00:05:50,160 --> 00:05:55,040
when Swift came out, you had the, the dual facing, you know, they had Swift and Coke

65
00:05:55,040 --> 00:06:02,800
objective C examples when you wrote an iOS or Mac OS app at the time you had objective C and Java.

66
00:06:02,800 --> 00:06:08,160
Right. And that's what I did. That's a little bit before my time in on the backside, but,

67
00:06:08,160 --> 00:06:14,480
but the only thing I do remember of that is that what was the web frameworks, web objects,

68
00:06:14,480 --> 00:06:20,720
came with Java examples for a long time still after, after they dropped them from the Coco side.

69
00:06:21,520 --> 00:06:26,800
Yeah, there was for quite a while, I think there was sort of, I'm not sure how,

70
00:06:26,800 --> 00:06:33,360
how clear it was to everyone involved, which one would win out. I remember at the time also,

71
00:06:33,360 --> 00:06:39,200
Java was just the thing, you know, it's like these days, you have to have AI at the time,

72
00:06:39,200 --> 00:06:44,320
you sort of had to have Java in your, in your stack somewhere, you needed to be talking about

73
00:06:44,320 --> 00:06:49,520
Java. And it was very much the thing that people thought would solve all the, you know, different

74
00:06:50,080 --> 00:06:54,800
UI paradigms across different platforms and stuff. So it was quite interesting. It did,

75
00:06:54,800 --> 00:07:00,160
I didn't keep it around for long, because it was, it was very clear, I can't point to exact

76
00:07:00,160 --> 00:07:07,840
examples of what tipped me off. But when you looked at it, you knew, no, this, this is the one

77
00:07:07,840 --> 00:07:13,280
you actually should be using. The other one is, is, you know, there were these little signs

78
00:07:14,240 --> 00:07:19,520
along the side, you see, yeah, you can see this is it kind of works, but it's probably not.

79
00:07:19,520 --> 00:07:25,040
It's probably not the one that's, that's going to stick around pretty much like also after a while,

80
00:07:25,040 --> 00:07:31,120
it was clear that, you know, with Swift, newer stuff would be Swift only and Objective-C is kind

81
00:07:31,120 --> 00:07:36,560
of on, on the way out. But it's, it was really interesting to see Java come up again in this

82
00:07:36,560 --> 00:07:43,440
context and being used in a UI application. So really nice example there, we'll, we'll add links

83
00:07:43,440 --> 00:07:51,360
to the show notes. Yeah, it's Java was a language that passed me by, really. I, my university

84
00:07:51,360 --> 00:08:00,560
degree was to, it was before Java's time, we learned C++ and C on in my university degree.

85
00:08:00,560 --> 00:08:07,840
And then when Java was kind of taking off, I was doing Delphi and Object Pascal. And then

86
00:08:08,560 --> 00:08:15,040
from there into, into the web, basically. So Java kind of missed, passed me by. So it's never,

87
00:08:15,040 --> 00:08:20,480
it's not something I ever really got any, any real experience with. I, I wrote, I think I wrote a

88
00:08:20,480 --> 00:08:26,640
little applet once for some website that we did one time. But that was about it. Yeah, no, I only

89
00:08:26,640 --> 00:08:34,320
encountered it in a, in a project later on as well. It's my, my university stuff was also C and,

90
00:08:35,200 --> 00:08:42,480
and Pascal. Yeah, it was Pascal. I'm not sure we used Delphi, but some, some,

91
00:08:42,480 --> 00:08:50,400
something that used Pascal and compiled Pascal. Some kind of Pascal. Yeah. Yeah. Very popular

92
00:08:50,400 --> 00:08:57,760
back then. God, we're dating ourselves again. Let's, let's move on. Yes, yes. It is the old

93
00:08:57,760 --> 00:09:07,760
person Swift broadcast again. Yeah. Talking of Swift, I did a little survey in iOS Dev Weekly

94
00:09:07,760 --> 00:09:15,840
last week, which was kind of interesting. And I, it was, the survey was both about Swift and also

95
00:09:15,840 --> 00:09:21,840
kind of Apple platform development. But, and I wrote about the results of it in last Friday's

96
00:09:21,840 --> 00:09:25,680
email. So there's a kind of detailed look at it there, but I thought it was just worth mentioning

97
00:09:25,680 --> 00:09:32,080
here as well. That both Swift and Apple platform development got, I asked her two questions at the

98
00:09:32,080 --> 00:09:38,960
beginning, which is how do you feel about Swift and how do you feel about object, object Pascal,

99
00:09:38,960 --> 00:09:46,560
not object Pascal. How do you feel about some Apple platform development? And there was a scale

100
00:09:46,560 --> 00:09:55,840
of kind of pessimistic to optimistic from one to five. And both answers got well above average.

101
00:09:55,840 --> 00:10:02,240
Apple platform development got a four out of five and Swift got a three and a half out of five,

102
00:10:02,240 --> 00:10:09,520
which is, you know, it's a positive, it's a positive number. But what I noticed is because

103
00:10:09,520 --> 00:10:14,720
people were also then asked later in the survey to leave comments about what,

104
00:10:16,000 --> 00:10:20,640
about what they thought about these two technologies. And it, what was quite interesting

105
00:10:20,640 --> 00:10:26,800
was obviously the people who felt pessimistic, one of the things that they brought up was

106
00:10:26,800 --> 00:10:33,840
Swift concurrency and language complexity in general. But actually what was kind of interesting

107
00:10:33,840 --> 00:10:40,320
was that also in the people who felt optimistic about the language, those same themes came through

108
00:10:41,040 --> 00:10:46,240
regularly. And it was, it was the main feedback about the language, both from people who felt

109
00:10:46,240 --> 00:10:51,840
pessimistic and optimistic. Interesting. Yeah. I, by the way, I really liked what you did in,

110
00:10:51,840 --> 00:10:57,120
in Iostep weekly last week that you had the intro and then expanded on it later on.

111
00:10:57,120 --> 00:11:03,600
Yeah, I got some good feedback about that. People, people liked it. Although at the same time,

112
00:11:03,600 --> 00:11:07,760
I did get a higher than normal number of unsubscribes. So yeah, it's mixed.

113
00:11:07,760 --> 00:11:11,920
Oh, that's a shame.

114
00:11:11,920 --> 00:11:15,440
The people who took time to write liked it and the people who didn't just unsubscribe.

115
00:11:15,440 --> 00:11:19,040
Well, just, just, you know, these people liked it harder than the others did.

116
00:11:19,040 --> 00:11:32,240
Yeah, it's, it's a, it's a theme and I wonder how much of it is sort of self-fulfilling. I,

117
00:11:32,880 --> 00:11:39,120
I've mentioned this before and I'll happily say it again. I think a lot of this discussion around

118
00:11:39,120 --> 00:11:48,000
Swift getting more complex is just people having to face the inherent complexity there is.

119
00:11:48,000 --> 00:11:54,240
People complain about C++ being complex and other languages being complex. And

120
00:11:54,240 --> 00:12:02,640
there is just something that we're dealing with as we write software for now systems that have

121
00:12:03,360 --> 00:12:09,760
10 cores. I mean, it's not rare. I mean, that's like common to have six, seven, eight cores. So

122
00:12:09,760 --> 00:12:16,160
you are dealing with multi-processor systems and accordingly are sort of

123
00:12:16,160 --> 00:12:24,240
herded down the path of dealing with that. I mean, when I, we're going back in that territory again.

124
00:12:24,240 --> 00:12:32,320
When I started programming, I actually managed to talk our professor at the time into buying us a

125
00:12:32,320 --> 00:12:38,560
dual core Pentium at the time. Like you actually had two processors. There were like two separate

126
00:12:38,560 --> 00:12:47,360
cards on the thing and that was rare. So in lots of ways, there was no complexity of that sort to

127
00:12:47,360 --> 00:12:52,480
deal with. Yes, of course the systems were multitasking and they did stuff and you sort of

128
00:12:52,480 --> 00:13:00,080
all the underpinnings were already there. But I think these days you are just, you're leaving

129
00:13:00,080 --> 00:13:06,800
much more on the table if you ignore that and don't deal with it at all. But that complexity

130
00:13:06,800 --> 00:13:12,880
is there. You need to synchronize somehow when you deal with data, right? It's just because Swift 5

131
00:13:12,880 --> 00:13:20,800
doesn't deal with the warnings effectively that Swift 6 flushes out. Doesn't mean the problems

132
00:13:20,800 --> 00:13:26,080
aren't there. It's just, you see them maybe rarely because you don't look at crash reports or

133
00:13:27,840 --> 00:13:32,160
you don't make the connection necessarily. You think it's someone else's bug, but

134
00:13:32,160 --> 00:13:38,800
stuff is there and some part of the system has to deal with it. And you are part of that system

135
00:13:38,800 --> 00:13:43,520
having to deal with it. So in a sense, it's like complaining about the weather. I mean,

136
00:13:43,520 --> 00:13:50,000
you know, you got to get a bit thicker coat. It's just no way around it. Yeah. I think one thing

137
00:13:50,000 --> 00:13:56,800
that I, in my, when I was writing about it on Friday, the one thing I added to it is obviously

138
00:13:56,800 --> 00:14:02,080
that we've said many, many times now is that you don't need to opt into Swift 6 language mode

139
00:14:02,080 --> 00:14:08,240
immediately. But I think there is also a downside to that, which is that people don't like feeling

140
00:14:08,240 --> 00:14:16,000
like they're being left behind. And maybe this is clear, but I'm not sure it's clear to me.

141
00:14:16,000 --> 00:14:23,280
Certainly I can't think whether it's been said off the top of my head is, is there any

142
00:14:24,720 --> 00:14:29,040
estimation of how long these language modes will stick around? I mean, is staying on an old

143
00:14:29,040 --> 00:14:34,080
language mode indefinitely? Is that, I don't think that's a possibility, but I don't think

144
00:14:34,080 --> 00:14:42,960
it's clear when you'll be kind of moved towards making that decision, whether you like it or not.

145
00:14:42,960 --> 00:14:49,520
Honestly, looking at lots of packages, I get the feeling like the packages themselves are going to

146
00:14:49,520 --> 00:14:57,440
age out before Swift 5 mode disappears. I mean, like Swift 4 mode is around and no one is writing

147
00:14:57,440 --> 00:15:03,520
packages in, you know, that requires Swift 4 anymore. And there were also big steps in the

148
00:15:03,520 --> 00:15:10,640
past that sort of, you know, were hurdles. And I don't think that's a concern. I mean,

149
00:15:10,640 --> 00:15:17,120
not in the sense I understand that people have that worry, but I think it really bears repeating.

150
00:15:17,120 --> 00:15:20,720
That's not the thing you need to worry about. I think that the thing people need to worry about

151
00:15:20,720 --> 00:15:29,520
is whether the cost of not using what Swift 6 mode offers is a loss, right? Are you not

152
00:15:29,520 --> 00:15:35,600
leaving something on the table by not using these tools to make it easier and safer? I mean, easier

153
00:15:35,600 --> 00:15:40,560
is sort of, it's only going to be easier in hindsight. You know, once you've paid sort of

154
00:15:40,560 --> 00:15:47,360
the price of learning how to actually use it, then, you know, then that, you know, the balance

155
00:15:47,360 --> 00:15:54,560
shifts a bit. Actually, something I want to bring up in that sense, because you see this a lot in

156
00:15:54,560 --> 00:16:01,520
social media, it seems like it's often people well regarded in the community that spearhead

157
00:16:01,520 --> 00:16:07,600
these discussions about Swift complexity and stuff. And there's a really interesting

158
00:16:07,600 --> 00:16:13,360
observation I made a while back, there was a well known podcaster and Swift author,

159
00:16:13,360 --> 00:16:16,480
I don't want to name him, although it's probably going to be obvious who it is,

160
00:16:16,480 --> 00:16:22,800
because I don't want to throw shade, but he was very reluctant to move to Swift. He complained

161
00:16:22,800 --> 00:16:29,120
about it. It's super complex and hard. And, you know, it was very clear that the problem of

162
00:16:29,120 --> 00:16:35,520
switching wasn't the language, but his discomfort of trying the new thing and feeling like stepping

163
00:16:35,520 --> 00:16:42,960
back. And it's very easy to feel that way, right? There's something you're really familiar with,

164
00:16:42,960 --> 00:16:48,800
you know exactly how to do and you're asked to forget that or sort of not use it and use

165
00:16:48,800 --> 00:16:56,160
something else instead and relearn your skills. And then at some point, you realize, well, I'm

166
00:16:56,160 --> 00:17:01,040
going to have to move because I can't be using I can't keep object using Objective C anymore,

167
00:17:01,040 --> 00:17:08,080
there are APIs coming out that aren't Objective C native. And while it still might be possible to

168
00:17:08,080 --> 00:17:14,000
use them, I'm very clearly, you know, going down the wrong path. So he started writing parts of

169
00:17:14,000 --> 00:17:22,720
his app in Swift. And lo and behold, week by week, it seemed to be getting easier. And after a while,

170
00:17:22,720 --> 00:17:27,520
he spoke quite favorably about Swift. And he made that transition, he made that change, he trained,

171
00:17:28,240 --> 00:17:34,400
he retrained in Swift, and I would actually get his his really his common body actually post stuff

172
00:17:34,400 --> 00:17:41,120
where he says, this is really nice. Look, look how Swift is succeeding here. I think if you presented

173
00:17:41,120 --> 00:17:46,960
him today with a choice, which one do you like better? Which one do you think is easier? Which

174
00:17:46,960 --> 00:17:52,800
one is is, is better at dealing with the complexity of your software? I'm pretty confident he'd say,

175
00:17:52,800 --> 00:17:58,800
it's Swift. But it's really hard to see that before the transition, this is only something

176
00:17:58,800 --> 00:18:05,120
you see after you've you've paid that price of, you know, that ramping up cost into, into the new

177
00:18:05,120 --> 00:18:13,280
system. And I think that's largely a communication problem and and education problem for all of us to,

178
00:18:13,280 --> 00:18:18,160
to take the plunge. And also, I think on the tooling side, they are, I mean, we know this,

179
00:18:18,160 --> 00:18:23,760
right, there are rough edges still around how warnings are presented, how many there are,

180
00:18:23,760 --> 00:18:28,960
some of them can actually go away, because the compiler can be smarter. And I think,

181
00:18:28,960 --> 00:18:36,320
because of that, it's really important to stress that the switch to Swift six mode is not something

182
00:18:36,320 --> 00:18:42,080
you need to do immediately, you actually are on the leading edge of the adoption curve, if you're

183
00:18:42,080 --> 00:18:48,400
doing it now, oh, completely give yourself the time, because stuff will improve all on its own

184
00:18:48,400 --> 00:18:52,240
without you doing anything. And if you do this in a year's time, you'll have a better time.

185
00:18:52,240 --> 00:18:57,360
By all means, if you feel like it's interesting, and something you want to do now do it because

186
00:18:57,360 --> 00:19:02,080
you will benefit already. I mean, we have benefited in our project from from doing it.

187
00:19:02,080 --> 00:19:08,400
But it's you're not, there's no FOMO here, you're not losing out on anything by waiting. In fact,

188
00:19:08,400 --> 00:19:14,320
you're you're gaining, you know, just letting other people do the adoption is helping you

189
00:19:14,320 --> 00:19:21,360
indirectly. And I think that's the part that is missing a bit. And I suspect a lot of that

190
00:19:21,360 --> 00:19:28,800
negativity around Swift and concurrency is, is a bit of fear, you know, there's a big change

191
00:19:28,800 --> 00:19:35,200
coming. I don't really know what it's about. I see these people who are really, you know,

192
00:19:35,200 --> 00:19:40,320
advanced struggling with it. How would I have a chance? I mean, I have those same thoughts. Like,

193
00:19:40,320 --> 00:19:45,040
I, I look at Matt Massicotti, who we'll probably be talking about in a minute.

194
00:19:45,040 --> 00:19:51,200
Again, making changes and struggling with some of that stuff and posting stuff. And I read his

195
00:19:51,200 --> 00:19:55,680
posts, I think, Jesus Christ, I would never figure this out. But the good thing is, I don't have to

196
00:19:55,680 --> 00:20:01,040
write, I can just give myself the time and wait. There's no, there's no one sitting there and

197
00:20:01,040 --> 00:20:07,360
asking me to make this change tomorrow. I think, I think everything you've said there is, is,

198
00:20:07,360 --> 00:20:15,680
is good. But also, in some way, doesn't matter, because the perception is, is the reality. I mean,

199
00:20:15,680 --> 00:20:24,960
people, there is a, there is a definite feeling of this. And it's, it's not something that should be,

200
00:20:24,960 --> 00:20:29,840
I don't think any changes are needed or anything like that. But it's certainly something that

201
00:20:29,840 --> 00:20:38,400
we should be aware of, because it can, this kind of thing can, can become how, how people externally

202
00:20:38,400 --> 00:20:41,360
see the language as well. - Yeah, absolutely. Yeah, that's why I'm saying it. I think it's,

203
00:20:41,360 --> 00:20:46,560
like, communication-wise, it's really important to, to try and, you know, maybe not counter,

204
00:20:46,560 --> 00:20:52,240
it's like, it's more, it sounds more like an argument, but maybe stress that there's no,

205
00:20:52,240 --> 00:20:59,440
the time-critical part isn't as time-critical as you think it is. And to more pitch

206
00:21:00,400 --> 00:21:06,400
this is not a chore. This is actually, you're, you're opting into a, a mechanism that helps you.

207
00:21:06,400 --> 00:21:13,280
And I, I often miss that from the discussion. The, the upsides of making this change aren't,

208
00:21:13,280 --> 00:21:17,120
aren't what's typically presented. - I would push back a little bit there. I think,

209
00:21:17,120 --> 00:21:24,400
I think, I think it's clear that there are advantages to adopting data-based safety in

210
00:21:24,400 --> 00:21:31,200
Swift 6 language mode, but they are not super obvious changes in all cases. In fact, in most

211
00:21:31,200 --> 00:21:37,200
cases, they're not super obvious changes. And this is not, this is not a problem that the language

212
00:21:37,200 --> 00:21:42,160
was really struggling with any more than any other language struggles with this. And yes,

213
00:21:42,160 --> 00:21:48,160
it's better, but it wasn't, this was not something that people were going, "Oh, I wish that somebody

214
00:21:48,160 --> 00:21:53,520
would solve data-based safety." And I think that's where some of it comes from. - Yeah, that's a fair

215
00:21:53,520 --> 00:22:00,640
point. But I think that's also because we don't immediately associate issues with, with the source

216
00:22:00,640 --> 00:22:05,600
there because it's so disconnected, right? This is like, this is like someone pushing a change on

217
00:22:05,600 --> 00:22:09,760
Wednesday and, and, you know, two weeks later it crashes in production. You don't make that

218
00:22:09,760 --> 00:22:16,720
immediate connection. And these crashes we, we often seen, it's really hard to trace that back.

219
00:22:16,720 --> 00:22:21,600
- It often is, yeah, exactly. Yeah. Yeah. But if you think, and that's, but that's in a, that's in

220
00:22:21,600 --> 00:22:27,040
a highly concurrent Swift on the server application. If you think about your average iOS application,

221
00:22:27,040 --> 00:22:34,480
this was not the big problem. - Well, I guess, but I mean, it's also not something that's even

222
00:22:34,480 --> 00:22:38,720
harder to see there because it's not your device that's going to crash, right? - Sure, sure.

223
00:22:38,720 --> 00:22:47,520
Anyway, good, good, good to hear what people are thinking about it. And, and, and as you say,

224
00:22:48,160 --> 00:22:52,960
going forward, it's only going to get better from here. You don't have to do it immediately. So,

225
00:22:52,960 --> 00:22:56,800
but I thought it was interesting to bring those, bring those results to the podcast too.

226
00:22:56,800 --> 00:23:00,240
- Yeah, absolutely. Yeah. And I think it's, it's also important not to just,

227
00:23:00,240 --> 00:23:05,120
just gloss over it, right? Because if people voice that concern, it's, it's a, it's a concern that

228
00:23:05,120 --> 00:23:11,040
needs to be heard and discussed and, and, and of course, it can drive a bit of change around tooling

229
00:23:11,040 --> 00:23:16,880
and communication to, to make it clearer what the, what the stakes are. - Shall we do some package

230
00:23:16,880 --> 00:23:23,520
recommendations? - Yeah, let's do some packages. - Okay. I will start us this week and I'll start

231
00:23:23,520 --> 00:23:32,480
us with a package called Swift Claude, which is predictably an API wrapper around Anthropx

232
00:23:32,480 --> 00:23:42,880
Claude API, which is one of these LLM providers. They are kind of on par with ChatGPT and OpenAI

233
00:23:42,880 --> 00:23:51,120
as, as the kind of market leader. And this is a predictable wrapper around the API, but there

234
00:23:51,120 --> 00:23:57,680
was something in it that struck me that I hadn't seen before and I thought was worth a mention.

235
00:23:57,680 --> 00:24:10,800
And it was that you can, apparently in the Claude API, you can supply functions in your code

236
00:24:10,800 --> 00:24:16,560
and let the AI decide when to call them, which is something I hadn't come across before. And you can

237
00:24:16,560 --> 00:24:27,120
do this via the API. So you can define a, an API within your Swift code and using a, a property

238
00:24:27,120 --> 00:24:35,280
wrapper, you can mark that as something that the API should be aware of. And it will communicate

239
00:24:35,280 --> 00:24:43,360
the details of that API up to Claude. And then Claude will decide, depending on what, what it's

240
00:24:43,360 --> 00:24:48,800
doing with your prompt, will decide what, when to call that function and what parameters to call it

241
00:24:48,800 --> 00:24:55,680
with. So you can kind of have the LLM decide to call, call back to code in your application,

242
00:24:55,680 --> 00:25:01,680
which I thought was very interesting and a great implementation through property wrappers here into,

243
00:25:02,400 --> 00:25:08,000
into Swift is really a very trivial, a very trivial mechanism to

244
00:25:08,000 --> 00:25:13,280
transmit the details of your API up into the Claude API.

245
00:25:13,280 --> 00:25:18,000
Interesting. Is there like an example given how you would use that?

246
00:25:18,000 --> 00:25:25,760
There is, there is, but it's a, it's a very abstract example and not actually that useful

247
00:25:25,760 --> 00:25:31,600
unless, unless it's referring to something that I don't know about. So the, the example that's in

248
00:25:31,600 --> 00:25:38,560
the readme file is there's a struct called turbo encabulator, which I don't know what an encabulator

249
00:25:38,560 --> 00:25:46,720
is. And it says it turbo encabulates its input. And the parameter is a number of marzl vein count,

250
00:25:46,720 --> 00:25:51,280
which I also don't know what those are. I think they're made up. I think, I think it's just a

251
00:25:51,280 --> 00:25:58,320
completely abstract. I think it is. I think it's just completely abstract, but it's, it's so

252
00:25:58,320 --> 00:26:02,080
obscure that it made me think, I wonder if this is a thing that I just don't know about.

253
00:26:02,080 --> 00:26:12,480
And, and then in the conversation, the prompt says, I'm creating a demo showcasing your ability to

254
00:26:12,480 --> 00:26:18,400
use tools. Can you invoke the turbo encabulator tool with some made up input? So I have a feeling

255
00:26:18,400 --> 00:26:23,840
it is purely just a, an abstract example. Right. Yeah. Okay. Interesting.

256
00:26:25,120 --> 00:26:30,160
And of course it also supports all the other things that all of these API support. So it

257
00:26:30,160 --> 00:26:38,160
supports full text responses. It supports streamed text responses. So you can show the output as you

258
00:26:38,160 --> 00:26:45,440
receive it from the API. It has image, UI image and NS image compatibility. So you can include

259
00:26:45,440 --> 00:26:52,160
images with your, with your prompts and you know, all the other things that these, that these API

260
00:26:52,160 --> 00:26:57,040
wrappers all, all do. But I thought the, the tool use was, was worth, worth a mention.

261
00:26:57,040 --> 00:27:05,120
Nice. Yeah. Interesting that these, I guess all the LLMs and their providers are covered by,

262
00:27:05,120 --> 00:27:09,600
by Swift packages now, aren't they? I've seen quite a number of them.

263
00:27:09,600 --> 00:27:14,240
Pretty much. Yeah. Yeah. There's, there's certainly ones for all of the major kind of

264
00:27:14,240 --> 00:27:20,240
commercial ones. And then there's also ones for things like Llama and a lot of the other

265
00:27:21,120 --> 00:27:23,600
ones as well that are kind of some of them are non-commercial too.

266
00:27:23,600 --> 00:27:26,400
Okay. My first pick is called...

267
00:27:26,400 --> 00:27:29,440
Oh, and I didn't say who that was from. It was from George Leon.

268
00:27:29,440 --> 00:27:39,440
Nice. Okay. My first pick is called JSON Patch by Peter Ringset. And this is an interesting

269
00:27:39,440 --> 00:27:45,360
package dealing with JSON Patch objects. Have you heard of JSON Patch objects before? I hadn't.

270
00:27:45,360 --> 00:27:45,920
I have.

271
00:27:45,920 --> 00:27:47,440
You have. Oh, okay. So...

272
00:27:47,440 --> 00:27:49,840
I've not used them, but I have heard of them.

273
00:27:49,840 --> 00:27:54,400
Interesting. Yeah. So this was new to me. So this is actually an RFC and it's an RFC to,

274
00:27:54,400 --> 00:28:00,720
like a spec to modify JSON objects. And effectively it's like little specification

275
00:28:00,720 --> 00:28:09,920
for little JSON snippets that define operations on a JSON object, like add, remove, remove and

276
00:28:09,920 --> 00:28:15,920
replace operations on properties. Like you could add a new property, remove one or replace one,

277
00:28:17,200 --> 00:28:23,760
or replace the value and stuff like that. Think of as a diff mechanism on a JSON object. And

278
00:28:23,760 --> 00:28:31,440
this is like a Swift package that deals with that. So you can specify these operations in Swift and

279
00:28:31,440 --> 00:28:39,760
then generate these patch objects and also apply these patch objects to an existing JSON object

280
00:28:39,760 --> 00:28:45,680
that you have in your data and stuff like that. So really interesting. And I think this is also

281
00:28:45,680 --> 00:28:52,720
interesting in combination with HTTP patch requests, where you would not send the whole

282
00:28:52,720 --> 00:28:57,280
object again, but have a patch operation on an existing object. And then you can

283
00:28:57,280 --> 00:29:04,080
streamline your APIs to be passing around these rather than having big objects passed around

284
00:29:04,080 --> 00:29:10,640
when they change and stuff like that. So yeah, quite interesting. That's JSON Patch by Peter

285
00:29:10,640 --> 00:29:11,600
Ringseth.

286
00:29:11,600 --> 00:29:23,200
Very cool. My next package is called Singapore Kit by Jia Chen. And this is a package that is

287
00:29:23,200 --> 00:29:31,520
very specific. So it is a package that makes it easy to use Singapore government data within your

288
00:29:31,520 --> 00:29:37,840
SwiftUI projects. And again, comes with a property wrapper. And that's the reason that I'm highlighting

289
00:29:37,840 --> 00:29:46,080
it really is this property wrapper effectively gives you a Singapore property wrapper that you

290
00:29:46,080 --> 00:29:54,000
can pop before any variable. And if you pass a key path into that property wrapper of one of the

291
00:29:54,000 --> 00:29:59,760
bits of data you would like, for example, like relative humidity or air temperature or rainfall

292
00:29:59,760 --> 00:30:06,480
or air quality or UV index or a whole load of other bits of data, and then declare a variable

293
00:30:06,480 --> 00:30:13,040
after that property wrapper, it's going to automatically pull that data in and assign it

294
00:30:13,040 --> 00:30:16,800
into that variable for you. And it reminded me of something that we're just switching across to

295
00:30:16,800 --> 00:30:24,320
in the Swift package index now. It reminded me of the dependencies package and property wrapper

296
00:30:24,320 --> 00:30:29,040
from Pointfrico, which I think works in a... I don't know how it works behind the scenes, but

297
00:30:29,040 --> 00:30:34,800
to the end user, it works in a similar way is that you kind of say, this is a piece of data that I

298
00:30:34,800 --> 00:30:42,080
would like to bring in as a dependency to this type that I'm working with right now. And that is

299
00:30:42,080 --> 00:30:48,000
literally all you have to do. And it's a very powerful way of working with something like this.

300
00:30:48,000 --> 00:30:52,480
Now, I'm not sure what's happening behind the scenes, whether there are network requests being

301
00:30:52,480 --> 00:30:58,000
made. And that is the disadvantage of something like this is that it is completely opaque,

302
00:30:58,000 --> 00:31:04,080
how it's actually working. Is there any caching happening here? Or is this setting off network

303
00:31:04,080 --> 00:31:11,760
requests, which I presume it is. But I do like the syntax of this. And I think it's something

304
00:31:11,760 --> 00:31:18,400
that I'm seeing more and more often at the moment. Interesting. I wonder if that would work because

305
00:31:18,400 --> 00:31:27,120
a property wrapper can't be async, can it? So I'm curious how that works.

306
00:31:27,120 --> 00:31:34,720
I don't think it can. But I am looking down further in the readme now and I am finding that

307
00:31:34,720 --> 00:31:40,480
the relative humidity, for example, this is just an example that's in the readme file,

308
00:31:40,480 --> 00:31:47,120
comes back as a enum, which can be loading, failure or success. So it clearly is async

309
00:31:47,120 --> 00:31:55,120
because there is a loading state. And you are tasked with dealing with that loading state in

310
00:31:56,000 --> 00:32:03,440
your code. Interesting. Yeah, I guess that's kind of similar because the dependency system

311
00:32:03,440 --> 00:32:07,840
you mentioned is also very similar to the environment system in SwiftUI. So I'm guessing

312
00:32:07,840 --> 00:32:14,000
that's just to give people an impression that's what the API looks like effectively, isn't it?

313
00:32:14,000 --> 00:32:19,200
Yes. I should have thought of environment. I think it's just because we've been working

314
00:32:19,200 --> 00:32:26,160
with dependencies recently. Exactly. It's the thing that came to mind. But I like it. And I like

315
00:32:26,160 --> 00:32:34,320
that something, I guess this is a very specific use. The Singapore kit is only, you're only going

316
00:32:34,320 --> 00:32:40,240
to need that if you're writing an app that deals with Singapore data. But I do like the technique.

317
00:32:40,240 --> 00:32:44,320
Well, it might be interesting if you're building something similar for a different data domain or

318
00:32:44,320 --> 00:32:47,200
a different domain in general. Sure. Take a look at it.

319
00:32:47,200 --> 00:32:51,920
Interesting to inspect how it's done there. 100%. Yeah.

320
00:32:51,920 --> 00:33:01,840
My second pick is called Swift Glob. And it's by Tourist, but forked from the similar

321
00:33:01,840 --> 00:33:09,040
project by the same name by David Beck. And Tourist have taken this over. I think the other

322
00:33:09,040 --> 00:33:16,000
project has sort of not been maintained anymore. And it does what it says on the tin. So this

323
00:33:16,000 --> 00:33:24,960
gives you a Glob API for file name lookup. And by Glob, I mean, like the star thing, like the

324
00:33:24,960 --> 00:33:32,080
star.swift to match on all the Swift files in a directory. It also supports the double star slash

325
00:33:32,080 --> 00:33:39,360
syntax. So you have all the subdirectories and then it searches through those. I think it follows

326
00:33:39,360 --> 00:33:44,720
the, I think there's a standard around Globing how the syntax works and it's allegedly.

327
00:33:45,440 --> 00:33:52,080
Right. Yes. Compatible with that general standard. But this is like a really nice API,

328
00:33:52,080 --> 00:33:56,560
because to my knowledge, there is nothing like it currently in foundation. So you'd have to do your

329
00:33:56,560 --> 00:34:02,640
own, you know, get all the entries and then filter on them. And this just deals with that. And you

330
00:34:02,640 --> 00:34:08,400
can write really expressive file filters in your application if you need that sort of thing.

331
00:34:08,400 --> 00:34:14,080
Yeah, nice, nice API, very focused and easy to use.

332
00:34:14,080 --> 00:34:17,840
Great. Now it's time for my Dave recommendation.

333
00:34:17,840 --> 00:34:31,840
My final package this week is called gesture button by Daniel Seide. And it's a SwiftUI button

334
00:34:31,840 --> 00:34:37,280
that as the readme says, the gesture button is a SwiftUI button that can handle many different

335
00:34:37,280 --> 00:34:44,480
gestures. So it is just a button, but you can also add functionality on is pressed, press action,

336
00:34:44,480 --> 00:34:48,800
release inside action, release outside action, long press action, double tap action, repeat

337
00:34:48,800 --> 00:34:52,800
action, blah, blah, blah, blah, blah, lots of these, you know, even dragging and dropping

338
00:34:52,800 --> 00:35:00,960
and things like that. And it is a, an encapsulation, I think of all of the different things

339
00:35:00,960 --> 00:35:06,800
that were possible with the old UI button that maybe all of them haven't come across to

340
00:35:06,800 --> 00:35:13,600
SwiftUI yet. So if you want to do something slightly non-standard with a button, then

341
00:35:13,600 --> 00:35:21,760
this is the kind of package that is going to help you do that. My, my, my caveat to this is

342
00:35:21,760 --> 00:35:30,640
don't do weird things with buttons. And the reason I'm talking about it, because obviously if I just

343
00:35:30,640 --> 00:35:34,800
don't, if I just believe that you just shouldn't ever do weird things with buttons, then I just

344
00:35:34,800 --> 00:35:38,720
wouldn't talk about this package, right? But it is worth talking about because there are

345
00:35:38,720 --> 00:35:45,520
situations in apps all the time where you do just want to do something extra, a little bit extra

346
00:35:45,520 --> 00:35:51,120
with a button. Maybe it does drag off the screen. Maybe it does have a long press or something like

347
00:35:51,120 --> 00:35:55,840
that in addition to the short press or something like that. I can't think of any specific examples

348
00:35:55,840 --> 00:36:00,640
right now. And this kind of package is going to be better in those situations than rolling your

349
00:36:00,640 --> 00:36:08,880
own stuff at that point. But resist the temptation to go crazy with buttons because it is a common

350
00:36:08,880 --> 00:36:15,680
user interface gotcha to have buttons that don't behave like buttons and people expect to be able

351
00:36:15,680 --> 00:36:21,040
to just tap on a button and have it do a thing. And playing with that expectation is very risky

352
00:36:21,040 --> 00:36:26,240
in terms of whether people will be able to use your application. So I do like the package,

353
00:36:27,040 --> 00:36:31,600
but I also think you should be very cautious with your use of it.

354
00:36:31,600 --> 00:36:33,280
Yeah, I think that's great advice.

355
00:36:33,280 --> 00:36:39,280
All right. Well, my third pick is a Dave pick as well.

356
00:36:39,280 --> 00:36:51,760
And it's a package called StarCraft Kit by Marcus Ziedde. And I, this is super niche.

357
00:36:52,640 --> 00:37:00,400
You're really unlikely to ever use this, but I just saw the description. It says StarCraft Kit

358
00:37:00,400 --> 00:37:07,280
aims to be the go-to Swift package for developers working with the StarCraft 2 Pro scene. And I

359
00:37:07,280 --> 00:37:12,480
thought, well, it succeeded in that mission because I think it is the go-to Swift package

360
00:37:12,480 --> 00:37:20,560
for that purpose. It is number one in that list. But I also thought it's great that there are

361
00:37:21,600 --> 00:37:28,000
these packages being now served in the Swift ecosystem. Like, is this like super niche? I

362
00:37:28,000 --> 00:37:33,600
think. I mean, I know StarCraft is still big given that it's a... God, how old is that game? That's

363
00:37:33,600 --> 00:37:38,160
like 20, 30 years old? Yeah, it must be 30 even.

364
00:37:38,160 --> 00:37:43,280
No, I mean, StarCraft, the original StarCraft is that old, but I presume that's not StarCraft

365
00:37:43,280 --> 00:37:44,160
they're talking about.

366
00:37:44,160 --> 00:37:47,200
Well, StarCraft 2 is also old.

367
00:37:47,200 --> 00:37:50,000
It's not new. It's certainly more than 10 years old.

368
00:37:51,360 --> 00:37:56,960
But I know there's a tournament scene around that. But still, to see a package like that

369
00:37:56,960 --> 00:38:04,160
pop up is quite nice. I think it's really great to see that even these niches are now being served

370
00:38:04,160 --> 00:38:12,000
in the Swift ecosystem. That's why I thought I'd highlight it. It has a text user interface.

371
00:38:12,000 --> 00:38:20,080
I think there's a tournament site and data that you can crawl through and inspect and stuff and

372
00:38:20,080 --> 00:38:25,440
list and all sorts of stuff. Just have a look at it if you're interested in StarCraft and see what's

373
00:38:25,440 --> 00:38:26,080
going on there.

374
00:38:26,080 --> 00:38:32,480
I did have a look at this. And in fact, it was on my shortlist of packages to talk about this

375
00:38:32,480 --> 00:38:38,160
week, but it didn't make the final three for me. But yes, I thought it was great to see this. I

376
00:38:38,160 --> 00:38:42,800
think it uses... There's an API that it uses called PandaScore or something like that. I was

377
00:38:42,800 --> 00:38:48,160
reading the readme. And so it has... There's a web API behind the scenes where it's getting all

378
00:38:48,160 --> 00:38:55,120
this stuff from. But you're right, that this is the premier StarCraft stats package for Swift.

379
00:38:55,120 --> 00:38:56,080
- Nice.

380
00:38:56,080 --> 00:39:03,600
- Yeah, I think it's great to see all sorts of packages. You're right, I do like to bring

381
00:39:03,600 --> 00:39:12,000
the occasional obscure one that you might never use. Well, I've done many retro computing ones

382
00:39:12,000 --> 00:39:17,840
in the past. And is StarCraft 2 retro yet? I don't know. When does it become retro?

383
00:39:17,840 --> 00:39:26,080
- Oh, I'm sure it is. I'm just checking. The original StarCraft came out in '98. StarCraft 2,

384
00:39:26,080 --> 00:39:34,800
the expansion came out in 2010. So it must be... Oh no, 2010. So yeah, it's not the 20 years that

385
00:39:34,800 --> 00:39:35,200
I gave it.

386
00:39:35,200 --> 00:39:36,080
- Right, so 14 years.

387
00:39:36,080 --> 00:39:36,880
- Yeah, but still.

388
00:39:36,880 --> 00:39:38,800
- Yeah, old enough though.

389
00:39:38,800 --> 00:39:39,120
- Yeah.

390
00:39:39,120 --> 00:39:46,000
- Right, let's wrap it up there. And we will be back in a few weeks with more news from

391
00:39:46,000 --> 00:39:52,800
the package index and package recommendations or not recommendations as the case may be.

392
00:39:52,800 --> 00:39:56,640
But until then, we will say goodbye for now.

393
00:39:56,640 --> 00:39:58,400
- See you next time. Bye-bye.

394
00:39:58,400 --> 00:39:59,840
- All right, bye-bye.