1
00:00:00,001 --> 00:00:05,840
I think the biggest news in the last three weeks of Swift news is that the Swift Package Indexing

2
00:00:05,840 --> 00:00:12,880
podcast last week or last episode had chapters. Did you see them? I did see the chapters. I love

3
00:00:12,880 --> 00:00:21,520
them. It's great. We're getting there. We're like a nearing our anniversary of 50 episodes. We've

4
00:00:21,520 --> 00:00:26,720
got transcriptions. Well, we've had those for a while. Now we got chapters. It's got everything,

5
00:00:26,720 --> 00:00:33,280
all the bells and whistles. It's got almost everything. Yeah. All it needs is better content.

6
00:00:33,280 --> 00:00:36,000
Well, there's nothing we can do about that, can we?

7
00:00:36,000 --> 00:00:45,840
Yeah, it was not a big hassle at all to get the chapters in. I won't go into a huge amount of

8
00:00:45,840 --> 00:00:56,480
detail, but after editing of the podcast, I placed some markers in Audition and then

9
00:00:56,480 --> 00:01:05,120
exported it actually as a WAV file and used a free utility written by Marco Arment called Forecast,

10
00:01:05,120 --> 00:01:13,760
which is actually... So I tried this tool first of all with just the MP3 file, the plain vanilla

11
00:01:13,760 --> 00:01:20,320
MP3 file that hadn't got the markers in it and tried to add the markers in Forecast, but I don't

12
00:01:20,320 --> 00:01:25,440
think it's designed to work that way. I think it's designed to work that you put your markers in your

13
00:01:25,440 --> 00:01:29,120
source file, which is great because then if we ever need to re-export it, those markers are all

14
00:01:29,120 --> 00:01:35,120
in the right place. And then it takes them and just kind of compresses the MP3 and inserts the

15
00:01:35,120 --> 00:01:40,560
chapter markers at the right place. So it was a very smooth process. And I can say that we will

16
00:01:40,560 --> 00:01:46,880
be continuing to do that in the podcast. Great. Now Forecast is not a Swift package, is it? That

17
00:01:46,880 --> 00:01:52,080
wasn't your first recommendation? It's not. That's not a recommendation. No, it is a recommendation

18
00:01:52,080 --> 00:02:00,880
of a tool, but not a Swift package or not as far as I'm aware. Nice. Yeah, I heard about that one.

19
00:02:00,880 --> 00:02:05,680
Oh, speaking of podcasts and players, there's something interesting I discovered just today.

20
00:02:05,680 --> 00:02:11,680
It's sort of only tangentially related to what we're doing, but because I mentioned transcripts

21
00:02:11,680 --> 00:02:17,520
just a moment ago, did you realize that in the Apple's podcast player, if you listen to a podcast

22
00:02:17,520 --> 00:02:25,840
and you switch to the transcript page, it's pretty much exactly like the lyrics in the music app.

23
00:02:25,840 --> 00:02:32,640
It plays along like the text, it highlights the current position where you're at. I thought that

24
00:02:32,640 --> 00:02:38,960
was really great. Yes, I think that's a fairly recent addition to the podcast app, like in the

25
00:02:38,960 --> 00:02:44,640
last couple of months, maybe. But I was aware of it. Yes. That's really great. Out of interest,

26
00:02:44,640 --> 00:02:51,680
what podcast app do you use? That's in... normally I use both Apple podcasts and

27
00:02:51,680 --> 00:02:57,360
Marco Armand's Overcast. Those are my... Oh, interesting. Okay. Yeah, those are the two.

28
00:02:57,360 --> 00:03:04,480
I use Castro, which I've used for many, many years now. And every time... it went through a bit of a

29
00:03:04,480 --> 00:03:10,720
rough patch recently with a change of ownership. And before the change of ownership, it had some

30
00:03:10,720 --> 00:03:19,120
problems. But the problem is I'm so spoiled by the workflow of Castro that I really struggled.

31
00:03:19,120 --> 00:03:23,920
When it was having those problems, I tried a couple of alternatives and I just couldn't

32
00:03:23,920 --> 00:03:31,440
get it to work as Castro works. And it really has ruined me. I'm completely stuck on Castro

33
00:03:31,440 --> 00:03:35,920
forever. But luckily, I think the new owner seems to be doing a great job with it so far. So

34
00:03:35,920 --> 00:03:42,720
I'm happily sticking with it. Yeah. Podcast players are really sticky, I find. Actually,

35
00:03:42,720 --> 00:03:49,760
the reason I use two is that I've started listening to some stuff on each and I have a

36
00:03:49,760 --> 00:03:56,560
hard time switching like podcasts over because I sort of know where they are and how the next episode

37
00:03:56,560 --> 00:04:03,680
is going to be coming in. And it's just, you know, for this podcast, I go to this player and for the

38
00:04:03,680 --> 00:04:09,360
others, I go to that player. It's really bizarre how that is segmented in my listening habits.

39
00:04:09,360 --> 00:04:17,040
Yeah, it's a tough business. But I think once you get a customer, it is hard for them to switch

40
00:04:17,040 --> 00:04:27,360
away. So in terms of news this week, I thought there was a post that was worth us discussing.

41
00:04:27,360 --> 00:04:36,160
And the post was on the CocoaPods blog. And it's by Orta Therox. And it's,

42
00:04:36,160 --> 00:04:44,080
I think it's a really great post for them to make, because we'll talk about the content of it in a

43
00:04:44,080 --> 00:04:50,640
minute. But actually, the summary of the post is that nothing is changing. But they just want to

44
00:04:50,640 --> 00:04:58,560
be a little bit more open about the state of CocoaPods these days and how it's getting maintained

45
00:04:58,560 --> 00:05:03,760
and who's maintaining it and how long will it be maintained for and that kind of thing. Because

