1
00:00:00,000 --> 00:00:03,000
So it's been how long since we made the announcement?

2
00:00:03,000 --> 00:00:05,000
A bit over a week, right?

3
00:00:05,000 --> 00:00:08,000
And the response has been extremely positive.

4
00:00:08,000 --> 00:00:12,000
From what I've seen, I think people are delighted to see that,

5
00:00:12,000 --> 00:00:17,000
first of all, the package index is on a steadier footing when it comes to being around for the long term,

6
00:00:17,000 --> 00:00:22,000
but also that Apple are supporting this project, along with a whole load of other companies.

7
00:00:22,000 --> 00:00:25,000
And I think that's worth just talking about for a second.

8
00:00:25,000 --> 00:00:29,000
They were keen to join that set of sponsors rather than replace them.

9
00:00:29,000 --> 00:00:33,680
them. So our GitHub sponsorship is still really important to us, the sponsorship

10
00:00:33,680 --> 00:00:37,760
of Stream and Emerge tools is really important to us, and of course the

11
00:00:37,760 --> 00:00:43,040
infrastructure sponsorship of Microsoft and Mac Stadium remains completely

12
00:00:43,040 --> 00:00:49,200
integral to how we keep this project running. What we've done is expanded the

13
00:00:49,200 --> 00:00:53,200
amount of companies that are supporting the project rather than replaced

14
00:00:53,200 --> 00:00:57,680
everybody with Apple. Yeah absolutely, feedback has been really great, just

15
00:00:57,680 --> 00:01:02,560
great to have that in place and take some of our concerns away.

16
00:01:02,560 --> 00:01:06,840
When we were planning out the project, we sort of had some early timelines

17
00:01:06,840 --> 00:01:10,520
where we thought, how long can we run this given what support we had at the

18
00:01:10,520 --> 00:01:16,520
time, and it's really a great relief to have this additional support by Apple

19
00:01:16,520 --> 00:01:21,760
to give us that long-term trajectory and giving us the assurance that we can

20
00:01:21,760 --> 00:01:23,800
keep running this site and also growing it.

21
00:01:23,800 --> 00:01:26,200
And that's actually probably something we should also mention.

22
00:01:26,680 --> 00:01:29,640
The site growth just over the last week has been tremendous.

23
00:01:29,640 --> 00:01:37,220
The influx of unique users on the day alone was a record, but also since then,

24
00:01:37,220 --> 00:01:42,160
the levels of unique visitors and page views has been a lot higher than previously.

25
00:01:42,160 --> 00:01:43,920
And that's just really great to see.

26
00:01:43,920 --> 00:01:45,640
And package submissions as well.

27
00:01:45,640 --> 00:01:46,200
Oh yes.

28
00:01:46,200 --> 00:01:49,680
We've woken up lots of people who were sitting on their packages, probably just

29
00:01:49,680 --> 00:01:54,600
waiting to see if we're going to be around or what's the status of that project.

30
00:01:54,600 --> 00:01:58,280
And then they all clicked on that button, just submit their packages.

31
00:01:58,280 --> 00:01:59,880
And it's been absolutely wild.

32
00:01:59,880 --> 00:02:05,940
But seriously, though, I say this to everybody who, whenever I talk about

33
00:02:05,940 --> 00:02:11,520
marketing, you cannot talk about your project enough, like you may get sick

34
00:02:11,520 --> 00:02:17,580
of hearing yourself talk about it, but, but it's impossible to, you know, I

35
00:02:17,580 --> 00:02:23,020
would say that we were running a fairly successful project already, and yet the

36
00:02:23,020 --> 00:02:25,540
number of people who had no idea it existed.

37
00:02:25,540 --> 00:02:30,380
We were both on a Slack where somebody was talking about the announcement and

38
00:02:30,380 --> 00:02:31,940
we were on that thread in the Slack.

39
00:02:31,940 --> 00:02:35,660
And I think there were a couple of people in that thread who didn't know about

40
00:02:35,660 --> 00:02:39,100
packageindex.com before, before this announcement.

41
00:02:39,100 --> 00:02:40,820
Inconceivable.

42
00:02:40,820 --> 00:02:49,300
And also they actually only saw the announcement through that thread in the

43
00:02:49,300 --> 00:02:52,300
Slack, like you can't talk about it enough.

44
00:02:52,300 --> 00:02:52,700
Yeah.

45
00:02:52,740 --> 00:02:54,020
You can't talk about it enough.

46
00:02:54,020 --> 00:02:59,880
Even an official post on swift.org is only part of the story.

47
00:02:59,880 --> 00:03:01,860
And of course it was also nice to see.

48
00:03:01,860 --> 00:03:06,940
It's a nice moment of recognition to have any post on a swift.org.

49
00:03:06,940 --> 00:03:10,380
Have your name against it, but it was nice to see both of our

50
00:03:10,380 --> 00:03:12,100
names up there on the swift.org too.

51
00:03:12,100 --> 00:03:13,340
Yeah, that was really great.

52
00:03:13,340 --> 00:03:17,140
So we asked whether the community had any questions about the