46
00:05:03,760 --> 00:05:11,520
obviously, since Swift Package Manager got support for iOS and MacOS and other Apple platform

47
00:05:11,520 --> 00:05:21,440
projects in 2019, the writing has kind of been on the wall for CocoaPods that that would become the

48
00:05:21,440 --> 00:05:29,760
de facto standard at some point. But also, there are so many projects around that have CocoaPods

49
00:05:29,760 --> 00:05:37,520
in them or had CocoaPods in them, that even if the writing is on the wall, that tool is going

50
00:05:37,520 --> 00:05:43,840
to be needed in many environments for many, many years. And it left them in, I think, quite a

51
00:05:43,840 --> 00:05:50,240
difficult situation because, as he says in the post, several of the people who are the core

52
00:05:50,240 --> 00:05:55,520
maintainers don't use the project anymore. And this often happens with open source that's been

53
00:05:55,520 --> 00:06:03,120
around a long time. And you end up in this situation where the people ultimately responsible

54
00:06:03,120 --> 00:06:13,280
for maintaining it and supporting usage of this tool in enormous companies have mentally kind of

55
00:06:13,280 --> 00:06:23,040
moved on in some ways. And Orta does an amazing job with lots of open source. And he is absolutely

56
00:06:23,040 --> 00:06:29,920
not guilty of moving on because he sticks with these projects until... Well, he just sticks with

57
00:06:29,920 --> 00:06:34,880
these projects. I've never seen anyone like him. And I'm sure there are lots of people on the team

58
00:06:34,880 --> 00:06:40,720
who also feel the same way as him, that it's so important that they need to maintain it.

59
00:06:40,720 --> 00:06:47,120
But what's difficult to do is communicate that because if you make a big post and say,

60
00:06:47,120 --> 00:06:52,640
"CocoaPods is shutting down," or "What does that even mean with an open source project?"

61
00:06:52,640 --> 00:06:58,080
Or if you make a post like he made, a lot of people will take that to be, "Well, this is

62
00:06:58,080 --> 00:07:01,840
absolutely the end." And that's not what they're saying in this post. But I thought it was worth

63
00:07:01,840 --> 00:07:06,720
discussing. Yeah, definitely. I mean, I've said in the past that I'm not a heavy

64
00:07:06,720 --> 00:07:13,360
CocoaPods user. Certainly not now, but even in the past, I haven't been. I've sort of seen it

65
00:07:13,360 --> 00:07:18,960
in a couple of projects that I was working on. But it's very clearly been a really instrumental

66
00:07:18,960 --> 00:07:25,440
part of iOS and macOS development, right? So in that sense, it's kind of amazing how

67
00:07:26,960 --> 00:07:30,800
many projects are leaning on this and how important it really is. And in that sense,

68
00:07:30,800 --> 00:07:38,400
it's a really considered approach, right? They're laying out a multi-year timeline before they're

69
00:07:38,400 --> 00:07:44,640
even considering to make stuff read-only and sort of very clear about how it's going to be

70
00:07:44,640 --> 00:07:50,880
in maintenance mode. And that meaning they're not adding features, but they're still addressing

71
00:07:50,880 --> 00:07:57,120
security issues and stuff like that. When I read this, I thought, "There are lots of paid

72
00:07:57,120 --> 00:08:02,880
services that could probably take a look at this and not shut down as hard as they often do, right?"

73
00:08:02,880 --> 00:08:08,720
They shut down with a couple of months notice. And it's remarkable. And that's the biggest point

74
00:08:08,720 --> 00:08:14,720
that I want to make while we're talking about this, which is the commitment and the way that

75
00:08:14,720 --> 00:08:21,840
this team has behaved, not just with this, but with the entire history of CocoaPods is remarkable.

76
00:08:21,840 --> 00:08:27,760
And I cannot commend them enough for the way that they run and continue to run this project.

77
00:08:27,760 --> 00:08:35,360
I was a big CocoaPods user. It was the first thing I did with every iOS project that I started.

78
00:08:39,360 --> 00:08:45,360
And yeah, it was a fantastic tool that replaced kind of working with Git submodules, which I

79
00:08:45,360 --> 00:08:53,920
don't think any of us really want to do. So yes, it was a fantastic tool in its day. And while

80
00:08:53,920 --> 00:08:59,200
it's true that I wouldn't consider using it these days, that doesn't mean that there aren't a lot

81
00:08:59,200 --> 00:09:05,200
of projects who still are using it. What's interesting is in the post, if you read through

82
00:09:05,200 --> 00:09:13,120
it, one of the things that I was kind of surprised about is that I thought that if they did give any

83
00:09:13,120 --> 00:09:20,800
details on traffic or usage, that it would show a peak and then a decline. But actually, that's not

84
00:09:20,800 --> 00:09:29,120
the case. And in fact, most metrics of usage and traffic are still rising because it's found a home

85
00:09:29,120 --> 00:09:35,680
in a couple of different technologies, React, Native, and Flutter, both I would imagine have a

86
00:09:35,680 --> 00:09:44,800
happier path with CocoaPods than they do with Package Manager currently. And I'm not sure of

87
00:09:44,800 --> 00:09:48,960
the details of that because I don't use either of those two technologies. But it's interesting

88
00:09:48,960 --> 00:09:55,360
how these projects sometimes find a new home where they can continue to thrive, not maybe on the

89
00:09:55,360 --> 00:10:03,440
scale that they were originally, but certainly within those two domains, it seems like it may

90
00:10:03,440 --> 00:10:09,920
have an even longer life. Yeah. You said something earlier that made me pause and I'm not up to date

91
00:10:09,920 --> 00:10:18,160
that it's replaced, Swift Package Manager has replaced CocoaPods on Mac and iOS. I was wondering,