53
00:03:17,140 --> 00:03:18,980
announcement or about the funding.

54
00:03:19,340 --> 00:03:22,260
And we had a few people get in touch with questions.

55
00:03:22,260 --> 00:03:26,180
Actually, mainly the questions come from contributors and people who are quite

56
00:03:26,180 --> 00:03:28,260
close to the project, which of course you would expect.

57
00:03:28,260 --> 00:03:31,380
And so I think we should go through some of these questions.

58
00:03:31,380 --> 00:03:36,420
So the first question is from James Sherlock, who is a regular

59
00:03:36,420 --> 00:03:37,740
contributor to the project.

60
00:03:37,740 --> 00:03:39,580
Thank you, James, for all of your contributions.

61
00:03:39,580 --> 00:03:44,860
Um, his first question is aside from improved financial safety, what else,

62
00:03:44,860 --> 00:03:47,820
if anything, are you hoping to get out of the relationship?

63
00:03:47,820 --> 00:03:56,820
So I think a big part of that is something I just touched upon, it's more visibility and more reach as the place to go for packages.

64
00:03:56,820 --> 00:04:12,820
So as I just mentioned, we already have seen that effect straight away that we got a lot more visibility and I think people like the assurance that we're closely associated with Swift.org and are the place to go for packages.

65
00:04:12,820 --> 00:04:17,900
packages. And it also validates our work. It's just great to see that this is seen,

66
00:04:17,900 --> 00:04:23,520
the project has been seen as a component in the Swift ecosystem. I think that's just great.

67
00:04:23,520 --> 00:04:30,360
It also gives us a line of communication into Apple, which we now have with the Swift team.

68
00:04:30,360 --> 00:04:33,080
And that in itself is very valuable.

69
00:04:33,080 --> 00:04:39,820
The second question is by Marin Todorov. And it is, how did the process happen? Who initiated

70
00:04:39,820 --> 00:04:42,100
it? What was it like?

71
00:04:42,100 --> 00:04:47,720
We talked to Tom Doran years ago now when package collections were being

72
00:04:47,720 --> 00:04:49,320
put into the package manager.

73
00:04:49,320 --> 00:04:56,960
And if you might remember that Swift package index was featured in a WWDC

74
00:04:56,960 --> 00:05:04,900
video, I think in 2021, if I remember rightly, and that was the year

75
00:05:04,900 --> 00:05:06,420
the package collections came out.

76
00:05:06,420 --> 00:05:10,220
And we knew package collections were coming out in the Swift package manager

77
00:05:10,220 --> 00:05:11,580
because that's all open source.

78
00:05:11,580 --> 00:05:17,480
And we launched our support for package collections on day one or around day one.

79
00:05:17,480 --> 00:05:18,700
So we were right there.

80
00:05:18,700 --> 00:05:22,460
What we didn't know of course, was that package collections would

81
00:05:22,460 --> 00:05:24,680
also be supported in Xcode.

82
00:05:24,680 --> 00:05:26,220
I've already gone down a rabbit hole here.

83
00:05:26,220 --> 00:05:31,940
So anyway, so we've been having conversations with Tom around package

84
00:05:31,940 --> 00:05:36,100
collections, but that was nothing to do with funding or anything like that.

85
00:05:36,100 --> 00:05:39,420
But that was the beginning of that relationship where we actually started

86
00:05:39,420 --> 00:05:40,920
to talk to, to Apple.

87
00:05:40,920 --> 00:05:45,120
We then initiated the conversation around funding.

88
00:05:45,120 --> 00:05:46,300
I think it's no secret.

89
00:05:46,300 --> 00:05:53,480
We've written on our blog many times that this project demands much more than

90
00:05:53,480 --> 00:05:56,120
your average open source project, which is just code.

91
00:05:56,120 --> 00:05:59,200
So the fact that there is a website to maintain, the fact that there is an

92
00:05:59,200 --> 00:06:04,920
entire build system on the backend means that as an open source project, it

93
00:06:04,920 --> 00:06:09,400
definitely it requires constant attention and constant maintenance.

94
00:06:09,400 --> 00:06:12,000
Whereas with a code-based open source project, you might be able to

95
00:06:12,000 --> 00:06:13,360
take some time away from it.

96
00:06:13,360 --> 00:06:15,600
That's not something we're able to do.

97
00:06:15,600 --> 00:06:19,800
And so, yeah, we reached out and said, look, we, we wonder if you have any

98
00:06:19,800 --> 00:06:21,960
interest in, in helping support the project.

99
00:06:21,960 --> 00:06:23,520
Yeah.

100
00:06:23,520 --> 00:06:24,720
And maybe we should add it.

101
00:06:24,720 --> 00:06:29,820
It almost felt like we were running into an open door because the feedback we got

102
00:06:29,820 --> 00:06:34,040
is we were aware of what you're doing and really interested in, in having that

103
00:06:34,040 --> 00:06:34,540
discussion.

104
00:06:34,540 --> 00:06:43,040
The other thing I want to say here is that the support that we received from Ted Kremenek and Tom Doran was incredible.

105
00:06:43,040 --> 00:06:55,040
They were nothing but helpful at every stage of the conversation and I want to thank them personally for all of their help to get to the fact that Apple now supports the project.

106
00:06:55,040 --> 00:07:02,760
Yeah. And at every point it was really important or is still is very clear that open source

107
00:07:02,760 --> 00:07:07,120
and the swift aspect of open source and the ecosystem is really important to them. I think

108
00:07:07,120 --> 00:07:12,440
that can't be overstated. And I think that reflects also in this support for the index.

109
00:07:12,440 --> 00:07:18,600
Yeah, that comes across very clearly every time we talked. Back to James Sherlock for

110
00:07:18,600 --> 00:07:23,160
the next question. And in fact, the next several questions are from James. James asks, is the

111
00:07:23,160 --> 00:07:28,380
agreement time-bound or is there some other limit on the agreement? Without

112
00:07:28,380 --> 00:07:34,560
going into specifics, any agreement of this kind would be time-bound. I think

113
00:07:34,560 --> 00:07:38,040
that's very clear that this isn't... Are you trying to tell me Sven that they

114
00:07:38,040 --> 00:07:43,360
haven't promised to support this project until the end of the internet? Well I'm

115
00:07:43,360 --> 00:07:50,640
I'm hoping you tell me about a clause that I didn't see where it says that, but unfortunately I think that's not the case.

116
00:07:50,640 --> 00:07:55,080
No, but it's a good question. It is a good question, but it's clear an agreement like

117
00:07:55,080 --> 00:08:01,260
this has a period, but it also has the opportunity to be renewed and we're not expecting this

118
00:08:01,260 --> 00:08:04,600
to be a short-term relationship.

119
00:08:04,600 --> 00:08:10,240
And the surrounding circumstances change, right? I mean, whenever that comes up for

120
00:08:10,240 --> 00:08:16,400
renewal, that sort of thing, the packet index might have very different usage, for instance,

121
00:08:16,400 --> 00:08:22,500
then require different kind of time investments or hosting investments and that sort of thing.

122
00:08:22,500 --> 00:08:26,460
And that's something you can't lock in at the moment for however many years down the

123
00:08:26,460 --> 00:08:27,460
line.

124
00:08:27,460 --> 00:08:28,460
That's just the nature of things.

125
00:08:28,460 --> 00:08:32,260
You need to keep that in mind when you set this sort of thing up.

126
00:08:32,260 --> 00:08:33,260
All right.

127
00:08:33,260 --> 00:08:38,100
So the next question by James is, this is the first agreement of its kind that I've

128
00:08:38,100 --> 00:08:39,380
seen.

129
00:08:39,380 --> 00:08:41,500
What barriers did you have to break down?

130
00:08:41,500 --> 00:08:43,780
What level in the business did it reach?

131
00:08:43,780 --> 00:08:45,460
Timothy get involved.

132
00:08:45,460 --> 00:08:49,100
Timothy being Tim Cook here.

133
00:08:49,100 --> 00:08:53,060
I can confidently say that Tim Cook was not involved in this.

134
00:08:53,060 --> 00:08:54,980
Although, of course, we have no idea.

135
00:08:54,980 --> 00:08:58,180
I'm pretty sure he was not involved in this.

136
00:08:58,180 --> 00:09:01,580
I would hope Tim Cook was not involved with this.

137
00:09:01,580 --> 00:09:04,540
I'm confident that Tim would value the work that we did

138
00:09:04,540 --> 00:09:06,900
for this fifth ecosystem greatly.

139
00:09:06,900 --> 00:09:11,580
But I am almost certain he was not involved.

140
00:09:11,580 --> 00:09:13,500
So dealing with a company of apple size

141
00:09:13,500 --> 00:09:18,700
naturally a complex process and you can imagine a number of people would be involved in signing

142
00:09:18,700 --> 00:09:24,100
that off. Throughout the process, effectively, our chief weapon was patience because it just

143
00:09:24,100 --> 00:09:27,140
takes very long to have these sorts of discussions.

144
00:09:27,140 --> 00:09:34,000
You're right that patience was definitely needed, but also this project felt important

145
00:09:34,000 --> 00:09:42,140
to Ted and Tom as well. And without them fighting our cause, I think you're right that this

146
00:09:42,140 --> 00:09:47,820
is an unusual agreement for any large company to support an open source

147
00:09:47,820 --> 00:09:52,460
project like this. It's going to be no secret to anyone listening that you need

148
00:09:52,460 --> 00:09:57,500
somebody inside the company who believes in what you're doing and those people in

149
00:09:57,500 --> 00:09:59,020
this instance were Ted and Tom.

150
00:09:59,020 --> 00:10:04,740
The next question by James is, do you think your partnership has opened

151
00:10:04,740 --> 00:10:09,700
doors for other open source projects to achieve similar levels of support?

152
00:10:09,700 --> 00:10:10,900
That's a great question.

153
00:10:10,900 --> 00:10:12,320
And I would say, I hope so.