92
00:10:18,160 --> 00:10:27,200
has it actually fully replaced it? Because I recall there is no way in Swift Package Manager to

93
00:10:27,200 --> 00:10:36,960
specify an app target, right? Like you normally do. Does that not impact its use in iOS apps?

94
00:10:36,960 --> 00:10:40,880
In terms of only including some dependencies on some targets?

95
00:10:41,840 --> 00:10:52,560
No. I mean, like as I recall, the Playgrounds app on the iPad introduced this new target,

96
00:10:52,560 --> 00:10:59,040
I think it's called iOS application that allows you to deploy directly from the iPad. And I always

97
00:10:59,040 --> 00:11:04,000
thought, well, that's the sort of thing that is still needed to make, to fully transition over to

98
00:11:04,000 --> 00:11:10,080
Swift Package Manager. I always thought there was something left for CocoaPods to do in that realm

99
00:11:10,080 --> 00:11:16,080
or any sort of Package Manager kind of thing, because Swift Package Manager can't do the whole

100
00:11:16,080 --> 00:11:22,400
thing yet outside of that Playgrounds app. Right. I'm actually, I'm not sure on that

101
00:11:22,400 --> 00:11:31,440
specific example, but I'm sure there are edge cases where people would at least need to make

102
00:11:31,440 --> 00:11:37,120
significant changes to their build infrastructure to move away from CocoaPods. And that's why

103
00:11:37,120 --> 00:11:41,600
it's going to live for a very, very long time. Yeah. I mean, I can see that. I mean,

104
00:11:41,600 --> 00:11:46,880
even if everything is there in Swift Package Manager for a big project, a big company to move,

105
00:11:46,880 --> 00:11:52,800
yeah, it's just not going to be feasible, you know, or something that's going to be tackled

106
00:11:52,800 --> 00:11:58,160
unless there's huge outside pressure to actually invest that time to transition over.

107
00:11:58,160 --> 00:12:04,480
Exactly. Yeah. So we should probably get to the meat of what was said, which is

108
00:12:05,920 --> 00:12:12,160
in the post, Autu says that basically, in fact, I'll quote from it. It says, "Strictly speaking,

109
00:12:12,160 --> 00:12:18,000
we don't plan on changing how we're maintaining CocoaPods. We're just going to start to be clear

110
00:12:18,000 --> 00:12:23,280
about how CocoaPods has been maintained." So I think that's great because there's actually

111
00:12:23,280 --> 00:12:29,280
nothing new here. This is already the state that CocoaPods is in. And the crux of it is

112
00:12:29,920 --> 00:12:37,280
that they will make sure that they handle systemic security issues to Trunk. They'll aim to make at

113
00:12:37,280 --> 00:12:42,000
least two releases a year to keep up to date with Xcode updates. They'll aim to look at support

114
00:12:42,000 --> 00:12:47,600
requests for Trunk every six months. They'll keep the website infrastructure from not falling over.

115
00:12:47,600 --> 00:12:54,160
And they're open to pull requests that make CocoaPods more future-friendly. But they have

116
00:12:54,160 --> 00:13:01,520
said they will not be following GitHub issues actively. They're not planning on doing any

117
00:13:01,520 --> 00:13:07,680
active feature development on the project. And they're not going to guarantee to handle pull

118
00:13:07,680 --> 00:13:14,560
requests from adding new features or application or fixing application-level bugs. So I think that's

119
00:13:14,560 --> 00:13:23,840
a really sensible way to do it. It means that if you have a project that does rely on this,

120
00:13:23,840 --> 00:13:29,920
you know that it's going to at least continue to support the latest version of Xcode, which is

121
00:13:29,920 --> 00:13:35,200
going to be the main thing. And of course, any security issues. There was recently a security

122
00:13:35,200 --> 00:13:42,800
issue with CocoaPods with their login system. And that was fixed in an extremely timely fashion,

123
00:13:42,800 --> 00:13:49,280
really quick response. And it does get the attention when it absolutely needs it. It just

124
00:13:49,280 --> 00:13:55,840
doesn't get a lot of attention outside of those required tasks.

125
00:13:55,840 --> 00:14:01,760
Yeah, absolutely. That makes perfect sense. I really like what they lay out there. I mean,

126
00:14:01,760 --> 00:14:03,840
it's what you need, right?

127
00:14:03,840 --> 00:14:04,720
Yeah, absolutely.

128
00:14:04,720 --> 00:14:11,600
So the other bit of news we could briefly talk about is a post that I've seen on the Swift

129
00:14:11,600 --> 00:14:20,160
forums. And that is a summary of a Google Summer of Codes project by Lokesh TR that adds macro

130
00:14:20,160 --> 00:14:22,880
expansions to VS Code. Did you see that?

131
00:14:22,880 --> 00:14:25,520
I did, but only after you sent it to me.

132
00:14:25,520 --> 00:14:34,000
Well, that still counts. So just to explain what that does, unless it's obvious,

133
00:14:34,000 --> 00:14:38,800
it adds macro expansions to VS Code. So macro expansion is the thing,

134
00:14:40,000 --> 00:14:45,440
you know, in Xcode when you can, I think, right click is the command. Obviously, there's surely

135
00:14:45,440 --> 00:14:51,120
there's a menu command as well that you can right click on a macro and then expand the source code.

136
00:14:51,120 --> 00:14:56,880
Because macros, all they do, like in quotes, all they do is sort of type out lots of stuff,

137
00:14:56,880 --> 00:15:01,840
you know, like have you not type out stuff and you put in a shortcut. That sort of does the

138
00:15:01,840 --> 00:15:08,560
typing behind the scenes. But it's all source code that's generated and you can expand it so you can

139
00:15:08,560 --> 00:15:14,400
see what it's actually doing. And this brings that feature to VS Code. And that's just great.