154
00:10:12,320 --> 00:10:16,640
It's not our place to speak for Apple here, but I think any big company supporting an

155
00:10:16,640 --> 00:10:21,560
open source project that benefits both the project and the company is a wonderful thing

156
00:10:21,560 --> 00:10:22,560
to see.

157
00:10:22,560 --> 00:10:29,940
And I personally hope that all big companies look at what we have arranged here with Apple

158
00:10:29,940 --> 00:10:33,860
and decide that they can do similar things in whatever ecosystem they're working in.

159
00:10:33,860 --> 00:10:34,860
Yeah.

160
00:10:34,860 --> 00:10:45,860
I mean, it's a recurring theme that you see on social networks where open source projects are looking for support and often complaining that it's really hard to keep running.

161
00:10:45,860 --> 00:10:49,860
And often it's just a labor of love that isn't financially viable.

162
00:10:49,860 --> 00:10:56,860
People do it anyway often because they hope for some future support or employment, that sort of thing.

163
00:10:56,860 --> 00:11:00,860
But it is very common for open source projects to be struggling.

164
00:11:00,860 --> 00:11:05,860
And some people succeed, but it's often around the person

165
00:11:05,860 --> 00:11:08,460
and their particular skills that make that succeed

166
00:11:08,460 --> 00:11:11,480
or the avenues they choose to find that support.

167
00:11:11,480 --> 00:11:13,900
So I think there's a problem to be solved.

168
00:11:13,900 --> 00:11:17,140
And I'm not saying that we found that solution,

169
00:11:17,140 --> 00:11:19,320
but it is a path.

170
00:11:19,320 --> 00:11:26,180
And hopefully there are more instances where that works out

171
00:11:26,340 --> 00:11:32,700
because just so much is built on open source and the value of the open source

172
00:11:32,700 --> 00:11:37,220
projects are reaped by these big companies that it feels like it should

173
00:11:37,220 --> 00:11:42,120
be easier for big companies to, to turn that around and also support these

174
00:11:42,120 --> 00:11:43,100
open source projects.

175
00:11:43,100 --> 00:11:47,760
There's been plenty of examples of open source projects that were very

176
00:11:47,760 --> 00:11:52,600
important to very large companies that, that were not being supported in

177
00:11:52,600 --> 00:11:54,760
anywhere near appropriate levels.

178
00:11:54,760 --> 00:11:59,800
like for example there was the log4j

179
00:11:59,800 --> 00:12:02,000
vulnerability that when obviously the

180
00:12:02,000 --> 00:12:03,560
vulnerability is a separate issue and all

181
00:12:03,560 --> 00:12:05,680
projects have vulnerabilities and that

182
00:12:05,680 --> 00:12:07,960
wasn't the problem but what came out of

183
00:12:07,960 --> 00:12:09,840
that was that log4j project was not

184
00:12:09,840 --> 00:12:13,080
receiving enough support and it was at

185
00:12:13,080 --> 00:12:16,280
the heart of every big tech company's

186
00:12:16,280 --> 00:12:19,320
infrastructure. Next question is again by

187
00:12:19,320 --> 00:12:21,720
James. Has Apple applied any restrictions

188
00:12:21,720 --> 00:12:24,000
to what can be done by the Swift

189
00:12:21,720 --> 00:12:28,080
package index or what contributions can be made. Is this the real reason for CLAs,

190
00:12:28,080 --> 00:12:33,320
CLA being contributor license agreements, that we have in place on our GitHub project?

191
00:12:33,320 --> 00:12:38,760
This is a very easy question to answer. In fact, there's a couple of

192
00:12:38,760 --> 00:12:43,400
questions here. The first part, have they applied any restrictions? Absolutely not.

193
00:12:43,400 --> 00:12:50,400
No, nothing changes on the open source side of this project. I don't think that

194
00:12:50,400 --> 00:12:57,440
topic even came up. And then your question about the CLA is also no. So the CLA has happened,

195
00:12:57,440 --> 00:13:01,840
so just to actually give a little bit of background there for people who are not familiar with this,

196
00:13:01,840 --> 00:13:08,320
a good couple of years ago now, we changed the licensing of the package index open source

197
00:13:08,320 --> 00:13:16,640
project. It was originally licensed, I think, as MIT. And I think as with many open source projects,

198
00:13:16,640 --> 00:13:20,240
Not enough thought is given to licensing at the point where you start the project.

199
00:13:20,240 --> 00:13:22,320
Like we definitely knew it was open source.

200
00:13:22,320 --> 00:13:24,380
We'd both liked the MIT license.

201
00:13:24,380 --> 00:13:29,040
I generally, MIT would be my, my, my default license to go to when

202
00:13:29,040 --> 00:13:30,360
I want to open source something.

203
00:13:30,360 --> 00:13:35,400
But actually it didn't fit particularly well with what we were

204
00:13:35,400 --> 00:13:37,040
trying to do with the project.

205
00:13:37,040 --> 00:13:41,160
And when we realized that we needed a little bit more structure

206
00:13:41,160 --> 00:13:45,440
to our open source licensing, I did have a look at what the Swift project used,