140
00:15:14,400 --> 00:15:22,480
I just love that these things are appearing in other editors and VS Code is leading the front

141
00:15:22,480 --> 00:15:30,080
of the pack here. And it should be mentioned that a lot of these changes are coming into the

142
00:15:30,080 --> 00:15:37,920
source kit LSP. LSP is a language service protocol, I believe, or language server protocol.

143
00:15:37,920 --> 00:15:47,200
It's a general protocol for IDEs, like where you, where a language backend sends information about

144
00:15:47,200 --> 00:15:53,040
the source code that it knows about and editors can then hook into that and use it to drive

145
00:15:53,040 --> 00:16:00,880
auto completion and features like this. And Lokesh has extended this and made this possible.

146
00:16:00,880 --> 00:16:07,840
And I think he's even demonstrated this working in Vim. So it's currently like fully implemented

147
00:16:07,840 --> 00:16:15,600
in VS Code. But there's nothing stopping other editors that support LSP to adopt this as well.

148
00:16:15,600 --> 00:16:21,760
I guess that the part that needs work in the editor end is, you know, the UI bit, right?

149
00:16:21,760 --> 00:16:27,120
Because you're bringing in and showing extra code and that needs to be presented somehow.

150
00:16:27,120 --> 00:16:33,760
But all the plumbing is there to be able to do that. And yeah, there's this forum post that

151
00:16:33,760 --> 00:16:40,080
explains it. And there's a second one that goes into a lot more detail in how it's done and what

152
00:16:40,080 --> 00:16:47,840
the parts are. And I think also a bit like future plans and stuff. In case you want to try it right

153
00:16:47,840 --> 00:16:54,960
now, that means you would have to use main branches of the Swift compiler and of source kit LSP and

154
00:16:54,960 --> 00:17:05,280
of the VS Code extension. But the Swift version where that's targeted to be released in is 6.1,

155
00:17:05,280 --> 00:17:10,800
which I guess isn't that far off. I mean, 6.0 is probably what we'll see

156
00:17:12,400 --> 00:17:18,720
next month, I believe. But I don't think Swift 6.1 is that far behind.

157
00:17:18,720 --> 00:17:26,400
And then VS Code, the next extension will have that, which certainly won't be later than the

158
00:17:26,400 --> 00:17:33,360
compiler. So we should be seeing this in production soon. So you don't have to fiddle around with,

159
00:17:33,360 --> 00:17:38,080
you know, main branch deployments and that sort of thing.

160
00:17:39,040 --> 00:17:44,320
Yeah, the language server has been a huge step forward for not only Swift, it supports a lot

161
00:17:44,320 --> 00:17:51,200
of languages. And you may not know this, but there is already documentation on swift.org

162
00:17:51,200 --> 00:17:58,800
for how to use both Vim and Emacs with Swift, both taking advantage of language server support.

163
00:17:58,800 --> 00:18:07,200
Yeah, I'm using Nova a lot. And that is also using LSP. And you get it's like it has, you know,

164
00:18:07,200 --> 00:18:13,600
the completions, which is the thing I really need the most is language is the auto complete.

165
00:18:13,600 --> 00:18:19,280
And that works great. And I love that that's available and is also automatically getting,

166
00:18:19,280 --> 00:18:25,040
you know, any improvements in the LSP side sort of automatically benefits all these editors.

167
00:18:25,040 --> 00:18:26,720
It's just great.

168
00:18:26,720 --> 00:18:32,320
The other big feature that this makes possible is jump to definition, right?

169
00:18:32,320 --> 00:18:35,200
Yeah, exactly. Yeah. I think that also works.

170
00:18:35,200 --> 00:18:42,160
Which is another huge, huge benefit for navigation. So yes, I shall include links in the show notes to

171
00:18:42,160 --> 00:18:50,480
the Emacs and Vim documents on the Swift website as well. But if you're just browsing it off the

172
00:18:50,480 --> 00:18:55,120
menu, if you just go to the tools page, it's almost the first thing on the tool page. It's

173
00:18:55,120 --> 00:18:58,080
Xcode, Visual Studio Code, and then Emacs and Vim.

174
00:18:58,080 --> 00:19:04,960
Yeah. Great. I think that brings us to the packages, doesn't it?

175
00:19:04,960 --> 00:19:14,800
Okay. Yeah. Then I will kick us off this week with a package called SVGPath by Nick Lockwood.

176
00:19:14,800 --> 00:19:24,240
And this is, as you might imagine, a package that deals with SVGs and specifically the paths within

177
00:19:24,240 --> 00:19:31,680
SVGs. And there are lots of SVG packages that will pass an SVG file and render it or whatever.

178
00:19:32,640 --> 00:19:41,280
What I liked about this is it takes just one aspect of that problem and solves it for something

179
00:19:41,280 --> 00:19:46,960
that actually is going to be extremely useful if you're writing graphics code in an iOS or a MacOS

180
00:19:46,960 --> 00:19:56,880
app. And it takes a path inside an SVG and brings it in and gives you a CG path out of it. So it

181
00:19:56,880 --> 00:20:05,920
doesn't try and render the entire SVG file, but if you're looking to try and get a hold of a complex

182
00:20:05,920 --> 00:20:15,520
path inside your application, there's probably not an easier way to do it than to draw it in an

183
00:20:15,520 --> 00:20:20,960
application that can export SVGs and then bring that path in and just get it as a native CG path,

184
00:20:20,960 --> 00:20:25,040
which I think is great. Nice. So effectively, you're saying all

185
00:20:25,040 --> 00:20:30,880
these lovingly handcrafted SVG icons that we've got on the Swift Package Index site

186
00:20:30,880 --> 00:20:39,520
could be converted into code paths, which we could then use in the native app that we're

187
00:20:39,520 --> 00:20:42,240
writing at some point, right, for the Swift Package Index?

188
00:20:42,240 --> 00:20:50,560
Probably not all of them, because there's more in the icons that we have than just paths. Now,

189
00:20:50,560 --> 00:20:56,480
all of the icons on the package page, so all those kind of two-color icons that are just

190
00:20:56,480 --> 00:21:02,640
literally just paths, they could all be converted into paths. But the logo, I don't think could be,

191
00:21:02,640 --> 00:21:06,720
because we have fills and things like that in there.

192
00:21:06,720 --> 00:21:09,040
It's not just all paths all the way down.

193
00:21:09,040 --> 00:21:18,160
No, it's not. I think anything with a fill would... The fill, probably, I don't know whether

194
00:21:18,160 --> 00:21:22,240
it would make this fall over, but it certainly... This is not what that's intended to do. It's

195
00:21:22,240 --> 00:21:29,120
intended to grab a path. So it's basically, it lets you use SVG as a data file to store paths

196
00:21:29,120 --> 00:21:33,840
with. And the nice thing about that data file is it's editable in graphics editors.

197
00:21:33,840 --> 00:21:39,280
Nice. Yeah, there are a number of these tools, right, that allow you to convert,

198
00:21:39,280 --> 00:21:46,640
like, draw vector graphics into code. And I really like that because it's just nicer.

199
00:21:46,640 --> 00:21:53,600
Some things are obviously really nice to work in graphical representation, but there's also

200
00:21:53,600 --> 00:22:00,080
often a huge benefit to have something in code, right, that you can manipulate in a different

201
00:22:00,080 --> 00:22:06,720
dimension, so to speak. Nice. I don't use it anymore, but there was a fantastic tool that

202
00:22:06,720 --> 00:22:16,000
I did use for several years. Well, it's still around. It's still current, called PaintCode.

203
00:22:16,960 --> 00:22:24,320
Which is a... It is a graphical editor. You can draw things in PaintCode. And as you draw them,

204
00:22:24,320 --> 00:22:33,600
you can see a swift representation using CG paths and CG, you know, all the core graphics code

205
00:22:33,600 --> 00:22:40,400
that actually gets dynamically created as you draw. Nice. You can have your code

206
00:22:40,400 --> 00:22:49,120
live, updated if you wanted to. And that was nice. I mean, partly, I'm not using it because I'm not

207
00:22:49,120 --> 00:22:55,840
writing my OS on my Mac apps anymore, because we're working on the server code. But what they

208
00:22:55,840 --> 00:23:03,760
also did was they created a build process that could output, I think it was a XC framework,

209
00:23:03,760 --> 00:23:08,240
or it was some kind of library, some kind of compatible library. So you could effectively

210
00:23:08,240 --> 00:23:13,920
save all your drawings as a single framework and then bring that into your application and use it

211
00:23:13,920 --> 00:23:19,440
from there. But that was an interesting way to go about things. I get the feeling that it's not a

212
00:23:19,440 --> 00:23:26,800
very popular way to do it. I think the primary way most people work is bringing in SVGs or sometimes

213
00:23:26,800 --> 00:23:32,640
bitmap files and using them in the application. I think it has, these days, I think it has

214
00:23:32,640 --> 00:23:39,040
transitioned much more to using SVGs rather than bitmaps. But I don't think a lot of people are

215
00:23:39,040 --> 00:23:47,040
turning those images into CG code. Yeah. Well, I guess the big advantage of the code

216
00:23:47,040 --> 00:23:53,120
thing was that it was, you know, the resolution was resolution independent,

217
00:23:53,120 --> 00:23:59,920
but SVGs solve that same thing, right? So you have less incentivized to convert that over.

218
00:24:00,480 --> 00:24:06,480
Exactly. Yeah. Yeah. There was a time when paint code was really popular. It was paint code or

219
00:24:06,480 --> 00:24:16,160
bitmap. I think you could import a PDF file in like icons in a PDF format, and that would work.

220
00:24:16,160 --> 00:24:20,480
But there was trouble. There was difficulties with that.

221
00:24:20,480 --> 00:24:22,320
There was trouble down that road.

222
00:24:22,320 --> 00:24:24,400
There was trouble down that road. Exactly. Yeah.

223
00:24:25,520 --> 00:24:35,200
All right. My first pick is called Swift Cloud by Andrew Barba. And I really like this one

224
00:24:35,200 --> 00:24:40,480
because it looks like a really simple way to get started with deployments on AWS or cloud

225
00:24:40,480 --> 00:24:45,680
providers in general. The first one and the only one supported right now is AWS, but I believe

226
00:24:45,680 --> 00:24:52,720
Andrew has plans to make this a bigger thing like supporting other providers.

227
00:24:53,760 --> 00:24:58,800
And the reason I like this is because AWS can be really daunting when you get started and you want

228
00:24:58,800 --> 00:25:05,680
to do maybe even just a simple thing like a simple Lambda function. It has quite the learning curve

229
00:25:05,680 --> 00:25:11,840
to get started. And the examples are laid out that really the thing you need is the account

230
00:25:11,840 --> 00:25:16,960
credentials. And then you can start writing a creating a little package and writing your

231
00:25:17,760 --> 00:25:23,600
service definition effectively in Swift and specifying it out. It's effectively like

232
00:25:23,600 --> 00:25:28,480
think of having your Swift package manifest that describes your package. You have equally

233
00:25:28,480 --> 00:25:35,040
like a code representation of your infrastructure that you want to deploy. And then you can run,

234
00:25:35,040 --> 00:25:41,680
it's like a plugin, then you can run these plugin commands to deploy even to like different

235
00:25:41,680 --> 00:25:47,040
environments, check your deployment, tear down the deployment and that sort of thing.