207
00:13:45,620 --> 00:13:53,380
But that was only part of the decision to choose Apache 2 and the Apache 2 CLA.

208
00:13:53,380 --> 00:13:57,680
So a CLA is a contributor license agreement.

209
00:13:57,680 --> 00:14:05,060
And really the reason that we put these CLAs in place is that what we wanted to

210
00:14:05,060 --> 00:14:12,060
make sure is that anybody who contributed to the project had the permission

211
00:14:12,060 --> 00:14:13,260
to contribute to the project.

212
00:14:13,360 --> 00:14:17,440
So if you contribute to the Swift package index open source project, your

213
00:14:17,440 --> 00:14:19,600
contributions remain your own.

214
00:14:19,600 --> 00:14:23,020
They are still yours, even with a contributor license agreement.

215
00:14:23,020 --> 00:14:27,520
A lot of people think that contributor license agreements assign the IP of

216
00:14:27,520 --> 00:14:29,240
the contribution to the project.

217
00:14:29,240 --> 00:14:30,800
That's actually not the case.

218
00:14:30,800 --> 00:14:35,600
What they do as I understand, I'm not a lawyer, but as I understand it, the

219
00:14:35,600 --> 00:14:42,440
main thing that they do in this instance is they give us the confidence that you

220
00:14:42,440 --> 00:14:45,240
had the permission to make that contribution.

221
00:14:45,240 --> 00:14:49,900
So for example, if you work for a big company, let's say Google.

222
00:14:49,900 --> 00:14:53,880
I'm not picking Google for any specific reason, but they're just a big, a large

223
00:14:53,880 --> 00:15:00,100
tech company and you use a Google laptop and you're being paid by Google as you

224
00:15:00,100 --> 00:15:04,140
make a contribution to the Swiss package index, the contributor license agreement

225
00:15:04,140 --> 00:15:07,060
is your declaration that you basically didn't do that.

226
00:15:07,060 --> 00:15:11,820
And it makes sure that the IP is clean to go into the project rather than

227
00:15:12,000 --> 00:15:17,680
assigning us the IP, but that was really just part of this project becoming more

228
00:15:17,680 --> 00:15:22,560
serious and part of us putting a few protections in to the project.

229
00:15:22,560 --> 00:15:24,200
And it was nothing to do with Apple.

230
00:15:24,200 --> 00:15:25,840
Nothing to do with them.

231
00:15:25,840 --> 00:15:26,760
Okay.

232
00:15:26,760 --> 00:15:31,860
I think the last question we have is from Joe Heck, who is also

233
00:15:31,860 --> 00:15:33,560
a contributor to the project.

234
00:15:33,560 --> 00:15:38,820
He says, I don't know how much support by Apple intermix is interbound by

235
00:15:38,820 --> 00:15:42,880
the same rules as Apple employees, but I'd love to hear a bit on your opinion

236
00:15:42,880 --> 00:15:46,960
of how the famously closed source only company is growing to embrace more

237
00:15:46,960 --> 00:15:51,060
community and open source aspects of development and how package index fits

238
00:15:51,060 --> 00:15:54,980
into that expansion. I think we've touched on this a couple of times how

239
00:15:54,980 --> 00:16:00,020
very clear it's been in our discussions that the open source aspects are core to

240
00:16:00,020 --> 00:16:05,400
what Apple and Swift.org are doing and I think that's very clearly reflected in

241
00:16:05,400 --> 00:16:10,400
just how many open-source packages Apple have created. If you look at the Swift

242
00:16:10,400 --> 00:16:15,800
package index, there are currently 57 packages by Apple in the index. Apple are the

243
00:16:15,800 --> 00:16:20,520
most prolific open-source Swift package authors according to our tracking. I

244
00:16:20,520 --> 00:16:25,440
think all of this speaks to the strategy and that's actually, if you think about it,

245
00:16:25,440 --> 00:16:30,240
a very familiar strategy by Apple. If you look at built-in apps on the iPhone,

246
00:16:30,240 --> 00:16:36,880
Apple's signature move is to provide the foundation, like weather, notes, reminders,

247
00:16:36,880 --> 00:16:41,920
like foundational features and apps, but then also leave lots of room for third parties

248
00:16:41,920 --> 00:16:44,320
to add on top of that.

249
00:16:44,320 --> 00:16:48,320
And it's very clear that the same is happening here in the open source space, like the very

250
00:16:48,320 --> 00:16:54,840
foundational libraries and services like Swift itself, Swift Package Manager, Neo driving

251
00:16:54,840 --> 00:16:59,720
all of the server-side Swift ecosystem, the package registry,

252
00:16:59,720 --> 00:17:02,960
and the index is sort of naturally falling into this space.

253
00:17:02,960 --> 00:17:07,520
I think this all lines up very, very nicely and very clearly

254
00:17:07,520 --> 00:17:12,040
what the plans are here and what the expansion space really is.

255
00:17:12,040 --> 00:17:15,560
I think that rounds out our questions, doesn't it?

256
00:17:15,560 --> 00:17:16,480
It does.