236
00:25:47,040 --> 00:25:53,440
So that's really nice. It's early days for the package, but it already covers a lot of cloud

237
00:25:53,440 --> 00:26:00,560
primitives like web server function, CDN bucket queue and more, all these things you might need.

238
00:26:00,560 --> 00:26:08,800
But because it's early days, you probably might want to test this a bit or use it for a project

239
00:26:08,800 --> 00:26:15,600
where you try something out. I'm not sure even if Andrew would recommend leaning on this too heavily

240
00:26:15,600 --> 00:26:22,400
this early on, but give this a go. If you don't know a lot about AWS and want to learn how this

241
00:26:22,400 --> 00:26:27,360
works, because I think another route might be to use this to deploy something and then check

242
00:26:27,360 --> 00:26:34,800
the AWS side of things, what is actually being created. Because I find that often a very useful

243
00:26:34,800 --> 00:26:42,560
way to learn what should this look like if I use the, if I then use other tools, what do I expect

244
00:26:42,560 --> 00:26:47,920
actually to happen on the AWS side? Because sometimes there's so many things you don't really

245
00:26:47,920 --> 00:26:54,000
know which ones are the ones you need. And if something is there that has this path plotted

246
00:26:54,000 --> 00:26:59,440
out for you as a template, then you can go back and sort of compare, right? I've set this up

247
00:26:59,440 --> 00:27:07,280
in the correct way, so to speak. Now, this is server-side Swift, and I realize it's very niche.

248
00:27:07,280 --> 00:27:12,960
We use it a lot. We've just said, right, all we do these days is working on server-side stuff.

249
00:27:12,960 --> 00:27:16,960
So this might not be interesting or probably isn't interesting for lots of people.

250
00:27:16,960 --> 00:27:22,400
But there's actually something in the readme that is interesting, even if you don't do

251
00:27:22,400 --> 00:27:25,680
server-side Swift, because you probably use Docker. - I'll be the judge of that.

252
00:27:25,680 --> 00:27:32,160
- All right. Well, you already have been, I believe, because the readme says if you're on a Mac,

253
00:27:32,800 --> 00:27:39,440
the easiest way to install Docker is Orbstack. And that's the thing I discovered.

254
00:27:39,440 --> 00:27:44,880
I was interested in the packet, but I thought I'd talk about it, because people might find

255
00:27:44,880 --> 00:27:50,000
this interesting, even if they don't care about server-side Swift, because even if you don't do

256
00:27:50,000 --> 00:27:56,160
server-side Swift, you probably are dealing with Docker one way or another. It's almost unavoidable

257
00:27:56,160 --> 00:28:01,280
that something in your dev tools, like spinning up a database or something, will probably involve

258
00:28:01,280 --> 00:28:05,840
Docker. And for the longest time I've been using, and you have been too, Dave, I know,

259
00:28:05,840 --> 00:28:14,800
Docker for Mac, like the Docker desktop application, which is an application, but it's not great.

260
00:28:14,800 --> 00:28:23,360
And Orbstack, I've been using this for two weeks now, and it's a drop-in replacement for this.

261
00:28:23,360 --> 00:28:29,520
And it's a really nice Mac app. I'm pretty sure it's SwiftUI. It looks like a proper Mac app.

262
00:28:29,520 --> 00:28:34,640
It's beautiful. It's really nice. It has all the things you would expect. And we use Docker a lot

263
00:28:34,640 --> 00:28:39,600
in our project. We build images, we push images, we run databases, we

264
00:28:39,600 --> 00:28:46,480
run build ARM containers, we run Intel containers on ARM Macs,

265
00:28:46,480 --> 00:28:54,400
all sorts of things. And everything works just fine. You wouldn't be able to tell whether you're

266
00:28:54,400 --> 00:29:03,600
using this or Docker. And key is that the Docker CLI is actually, I think, the same. This is a

267
00:29:03,600 --> 00:29:07,680
front end to see your containers. So if you don't know, Docker under the hood has an engine

268
00:29:07,680 --> 00:29:17,280
and has an HTTP API in front of that engine, and clients can talk to that API. And this app is a

269
00:29:17,280 --> 00:29:23,280
client that talks to that engine, just like the Docker for Mac application does. It's just a nicer

270
00:29:23,280 --> 00:29:30,080
version of that. But your Docker CLI is actually the same in both cases. So that's interesting to

271
00:29:30,080 --> 00:29:36,560
know. And that's why all these tools. So if you have any sort of scripts that rely on Docker

272
00:29:36,560 --> 00:29:41,360
commands, you can expect these to just keep on working because they're actually the same.

273
00:29:41,360 --> 00:29:48,640
So yeah, it's been a really great drop-in replacement for that. Looks great, works great.

274
00:29:49,440 --> 00:29:57,360
It's free for personal use, $8 per month commercially available license for that.

275
00:29:57,360 --> 00:30:04,720
And I believe nonprofits can ask for reduced or free licenses as well. So it really is great.

276
00:30:04,720 --> 00:30:06,960
I believe you've started using it as well, haven't you, Dave?

277
00:30:06,960 --> 00:30:15,120
I have, yeah. And I haven't really. So after you mentioned it, I installed it. And that's about

278
00:30:15,120 --> 00:30:19,520
everything that I've done with it. And I haven't noticed a single difference apart from the fact

279
00:30:19,520 --> 00:30:26,160
that I no longer have to use Docker Desktop, which is brilliant. I mean, it is absolutely the best

280
00:30:26,160 --> 00:30:32,560
endorsement of it that you don't have to worry about it. You don't have to care that it is even

281
00:30:32,560 --> 00:30:39,280
there. Although Docker Desktop did get much more, infinitely more usable when they finally

282
00:30:39,280 --> 00:30:45,840
implemented command W to close the window. So that was the huge step forward. And that