257
00:17:16,480 --> 00:17:19,080
We are definitely running long today.

258
00:17:19,080 --> 00:17:21,160
I can see by the time on the clock

259
00:17:21,160 --> 00:17:23,280
that we're not going to hit our length target today.

260
00:17:23,280 --> 00:17:27,160
So let's maybe keep the package recommendations a little shorter today.

261
00:17:27,160 --> 00:17:29,000
Do you want to kick us off with your first one?

262
00:17:29,000 --> 00:17:30,360
Yes.

263
00:17:30,360 --> 00:17:34,740
So the first one is called Crayon and it's by David Walter.

264
00:17:34,740 --> 00:17:39,400
And that's a really nice package for dealing with colors and color aspects.

265
00:17:39,400 --> 00:17:46,460
It is very similar in API to the color from SwiftUI and then has extensions on

266
00:17:46,460 --> 00:17:49,720
it, like is dark, is light, contrast.

267
00:17:49,740 --> 00:17:53,700
So you can get contrast values out of it and like a Boolean, whether you have

268
00:17:53,700 --> 00:17:57,900
enough contrast, like for accessibility, that sort of thing, and also gives you

269
00:17:57,900 --> 00:18:03,500
extensions to do color manipulation, like negative, inverted, saturated,

270
00:18:03,500 --> 00:18:04,980
desaturated, that sort of thing.

271
00:18:04,980 --> 00:18:11,540
So that's a really nice package for colors and it's called Crayon by David Walter.

272
00:18:11,540 --> 00:18:14,980
I would love to have this package in CSS.

273
00:18:14,980 --> 00:18:17,900
Darkening and lightening the colors.

274
00:18:18,060 --> 00:18:22,300
You can do it in SAS, which is the pre-process of a CSS, but the way that

275
00:18:22,300 --> 00:18:25,860
we do colors on the package index, we're doing our colors in pure CSS.

276
00:18:25,860 --> 00:18:27,700
And I would love a library like this.

277
00:18:27,700 --> 00:18:30,040
Okay.

278
00:18:30,040 --> 00:18:36,140
My first package this week is a package that is called with, and

279
00:18:36,140 --> 00:18:38,460
it's by Slip Douglas Thompson.

280
00:18:38,460 --> 00:18:44,580
So this package reminded me of a language feature of C#.

281
00:18:45,500 --> 00:18:49,540
I, this has been a very long time since I did any C# development, but I was

282
00:18:49,540 --> 00:18:54,920
at one point a C# developer, and there was a statement in the language called

283
00:18:54,920 --> 00:18:59,520
with, that basically says you can declare a variable and say with this newly

284
00:18:59,520 --> 00:19:05,220
declared variable, do something with it before you complete the initialization

285
00:19:05,220 --> 00:19:07,960
of this object or this variable.

286
00:19:07,960 --> 00:19:11,000
And it's a really nice technique.

287
00:19:11,000 --> 00:19:13,100
And you can do this already in Swift.

288
00:19:13,100 --> 00:19:19,080
You can say let X equals and then open up an inline closure and return

289
00:19:19,080 --> 00:19:23,380
something from that closure and that's your initiated object, but you have

290
00:19:23,380 --> 00:19:27,420
to do that with thing where you do the kind of braces and then the round brackets

291
00:19:27,420 --> 00:19:28,940
at the end to make it into a closure.

292
00:19:28,940 --> 00:19:34,260
And what this does is it's not a with statement like it was in C#, but it's

293
00:19:34,260 --> 00:19:39,440
a with function where you get a closure that you can do something with.

294
00:19:40,100 --> 00:19:43,620
and whatever comes out of that closure gets returned as the value.

295
00:19:43,620 --> 00:19:49,020
And I found that a useful tool 15, 20 years ago in C#,

296
00:19:49,020 --> 00:19:52,740
and I find it a useful tool with inline closures in Swift,

297
00:19:52,740 --> 00:19:55,500
and this just gives a little bit more structure to that.

298
00:19:55,500 --> 00:19:58,700
Yeah, what I really like about that pattern is that it scopes,

299
00:19:58,700 --> 00:20:00,900
like configuration you might have to do on an object,

300
00:20:00,900 --> 00:20:04,020
it really scopes it together and it's easy to see,

301
00:20:04,020 --> 00:20:07,380
and I'll group it together and not have a variable leaking around

302
00:20:07,380 --> 00:20:10,980
that you really just use temporarily to set something up.

303
00:20:10,980 --> 00:20:12,060
- It's not a big library.

304
00:20:12,060 --> 00:20:15,660
In fact, it even describes itself as a micro library.

305
00:20:15,660 --> 00:20:18,500
So it does one thing and that's all it does.

306
00:20:18,500 --> 00:20:20,860
It has documentation, it has a good readme file.

307
00:20:20,860 --> 00:20:22,740
It's been in development for three years

308
00:20:22,740 --> 00:20:25,160
and only has seven stars.

309
00:20:25,160 --> 00:20:28,340
In fact, I'm gonna go right now and give it a star.

310
00:20:28,340 --> 00:20:30,540
- Excellent, live starring.