283
00:30:45,840 --> 00:30:49,760
happened about six months ago, I think. Well, there you go. So that's Swift Cloud

284
00:30:49,760 --> 00:30:53,600
by Andrew Barber. And if that doesn't interest you at all, there's Orb Stack.

285
00:30:53,600 --> 00:31:00,080
And actually on the Swift Cloud thing, I actually linked to that in iOS Dev Weekly,

286
00:31:00,080 --> 00:31:05,840
I think last week. And Andrew dropped me a Discord message. So because in the newsletter, I said

287
00:31:06,640 --> 00:31:12,960
that it only works with AWS Lambda initially, and he corrected me, and I think I updated the

288
00:31:12,960 --> 00:31:19,680
poster with the correction that actually works with Lambda and Fargate. Now, I haven't even heard

289
00:31:19,680 --> 00:31:25,200
of Fargate, but apparently it's a similar thing, but using EC2 resources. So there are already two

290
00:31:25,200 --> 00:31:32,240
backend implementations that it can run on. And I believe the plan is for more of those,

291
00:31:32,240 --> 00:31:39,440
maybe not AWS ones as well. So. Yeah, I believe so. My memory is that Fargate is a bit like a

292
00:31:39,440 --> 00:31:45,120
droplet at DigitalOcean, where you get a machine that you can deploy to,

293
00:31:45,120 --> 00:31:51,600
and it's a bit easier to set up and run than the EC2 instances directly. Yes, that's it. Yeah.

294
00:31:53,760 --> 00:32:02,160
Okay, my next package is called PhraseKit by Mark Battistella. And

295
00:32:02,160 --> 00:32:11,120
it's a package that generates random data, basically kind of human readable phrases using

296
00:32:11,120 --> 00:32:16,160
customizable word combinations, perfect for creating unique file names, username, session

297
00:32:16,160 --> 00:32:20,560
IDs, and more. And yes, I was reading most of that from the description of it.

298
00:32:23,120 --> 00:32:29,360
So yeah, this is not a super complex package, although I shouldn't say that because I have

299
00:32:29,360 --> 00:32:37,760
no idea what's going on internally. But like it says, it generates phrases or

300
00:32:37,760 --> 00:32:45,360
strings of characters based on rules that you give it. So you can, for example, say,

301
00:32:45,360 --> 00:32:51,760
just generate a two word phrase would be just generate phrase. If you wanted a three word

302
00:32:51,760 --> 00:32:56,560
phrase, you could say generate phrase with a word count of three, pass that as a parameter.

303
00:32:56,560 --> 00:33:08,880
And then you can say that every phrase must be unique. And you can give it inclusion and

304
00:33:08,880 --> 00:33:14,000
exclusion lists of words to use. So you can say, if you want a specific set of words,

305
00:33:14,000 --> 00:33:18,240
here are the sets, or please never use this if you're, for example,

306
00:33:20,800 --> 00:33:25,360
if you have some kind of reserved words or something like that, you can exclude them,

307
00:33:25,360 --> 00:33:32,080
but it does come with a word dictionary. So I can see this being useful for kind of test data

308
00:33:32,080 --> 00:33:38,000
or sample data even better. And it's not the kind of thing that you're going to use every day,

309
00:33:38,000 --> 00:33:42,720
but I thought it was interesting enough. Yeah, it's nice that sort of thing. We use

310
00:33:42,720 --> 00:33:49,120
something similar in the past to generate like unique identifiers that aren't just numbers

311
00:33:49,120 --> 00:33:54,160
for passing around. And I think that was also used in testing scenarios, but it was really nice to be

312
00:33:54,160 --> 00:34:00,240
able to refer to something a bit more readable than, you know, just numbers and still identifiable.

313
00:34:00,240 --> 00:34:09,840
And, you know, it's just a nicer thing to have. Yeah. I use the tool for many, many years in

314
00:34:09,840 --> 00:34:16,400
Ruby called Faker, which was a library to specifically for testing to generate fake,

315
00:34:16,400 --> 00:34:23,360
but real, but reasonable test data. Right. My second and sort of final pick,

316
00:34:23,360 --> 00:34:31,520
because you, you Sherlocked one of mine there and plus, plus this is a double pick. Actually,

317
00:34:31,520 --> 00:34:36,880
this is two packages. Was it the last one that I phrased kid? Yeah. Yeah. Phrase kid was on my

318
00:34:41,520 --> 00:34:53,920
So my pick is two packages. One is called EditValueView by p-x9 repeat package author.

319
00:34:53,920 --> 00:34:59,600
We've, we've had a package of theirs before. And the other is called UserDefaultsEditor. Okay.

320
00:34:59,600 --> 00:35:08,080
The other one is called UserDefaultsEditor by Ryu which uses edit value view under the hood.

321
00:35:10,000 --> 00:35:19,920
And what edit value view does is it gives you editable views that adapt to common types, like

322
00:35:19,920 --> 00:35:26,560
giving a few examples, like a string would have a text field and that's not just a plain text field.

323
00:35:26,560 --> 00:35:33,040
So you, you have a, obviously an attribute name and a type, and then it would give you a view

324
00:35:33,040 --> 00:35:40,320
with the label name and the type name and a text field as a representation. And the same for bool

325
00:35:40,320 --> 00:35:46,400
with a toggle enum with a picker as the element showing it. So it gives you standardized sort of

326
00:35:46,400 --> 00:35:52,240
configured views to, to allow you to, to view a data type and edit it. And obviously that's,

327
00:35:52,240 --> 00:35:58,480
that's sort of a techie sort of representation of it, but it allows you to very easily build UI

328
00:35:59,600 --> 00:36:03,920
for a type for instance, that, that is completely configurable while still being,

329
00:36:03,920 --> 00:36:10,000
being a proper UI, you know, like where you see all the data laid out and represented.