311
00:20:30,540 --> 00:20:33,100
- Done.

312
00:20:33,100 --> 00:20:34,180
- Excellent.

313
00:20:34,180 --> 00:20:40,220
So my second package is a package you also mentioned on iOS Dev Weekly last week,

314
00:20:40,220 --> 00:20:43,340
but I will say I actually had it in my list before that.

315
00:20:43,340 --> 00:20:46,340
You were using it before it was cool, right?

316
00:20:46,340 --> 00:20:48,700
Exactly.

317
00:20:48,700 --> 00:20:50,620
I'm always on the fence with this sort of stuff.

318
00:20:50,620 --> 00:20:54,700
Everything is about chat GPT and I am ambivalent about that whole AI.

319
00:20:54,700 --> 00:20:57,580
We had an episode where we talked about this a little bit,

320
00:20:57,580 --> 00:21:00,380
but there is clearly something there.

321
00:21:00,380 --> 00:21:02,900
I mean, this is not cryptocurrencies.

322
00:21:02,900 --> 00:21:06,500
I don't want to open up that kind of worms, but there is clearly something there.

323
00:21:06,500 --> 00:21:09,700
There's already use cases that you can see.

324
00:21:09,700 --> 00:21:13,300
I don't think they are the ones that are commonly thrown around.

325
00:21:13,300 --> 00:21:18,620
Well, we're not going to talk about it this week, but we actually have been discussing

326
00:21:18,620 --> 00:21:24,180
whether there is a usage for the chat GPC API within Swift Package Index.

327
00:21:24,180 --> 00:21:26,260
And I'll leave that as a little teaser.

328
00:21:26,260 --> 00:21:31,860
We didn't look for a reason to use chat VPC like a lot of like a lot of projects

329
00:21:31,860 --> 00:21:36,180
are looking for reasons to do it. But actually, there's something that, and like I say, we'll

330
00:21:36,180 --> 00:21:40,660
tease this for a future episode, but there's something that we could legitimately use it for,

331
00:21:40,660 --> 00:21:45,460
and it's already, from our little experimentation with it, it's doing a really good job at what

332
00:21:45,460 --> 00:21:51,140
we wanted it to do. Yeah, and I think that that area is summarization, because that steps around

333
00:21:51,140 --> 00:21:57,940
a lot of the problems with AI. But back to the packages I wanted to recommend, and that's called

334
00:21:57,940 --> 00:22:07,860
DocCGPT, it's by Gonzalo Nunes, and it is a tool to generate documentation for your package.

335
00:22:07,860 --> 00:22:11,940
It's not a library, it's an executable that you run on your package, and it will

336
00:22:11,940 --> 00:22:18,580
stub out documentation on your properties, methods, functions, classes, structs,

337
00:22:18,580 --> 00:22:25,700
everything really. And the really nice thing about that is, and I've tried this with a Swift

338
00:22:25,700 --> 00:22:31,020
package index it does a really good job, an initial pass to give you something

339
00:22:31,020 --> 00:22:36,980
and even if you might have to edit the preamble more, the thing that I can see

340
00:22:36,980 --> 00:22:41,860
this help with is just dealing with the parameters and the return values but a

341
00:22:41,860 --> 00:22:46,340
lot of times when I actually start documenting something and I'm happy to

342
00:22:46,340 --> 00:22:50,660
write that one-liner that explains what this does but I get really annoyed

343
00:22:50,660 --> 00:22:56,260
having to then pick out all the parameters that often have very obvious names already.

344
00:22:56,260 --> 00:23:00,500
So I almost think like, leave me alone, the parameter speaks for itself as does the return.

345
00:23:00,500 --> 00:23:05,700
Well, you just let me write that one line and then be done with it. But you can't really do that.

346
00:23:05,700 --> 00:23:11,220
If you try to document it properly, you can't really leave those blank. And I can see this

347
00:23:11,220 --> 00:23:17,300
being really powerful and giving, at the very least, giving you those stubs. But actually,

348
00:23:17,300 --> 00:23:23,540
I found the one line is to be really good as well. So I think you can get, you can go a really long

349
00:23:23,540 --> 00:23:29,620
way taking the tedium out of documentation and actually allowing to use the edge cases,

350
00:23:29,620 --> 00:23:36,260
the special things about functions that you might actually, that's the strongest reason to document

351
00:23:36,260 --> 00:23:42,740
something. Because it's not the return types or the input and parameter types, because those are

352
00:23:42,740 --> 00:23:46,740
often documented by the Swift language types already.

353
00:23:46,740 --> 00:23:49,740
It's about why you might want to use a function

354
00:23:49,740 --> 00:23:52,240
or why you might not want to use a function.

355
00:23:52,240 --> 00:23:54,240
When is it good or bad?

356
00:23:54,240 --> 00:23:56,740
What are the special things about that?

357
00:23:56,740 --> 00:24:00,240
And I think tools like this free your time

358
00:24:00,240 --> 00:24:02,240
to deal with those kinds of things.