330
00:36:10,000 --> 00:36:14,320
And it has more complicated views than these simple ones, like date comes with a date picker,

331
00:36:14,320 --> 00:36:22,880
color with a color picker and array dict codable has entire editable JSON representations where

332
00:36:22,880 --> 00:36:28,640
you get a little text view where you can edit the representation and has all the,

333
00:36:28,640 --> 00:36:33,440
the other instrumentation. So as you can imagine, that's really nice for debug views,

334
00:36:33,440 --> 00:36:40,240
but I think you can also adapt this to if you have a sort of techie oriented, you know,

335
00:36:40,240 --> 00:36:46,400
developer tool where you have lots of data fields to, to present, but you don't want to make custom

336
00:36:46,400 --> 00:36:51,440
UI for them because there's lots of them. And they're often just, you know, strings and,

337
00:36:51,440 --> 00:36:59,920
and you know, like these core data types. And as you can imagine, one kind of area where that

338
00:36:59,920 --> 00:37:05,120
is useful is a user defaults editor. And that's exactly the second package. It wraps around

339
00:37:05,120 --> 00:37:12,160
edit value view and gives you like a very simple thing where you just say, well, I want a user

340
00:37:12,160 --> 00:37:19,200
defaults editor for the standard domain. And this is the, you know, this is the storage key for that,

341
00:37:19,200 --> 00:37:25,840
the data, and then you get a fully fleshed out view. Might not be perfect. Obviously,

342
00:37:25,840 --> 00:37:31,120
you know, it'll, it'll miss lots of things like additional explanation for fields, but it'll get

343
00:37:31,120 --> 00:37:39,600
you started if you have defaults views, defaults data that you want to represent and to be able to

344
00:37:39,600 --> 00:37:44,880
see what's actually saved. So might save you a lot of time to get started with a, with a thing,

345
00:37:45,440 --> 00:37:51,840
until you actually have a different UI, more custom UI. That's great. Yeah, there you go.

346
00:37:51,840 --> 00:38:02,480
That's edit value view by PX9 and user defaults editor by Ryu. I, I will do my last pick because

347
00:38:02,480 --> 00:38:08,000
it's only a short one. It's a, it's another, another little lighthearted one, which is

348
00:38:08,000 --> 00:38:14,640
confetti kits by Simon Støvring, which actually there's, there should be a double credit on this

349
00:38:14,640 --> 00:38:20,880
because it's, it's based from the readme file. It says it's based very heavily on the implementation

350
00:38:20,880 --> 00:38:29,040
from the blog post, recreating iMessage confetti by Bryce Bostwick. And confetti kit is,

351
00:38:29,040 --> 00:38:34,160
I would go as far as to say an essential package for any iOS or Mac application.

352
00:38:36,320 --> 00:38:44,960
And as you can imagine, it is a confetti implementation of, of randomly colored

353
00:38:44,960 --> 00:38:50,960
pieces of virtual paper that shower down from the top of the screen. And I would recommend reading

354
00:38:50,960 --> 00:38:59,680
both the blog post by Bryce and also the readme file by Simon before you, before you pop this in,

355
00:38:59,680 --> 00:39:05,520
because especially the blog post goes through step by step, the different stages to make

356
00:39:06,240 --> 00:39:12,480
random squares of color look actually like confetti before animating them down on the

357
00:39:12,480 --> 00:39:17,920
screen. And there's more to it than you might think. There is a practical, even though you

358
00:39:17,920 --> 00:39:21,440
might be thinking, well, there's no, there's no practical use for this, but there's actually a

359
00:39:21,440 --> 00:39:25,520
practical use for this, which is quite common in iOS and Mac applications. And I think it's a,

360
00:39:25,520 --> 00:39:30,880
it's an appropriate use, which is if you have an in-app purchase screen or some kind of payment

361
00:39:30,880 --> 00:39:36,800
gateway in your app, then at the point that a purchase has been successful, it's quite common

362
00:39:36,800 --> 00:39:44,320
to show some kind of celebration or confetti at that point, which, which this will save you the

363
00:39:44,320 --> 00:39:50,160
trouble of, of, of writing that code. And it's a very effective animation. Looks great.

364
00:39:50,160 --> 00:39:54,400
Nice. Yes. Required. Confetti is required for purchase confirmation.

365
00:39:54,400 --> 00:39:57,680
Exactly. Yeah, exactly.

366
00:39:57,680 --> 00:39:58,180
Nice.

367
00:39:59,120 --> 00:40:05,040
So, so yes, I would, I would say that even though it is, it's, it's fairly niche in what it does,

368
00:40:05,040 --> 00:40:07,520
I think there's a place in most applications for it.

369
00:40:07,520 --> 00:40:11,680
Great. Well, I'm done. I think that wraps it up. Isn't it? Doesn't it?

370
00:40:11,680 --> 00:40:18,240
Yeah. I think with that, we'll, we'll call it an episode and, and we'll be back in three weeks time

371
00:40:18,240 --> 00:40:19,440
with another one.

372
00:40:19,440 --> 00:40:24,720
Yep. See you in three weeks. And if any of this episode doesn't make any sense at all,

373
00:40:25,360 --> 00:40:30,640
like in terms of cutting, that's entirely down to my internet going down in the middle of it

374
00:40:30,640 --> 00:40:37,360
having to retrace our steps. So if this, if this comes out, well, it's all thanks to Dave's

375
00:40:37,360 --> 00:40:38,400
editing prowess.

376
00:40:38,400 --> 00:40:44,080
Yes. You've given me, you've given me a fun job tomorrow. There we go.

377
00:40:44,080 --> 00:40:46,800
See you in two weeks.

378
00:40:46,800 --> 00:40:49,840
All right. I will speak to you in a few weeks. Bye-bye.