359
00:24:02,240 --> 00:24:05,240
And I think that's where a lot of the power of AI lies,

360
00:24:05,240 --> 00:24:06,740
to take the tedium away.

361
00:24:06,740 --> 00:24:08,740
And I'll get off my soapbox now.

362
00:24:08,740 --> 00:24:09,740
- I agree.

363
00:24:09,740 --> 00:24:11,240
And I also, like you said,

364
00:24:11,240 --> 00:24:17,240
I linked to this in IOSWP. I think this is a great package that will give you a really solid

365
00:24:17,240 --> 00:24:22,600
starting point for documentation and take away some of that tedium. You might ask, what's the

366
00:24:22,600 --> 00:24:28,520
value in documentation that is so obvious that it could be derived? But actually, there is value in

367
00:24:28,520 --> 00:24:36,040
it. My second recommendation this week is TrustKit by, I presume this is a company, Data Theorem.

368
00:24:36,840 --> 00:24:44,040
TrustKit is an open source framework that basically helps you with SSL public key pinning.

369
00:24:44,040 --> 00:24:52,440
This is a technique that prevents man-in-the-middle attacks. You basically verify the identity of the

370
00:24:52,440 --> 00:24:57,720
SSL certificate that you are expecting to be on the server that you're communicating with,

371
00:24:57,720 --> 00:25:03,640
with a network request, and you can guarantee then that you're talking to the correct server

372
00:25:03,640 --> 00:25:07,640
and not somebody pretending to be the server that you think you're talking to.

373
00:25:07,640 --> 00:25:13,240
This has been possible for a long time, and in fact this package has been in development for

374
00:25:13,240 --> 00:25:21,880
eight years. So it's a well-established package and it makes that process of pinning SSL keys

375
00:25:21,880 --> 00:25:26,760
or verifying that you're talking to the right server much easier than it would be. You define

376
00:25:27,320 --> 00:25:35,080
the hashes that you are expecting to find in your info.plist, and then you're given a method to then

377
00:25:35,080 --> 00:25:41,000
basically be able to say, "Verify this." So this is the kind of package that solves a problem

378
00:25:41,000 --> 00:25:48,280
that you might be tempted to skip if you are rushing through to a first release. Whereas

379
00:25:48,280 --> 00:25:53,400
you might think, "Well, yes, I know I should pin my SSL certificates, but I'll do that later."

380
00:25:53,400 --> 00:25:56,360
Here's a package that makes it relatively trivial to do that.

381
00:25:56,360 --> 00:25:59,320
Well, you had me at "makes it easier to work with SSL"

382
00:25:59,320 --> 00:26:02,760
because that always gives me nightmares.

383
00:26:02,760 --> 00:26:10,360
My third and last pick is called Polykit by Anton Hestand.

384
00:26:10,360 --> 00:26:14,360
And that package is very easy to talk about

385
00:26:14,360 --> 00:26:17,880
because what it does, it gives you rounded polygons in SwiftUI.

386
00:26:17,880 --> 00:26:21,800
Just look at the readme, it draws out a few shapes and it's really nice.

387
00:26:21,800 --> 00:26:27,080
You get rounded triangles, squares, that sort of thing, hexagons.

388
00:26:27,080 --> 00:26:33,960
Very easy to use, very painless, and it saves you from a lot of pixel math,

389
00:26:33,960 --> 00:26:35,600
and it looks really nice.

390
00:26:35,600 --> 00:26:38,680
- That is an extremely targeted package,

391
00:26:38,680 --> 00:26:43,240
but I can't imagine an easier way to make that kind of shape.

392
00:26:43,240 --> 00:26:44,760
- That's great.

393
00:26:44,760 --> 00:26:47,720
All right, that's Polykit by Anton Hestand.

394
00:26:47,720 --> 00:26:49,880
- I know we said that we were only going to do a couple each,

395
00:26:49,880 --> 00:26:54,760
but my last one for this week is nothing more than a comical package name, so I'm going to sneak it in.

396
00:26:54,760 --> 00:26:59,240
My last package for this week is a package called Mork & Middy,

397
00:26:59,240 --> 00:27:06,920
which, if you have any recollection of the 70s TV show Mork & Mindy, Brad Howes, who is the author

398
00:27:06,920 --> 00:27:12,680
of this package, has obviously got a fondness for that TV show and called his Middy library

399
00:27:12,680 --> 00:27:16,040
Mork & Middy. And I'm not even going to tell you what it does. If you're interested in Middy,

400
00:27:16,040 --> 00:27:20,520
Go and have a look at it, but we'll leave it there because we are trying to keep today's episode

401
00:27:20,520 --> 00:27:27,160
under an hour. So with that, I think we should wrap it up. Thanks so much to everyone who submitted

402
00:27:27,160 --> 00:27:33,000
questions for the opening section of today's episode. And thank you so much for all of our

403
00:27:33,000 --> 00:27:40,280
supporters, including Apple, for making what we do here possible. Yeah, absolutely. Thanks everyone,

404
00:27:40,280 --> 00:27:44,840
and see you next time. Bye bye. See you next time. All right, bye bye.