1 00:00:00,001 --> 00:00:02,000 It's also the 50th episode. 2 00:00:02,000 --> 00:00:07,400 It is, it is actually. Yeah, I've seen this coming out and completely forgot about it again. 3 00:00:07,400 --> 00:00:10,400 It is. Happy, happy anniversary. 4 00:00:10,400 --> 00:00:12,000 The podcast will... 5 00:00:12,000 --> 00:00:13,400 Happy 50th anniversary, yeah. 6 00:00:13,400 --> 00:00:15,400 I think I made this joke before, right? 7 00:00:15,400 --> 00:00:20,400 This podcast will soon eclipse our age in terms of episodes. 8 00:00:20,400 --> 00:00:23,800 Well, I am actually 50 right now. 9 00:00:23,800 --> 00:00:24,600 Yeah, exactly. 10 00:00:24,600 --> 00:00:28,800 So it is... as of next month, it will be older than me. 11 00:00:29,000 --> 00:00:31,000 [laughs] 12 00:00:31,000 --> 00:00:36,000 But no, it's been a bit of a journey. 13 00:00:36,000 --> 00:00:38,400 I don't know whether we actually set out to... 14 00:00:38,400 --> 00:00:41,000 In fact, I know we didn't set out to make a podcast. 15 00:00:41,000 --> 00:00:45,000 It just kind of morphed into one over time. 16 00:00:45,000 --> 00:00:49,400 It started as a little kind of chat about what we were doing. 17 00:00:49,400 --> 00:00:54,000 We even had guests on the first few, which I do miss having guests, actually. 18 00:00:54,000 --> 00:00:58,200 I think we should consider bringing people on occasionally 19 00:00:58,200 --> 00:01:03,000 because I think it's good to get other people involved. 20 00:01:03,000 --> 00:01:09,400 But yeah, it's changed a lot since the very first days back on Twitter Spaces, 21 00:01:09,400 --> 00:01:11,000 which is where we started it. 22 00:01:11,000 --> 00:01:16,400 And then, of course, we kind of transitioned into being... 23 00:01:16,400 --> 00:01:20,000 I hesitate to say a proper podcast because I'm not sure I'd give it that, 24 00:01:20,000 --> 00:01:23,200 but certainly I'll take it a little bit more seriously. 25 00:01:23,200 --> 00:01:27,400 Well, it is listed on Apple Podcasts, right? 26 00:01:27,400 --> 00:01:30,200 So that absolutely makes it a proper podcast. 27 00:01:30,200 --> 00:01:31,000 Yeah. 28 00:01:31,000 --> 00:01:37,000 The requirements for being listed as a podcast there, though, are very, very minimal. 29 00:01:37,000 --> 00:01:41,200 Yeah, you're saying that the validation isn't as tight as it is 30 00:01:41,200 --> 00:01:43,600 to get a package on this with Package Index. 31 00:01:43,600 --> 00:01:47,600 Tim Kirk doesn't go and listen to your podcast if you want to be on that list. 32 00:01:47,600 --> 00:01:49,600 [laughs] 33 00:01:49,600 --> 00:01:54,600 He'd have a lot on his hands to listen to all of them. 34 00:01:56,000 --> 00:01:57,200 [laughs] 35 00:01:57,200 --> 00:01:58,000 I remember. 36 00:01:58,000 --> 00:02:02,200 In fact, it was at the last Swift Server Conference, 37 00:02:02,200 --> 00:02:06,600 which I think was actually 2022, the last one I was at. 38 00:02:06,600 --> 00:02:11,600 We'd just switched across to using... 39 00:02:11,600 --> 00:02:17,200 doing the podcast as a kind of actual podcast rather than Twitter Space, 40 00:02:17,200 --> 00:02:23,400 but we were still recording on the microphones we were just using for those early ones. 41 00:02:23,400 --> 00:02:27,000 And somebody came up to me at the Swift Server Conference and they said, 42 00:02:27,000 --> 00:02:31,200 "I really like the podcast, but please fix your audio." 43 00:02:31,200 --> 00:02:33,200 [laughs] 44 00:02:33,200 --> 00:02:35,200 Ooh, harsh. 45 00:02:35,200 --> 00:02:37,200 [laughs] 46 00:02:37,200 --> 00:02:39,600 I like "but" never ends well, does it? 47 00:02:39,600 --> 00:02:41,000 [laughs] 48 00:02:41,000 --> 00:02:42,600 I was well aware of the... 49 00:02:42,600 --> 00:02:43,600 And I'm not sure who it was. 50 00:02:43,600 --> 00:02:45,200 I didn't get their name. 51 00:02:45,200 --> 00:02:46,600 It was a very brief interaction. 52 00:02:46,600 --> 00:02:51,600 So if that was you and you're still listening, I did try and fix their audio. 53 00:02:51,600 --> 00:02:56,000 In fact, I've put many, many, many hours into fixing our audio. 54 00:02:56,000 --> 00:02:57,200 [laughs] 55 00:02:57,200 --> 00:03:01,800 If that was you, I'd love to see if you think it's fixed. 56 00:03:01,800 --> 00:03:03,000 So please get in touch. 57 00:03:03,000 --> 00:03:04,000 [laughs] 58 00:03:04,000 --> 00:03:05,000 Nice. 59 00:03:05,000 --> 00:03:07,200 So yeah, 50 episodes. 60 00:03:07,200 --> 00:03:09,400 It's a milestone of sorts. 61 00:03:09,400 --> 00:03:12,000 Well, speaking of the Server Side Swift Conference, 62 00:03:12,000 --> 00:03:13,200 actually, there was... 63 00:03:13,200 --> 00:03:17,800 Just after we recorded the last one, 64 00:03:17,800 --> 00:03:22,400 I went to the last episode of our podcast. 65 00:03:22,400 --> 00:03:26,600 I went to the Server Side Swift Conference in London. 66 00:03:26,600 --> 00:03:29,400 It was great. 67 00:03:29,400 --> 00:03:30,600 It was great to see folks. 68 00:03:30,600 --> 00:03:32,400 Great talks. 69 00:03:32,400 --> 00:03:34,400 It was a two-day conference this time. 70 00:03:34,400 --> 00:03:37,600 I think it was one day only in '22, 71 00:03:37,600 --> 00:03:38,600 which was the previous one. 72 00:03:38,600 --> 00:03:40,600 There wasn't one in '23. 73 00:03:40,600 --> 00:03:46,800 Yeah, great lineup, great news. 74 00:03:46,800 --> 00:03:50,000 So we actually got an Apple announcement of sorts again. 75 00:03:50,000 --> 00:03:54,000 There was a talk by Tony Parker and Ben Cohen. 76 00:03:54,000 --> 00:03:59,000 It was called "Swift and Interoperability". 77 00:03:59,000 --> 00:04:01,000 "Interoperability". 78 00:04:01,000 --> 00:04:02,000 God. 79 00:04:02,000 --> 00:04:03,400 See, that's easier for you to say. 80 00:04:03,400 --> 00:04:05,400 [laughs] 81 00:04:05,400 --> 00:04:08,400 And they announced Swift Java integration, 82 00:04:08,400 --> 00:04:11,200 which I found fascinating and great to see. 83 00:04:13,000 --> 00:04:17,800 So what this is about is about calling into Java from Swift 84 00:04:17,800 --> 00:04:20,600 and vice versa, calling into Swift from Java. 85 00:04:20,600 --> 00:04:22,600 And this is early days for the project. 86 00:04:22,600 --> 00:04:25,600 We'll drop a link in the show notes. 87 00:04:25,600 --> 00:04:26,800 Also open source again, 88 00:04:26,800 --> 00:04:29,400 so you can follow along as stuff is being developed. 89 00:04:29,400 --> 00:04:34,800 And it feels like Swift is really gaining 90 00:04:34,800 --> 00:04:37,000 more and more superpowers when it comes to 91 00:04:37,000 --> 00:04:39,800 interoperating with other languages. 92 00:04:39,800 --> 00:04:41,200 And there was quite a bit of excitement 93 00:04:41,200 --> 00:04:42,400 around the conference as well, 94 00:04:42,400 --> 00:04:44,800 when people were talking about it afterwards, 95 00:04:44,800 --> 00:04:47,800 because I can imagine there must be lots of 96 00:04:47,800 --> 00:04:54,200 big Java deployments that are perhaps sort of eyeing, 97 00:04:54,200 --> 00:04:57,000 you know, a future replacement. 98 00:04:57,000 --> 00:04:59,800 Like Swift is supposed to be one of the successor languages 99 00:04:59,800 --> 00:05:00,600 for C++. 100 00:05:00,600 --> 00:05:03,200 I wonder if there's the same sentiment for Java, 101 00:05:03,200 --> 00:05:07,400 because there are lots of nice things about Swift 102 00:05:07,400 --> 00:05:08,800 compared to Java. 103 00:05:08,800 --> 00:05:11,000 And I've just thinking in terms of memory, 104 00:05:11,000 --> 00:05:15,800 just today I looked at the memory consumption 105 00:05:15,800 --> 00:05:18,200 of our web application, 106 00:05:18,200 --> 00:05:21,800 which is a Swift on server project with 270 megabytes. 107 00:05:21,800 --> 00:05:26,000 And I don't think even that's particularly small. 108 00:05:26,000 --> 00:05:28,600 I think we have a couple of caching things happening 109 00:05:28,600 --> 00:05:32,600 that makes this a bit bigger than it would necessarily need to be. 110 00:05:32,600 --> 00:05:34,000 But I think in the Java world, 111 00:05:34,000 --> 00:05:39,400 that's a dream, you know, to have that as your memory size. 112 00:05:39,400 --> 00:05:41,800 And I think that might be really interesting 113 00:05:41,800 --> 00:05:44,800 for lots of projects as a way to transition. 114 00:05:44,800 --> 00:05:49,000 And in particular, because it really allows you to go bit by bit. 115 00:05:49,000 --> 00:05:50,800 So we can do this function by function, 116 00:05:50,800 --> 00:05:52,600 because you can call out into new code, 117 00:05:52,600 --> 00:05:54,800 and it really transitions slowly. 118 00:05:54,800 --> 00:05:57,600 And I think that's one of the greatest things 119 00:05:57,600 --> 00:06:00,400 with all these transitions that Apple always do, 120 00:06:00,400 --> 00:06:04,600 is making sure that you can do this byte size. 121 00:06:04,600 --> 00:06:07,200 And memory efficiency, especially on the server, 122 00:06:07,200 --> 00:06:08,600 is really, really important, 123 00:06:08,600 --> 00:06:11,600 because it's one of the things 124 00:06:11,600 --> 00:06:13,800 that hasn't really come down in price very much 125 00:06:13,800 --> 00:06:16,400 in the last few years. 126 00:06:16,400 --> 00:06:21,200 Large servers with lots of memory are still very expensive. 127 00:06:21,200 --> 00:06:24,600 And memory seems to be the thing that you actually pay. 128 00:06:24,600 --> 00:06:27,000 That's what bumps the price up. 129 00:06:27,000 --> 00:06:28,200 Yeah, absolutely. 130 00:06:28,200 --> 00:06:33,400 Our Linux builders are actually quite big in terms of memory, 131 00:06:33,400 --> 00:06:35,200 because builds often use a lot of memory. 132 00:06:35,200 --> 00:06:38,600 And CPU-wise, we wouldn't need the... 133 00:06:38,600 --> 00:06:40,600 I think it has an eight-core machine, 134 00:06:40,600 --> 00:06:42,600 which we wouldn't necessarily need. 135 00:06:42,600 --> 00:06:48,600 But the memory really drives up the price in that instance. 136 00:06:48,600 --> 00:06:50,000 Same with our Mac build machines. 137 00:06:50,000 --> 00:06:52,400 They've got an enormous amount of memory. 138 00:06:52,400 --> 00:06:57,400 And yeah, it's an expensive thing to do. 139 00:06:57,400 --> 00:06:59,400 Yeah. 140 00:06:59,400 --> 00:07:05,000 I think it's great to see Apple and the Swift team 141 00:07:05,000 --> 00:07:09,200 making these announcements at these community events. 142 00:07:09,200 --> 00:07:15,000 And especially, I don't know, I presume it was Tim 143 00:07:15,000 --> 00:07:17,200 and his team that were responsible for doing this, 144 00:07:17,200 --> 00:07:21,800 but they were incredibly quick getting the video out 145 00:07:21,800 --> 00:07:24,000 so that the announcement could actually be public, 146 00:07:24,000 --> 00:07:27,400 because that was the only downside to it a little bit. 147 00:07:27,400 --> 00:07:30,400 I heard about the announcement, 148 00:07:30,400 --> 00:07:32,400 but not being at the conference, 149 00:07:32,400 --> 00:07:34,000 I wanted to write about it, 150 00:07:34,000 --> 00:07:37,600 but I had almost nothing to go on to actually write about it. 151 00:07:37,600 --> 00:07:39,400 I could see the repository, of course, 152 00:07:39,400 --> 00:07:42,400 and the repository readme is useful, 153 00:07:42,400 --> 00:07:43,600 but it's not really the announcement. 154 00:07:43,600 --> 00:07:45,800 It doesn't give you any of the context or anything like that. 155 00:07:45,800 --> 00:07:48,800 Now, luckily, the Swift Server Conference 156 00:07:48,800 --> 00:07:51,400 did publish their videos within a week. 157 00:07:51,400 --> 00:07:53,400 So by the next week, 158 00:07:53,400 --> 00:07:55,800 I was able to link to the video as well. 159 00:07:55,800 --> 00:07:59,800 But I did have to kind of write about it a little bit blind. 160 00:07:59,800 --> 00:08:06,600 But I love that they're picking these venues to, 161 00:08:06,600 --> 00:08:09,800 like last year or in 2022, 162 00:08:09,800 --> 00:08:12,400 the announcement of the foundation 163 00:08:12,400 --> 00:08:16,400 and this year with the Java interop. 164 00:08:16,400 --> 00:08:19,400 Great. I applaud it. 165 00:08:19,400 --> 00:08:22,000 But if I could applaud it 166 00:08:22,000 --> 00:08:24,200 with also a blog post published at the same time, 167 00:08:24,200 --> 00:08:25,600 that would be even better. 168 00:08:25,600 --> 00:08:28,800 [laughs] 169 00:08:28,800 --> 00:08:31,600 Yeah. And speaking of the Swift Foundation announcement, 170 00:08:31,600 --> 00:08:33,000 Tony spoke to that a bit 171 00:08:33,000 --> 00:08:35,200 and gave a bit of a summary of what happened there 172 00:08:35,200 --> 00:08:38,400 and that the transition effectively is complete, 173 00:08:38,400 --> 00:08:43,000 like Swift Foundation is now shipping the open source one. 174 00:08:43,000 --> 00:08:46,000 That just happened during the Swift 6 beta phase 175 00:08:46,000 --> 00:08:49,800 that they switched over to the open source version 176 00:08:49,800 --> 00:08:52,000 of Swift Foundation, which is really nice 177 00:08:52,000 --> 00:08:56,800 because it aligns the APIs with the Linux world. 178 00:08:56,800 --> 00:08:59,400 This is a place where we've seen a couple of times 179 00:08:59,400 --> 00:09:01,800 when stuff wasn't quite there yet. 180 00:09:01,800 --> 00:09:05,400 So that's great to see. 181 00:09:05,400 --> 00:09:09,400 A few other talks I wanted to give a quick shout out. 182 00:09:09,400 --> 00:09:11,400 And this was a server-side Swift conference, 183 00:09:11,400 --> 00:09:13,800 but the reason I'm mentioning a few here 184 00:09:13,800 --> 00:09:16,200 is because they're more general. 185 00:09:16,200 --> 00:09:18,200 They're not server-specific really. 186 00:09:18,200 --> 00:09:20,800 Daniel Steinberg had a nice talk 187 00:09:20,800 --> 00:09:22,800 about when to make a macro. 188 00:09:22,800 --> 00:09:27,200 Really great talk going a bit into the details there. 189 00:09:27,200 --> 00:09:29,200 Franz Busch talked about leveraging 190 00:09:29,200 --> 00:09:31,400 structured concurrency in your applications. 191 00:09:31,400 --> 00:09:36,000 Again, giving a nice summary how to transition over, 192 00:09:36,000 --> 00:09:40,200 adopt concurrency, Swift 6 concurrency. 193 00:09:40,200 --> 00:09:44,200 Babit Vege, a bachelor student, 194 00:09:44,200 --> 00:09:46,600 gave a talk about stop worrying about roots 195 00:09:46,600 --> 00:09:48,800 with open API generator. 196 00:09:48,800 --> 00:09:52,800 I found that nice because while open API generator 197 00:09:52,800 --> 00:09:55,800 is obviously server-specific, 198 00:09:55,800 --> 00:09:57,800 you might have need for that. 199 00:09:57,800 --> 00:10:00,800 For instance, if you stand up a mock API, 200 00:10:00,800 --> 00:10:03,800 you're developing an app, and these days, 201 00:10:03,800 --> 00:10:07,400 I don't think, hardly any app gets developed 202 00:10:07,400 --> 00:10:09,200 right without talking to an API. 203 00:10:09,200 --> 00:10:12,400 And you might actually want to stand up something 204 00:10:12,400 --> 00:10:14,000 that you can connect your app to 205 00:10:14,000 --> 00:10:16,400 while maybe production doesn't exist yet 206 00:10:16,400 --> 00:10:19,400 or you want to inject some data, 207 00:10:19,400 --> 00:10:21,800 have some example data for testing 208 00:10:21,800 --> 00:10:24,800 or for generating screenshots, stuff like that. 209 00:10:24,800 --> 00:10:26,400 Depending on how you want to do that, 210 00:10:26,400 --> 00:10:29,400 it might be really nice to just take these 211 00:10:29,400 --> 00:10:31,200 open API specification, 212 00:10:31,200 --> 00:10:33,200 just run it through that generator 213 00:10:33,200 --> 00:10:35,200 and bring up a server that you connect to. 214 00:10:35,200 --> 00:10:38,200 So she gave a talk about that, 215 00:10:38,200 --> 00:10:41,600 how to use the open API generator. 216 00:10:41,600 --> 00:10:45,000 And then finally, Nick Lockwood with a really great talk. 217 00:10:45,000 --> 00:10:47,000 "So you think you know Swift?" 218 00:10:47,000 --> 00:10:50,000 And that was one of these where, you know, 219 00:10:50,000 --> 00:10:53,000 there's lots of things in Swift that seem weird 220 00:10:53,000 --> 00:10:55,000 and you sort of struggle with, 221 00:10:55,000 --> 00:10:58,000 especially around strings is like the classic example. 222 00:10:58,000 --> 00:11:03,000 Why can't you index into a Swift string? 223 00:11:03,000 --> 00:11:06,000 And he explains why there are these, 224 00:11:06,000 --> 00:11:08,000 why it is the way it is, 225 00:11:08,000 --> 00:11:10,000 and also brings up a couple of things 226 00:11:10,000 --> 00:11:13,000 that maybe people don't even know, 227 00:11:13,000 --> 00:11:15,000 because Swift is a big language, 228 00:11:15,000 --> 00:11:18,000 there's stuff that you don't typically come across. 229 00:11:18,000 --> 00:11:20,000 So that was a set of talks 230 00:11:20,000 --> 00:11:22,000 I wanted to mention from the conference. 231 00:11:22,000 --> 00:11:25,000 There were quite a few others, more service specific, 232 00:11:25,000 --> 00:11:28,000 but they're all great, they're all worth checking out. 233 00:11:28,000 --> 00:11:31,000 - That's great. - And we'll add links to the show notes. 234 00:11:31,000 --> 00:11:34,000 Sure, yeah. 235 00:11:34,000 --> 00:11:38,000 I also had a note from... 236 00:11:38,000 --> 00:11:41,000 Well, so in the previous episode, 237 00:11:41,000 --> 00:11:43,000 one of my packages that I talked about 238 00:11:43,000 --> 00:11:46,000 was called Chip8Kit, I think, 239 00:11:46,000 --> 00:11:49,000 or Chip8 something. 240 00:11:49,000 --> 00:11:51,000 And it was about an emulation 241 00:11:51,000 --> 00:11:56,000 of an old computer system called a Chip8. 242 00:11:56,000 --> 00:11:58,000 And I had a message from Mirza, 243 00:11:58,000 --> 00:12:00,000 who also got mentioned last episode 244 00:12:00,000 --> 00:12:03,000 as the person who contributed to the Swift package index, 245 00:12:03,000 --> 00:12:08,000 the forked from functionality that's now live on the site. 246 00:12:08,000 --> 00:12:11,000 And he dropped me a message on Discord 247 00:12:11,000 --> 00:12:15,000 and told me that a couple of years ago, 248 00:12:15,000 --> 00:12:19,000 he had built a Chip8 emulator, 249 00:12:19,000 --> 00:12:23,000 not as a Swift package, but as an iOS application. 250 00:12:23,000 --> 00:12:26,000 So if you were curious about the Chip8 system 251 00:12:26,000 --> 00:12:28,000 that we talked about last time, 252 00:12:28,000 --> 00:12:30,000 and wanted to play... 253 00:12:30,000 --> 00:12:32,000 Well, the screenshot on the Git repository 254 00:12:32,000 --> 00:12:40,000 is playing Pong on the Chip8 system. 255 00:12:40,000 --> 00:12:42,000 Or Tic-Tac-Toe, I think, as well, 256 00:12:42,000 --> 00:12:44,000 or maybe Snake as well. 257 00:12:44,000 --> 00:12:47,000 If you wanted to have an iOS version of that, 258 00:12:47,000 --> 00:12:51,000 I think it's worth to mention that there is this repository, 259 00:12:51,000 --> 00:12:54,000 and we'll put a link in the show notes to that as well. 260 00:12:54,000 --> 00:12:57,000 So thanks for the update on that, Mirza. 261 00:12:57,000 --> 00:12:59,000 Nice. 262 00:12:59,000 --> 00:13:04,000 Another thing worth mentioning is a new repository. 263 00:13:04,000 --> 00:13:06,000 I think it's--yeah, it's fairly new. 264 00:13:06,000 --> 00:13:11,000 It's GitHub Actions Workflows repository on Swift Lang. 265 00:13:11,000 --> 00:13:15,000 And what this does, it collects typical things 266 00:13:15,000 --> 00:13:17,000 you might want to run in your CI system. 267 00:13:17,000 --> 00:13:21,000 And I find that really nice because I tend to, 268 00:13:21,000 --> 00:13:23,000 you know, sort of copy bits around 269 00:13:23,000 --> 00:13:28,000 from my previous repositories when I need something 270 00:13:28,000 --> 00:13:31,000 or from, like, well-known repositories 271 00:13:31,000 --> 00:13:33,000 where I know they have solid setup, 272 00:13:33,000 --> 00:13:36,000 and I just steal bits and pieces here and there. 273 00:13:36,000 --> 00:13:39,000 But what this does is sort of--I think the idea is there 274 00:13:39,000 --> 00:13:42,000 for this to be the way to get started 275 00:13:42,000 --> 00:13:46,000 with a CI setup for a Swift package on GitHub 276 00:13:46,000 --> 00:13:47,000 with GitHub Actions. 277 00:13:47,000 --> 00:13:49,000 It has the typical thing you'd expect, 278 00:13:49,000 --> 00:13:51,000 like running tests. 279 00:13:51,000 --> 00:13:55,000 And it also has something which they call soundness checks, 280 00:13:55,000 --> 00:13:58,000 and that's stuff like formatting checks, linting, 281 00:13:58,000 --> 00:14:01,000 license checks, you know, that your files have 282 00:14:01,000 --> 00:14:04,000 license headers and that stuff. 283 00:14:04,000 --> 00:14:06,000 And you can configure this. 284 00:14:06,000 --> 00:14:08,000 You know, you can use these. 285 00:14:08,000 --> 00:14:10,000 You can--I think there's a YAML file you can use 286 00:14:10,000 --> 00:14:12,000 to specify which parts you want to run, 287 00:14:12,000 --> 00:14:13,000 that sort of stuff. 288 00:14:13,000 --> 00:14:16,000 It's great to see that appearing. 289 00:14:16,000 --> 00:14:19,000 The only problem right now, as far as I could tell, 290 00:14:19,000 --> 00:14:21,000 this is currently only supporting Linux, 291 00:14:21,000 --> 00:14:25,000 so if you need to run this on macOS, 292 00:14:25,000 --> 00:14:29,000 you'll have to wait a bit longer for that support to appear 293 00:14:29,000 --> 00:14:31,000 or make a contribution to add it. 294 00:14:31,000 --> 00:14:32,000 Of course, yeah. 295 00:14:32,000 --> 00:14:35,000 It's also probably worth mentioning at this point, 296 00:14:35,000 --> 00:14:37,000 have you heard of a tool called Danger? 297 00:14:37,000 --> 00:14:38,000 Yes, I have, yeah. 298 00:14:38,000 --> 00:14:41,000 Yeah, so Danger does some similar things to that, 299 00:14:41,000 --> 00:14:44,000 like checking license terms and other things 300 00:14:44,000 --> 00:14:46,000 that you can configure that it will check 301 00:14:46,000 --> 00:14:50,000 as a kind of sanity check before your code goes in. 302 00:14:50,000 --> 00:14:53,000 And I think that--I believe that does support Mac as well. 303 00:14:53,000 --> 00:14:55,000 It has been around for quite a while, 304 00:14:55,000 --> 00:14:57,000 so it's probably just worth mentioning that as well 305 00:14:57,000 --> 00:14:58,000 at this point. 306 00:14:58,000 --> 00:14:59,000 Yeah. 307 00:14:59,000 --> 00:15:02,000 So that's kind of action workflows, 308 00:15:02,000 --> 00:15:05,000 and we'll add the link to the show notes. 309 00:15:05,000 --> 00:15:09,000 So are we planning to implement some of those checks? 310 00:15:09,000 --> 00:15:12,000 Well, yeah, I think it might be worth looking 311 00:15:12,000 --> 00:15:15,000 at which parts we could use. 312 00:15:15,000 --> 00:15:19,000 I actually added an issue to our issue tracker 313 00:15:19,000 --> 00:15:21,000 to at least explore what the options are. 314 00:15:21,000 --> 00:15:23,000 I had a quick scan. 315 00:15:23,000 --> 00:15:27,000 There's quite a lot in there already, 316 00:15:27,000 --> 00:15:29,000 and I think some of it would certainly be useful, 317 00:15:29,000 --> 00:15:31,000 like the soundness checks license. 318 00:15:31,000 --> 00:15:35,000 I mean, I think we're pretty--we don't add new files 319 00:15:35,000 --> 00:15:38,000 that often these days, and I don't think we miss 320 00:15:38,000 --> 00:15:41,000 adding the header, but just having that check in there 321 00:15:41,000 --> 00:15:43,000 would be nice. 322 00:15:43,000 --> 00:15:44,000 Formatting, certainly. 323 00:15:44,000 --> 00:15:46,000 I think you wrote about formatting as well 324 00:15:46,000 --> 00:15:49,000 on "Iris Dev Weekly" last week, didn't you? 325 00:15:49,000 --> 00:15:51,000 I did, yeah. 326 00:15:51,000 --> 00:15:56,000 A rather opinionated piece, which I got lots of feedback 327 00:15:56,000 --> 00:15:57,000 in both directions on. 328 00:15:57,000 --> 00:15:58,000 Oh, do say. 329 00:15:58,000 --> 00:15:59,000 There was more-- 330 00:15:59,000 --> 00:16:00,000 About formatting. 331 00:16:00,000 --> 00:16:02,000 [laughter] 332 00:16:02,000 --> 00:16:05,000 There were more--there was more people in agreement 333 00:16:05,000 --> 00:16:09,000 with me than against me, but it was about 70/30, 334 00:16:09,000 --> 00:16:10,000 I would say. 335 00:16:10,000 --> 00:16:17,000 Yeah, I'd love seeing something like that be around, 336 00:16:17,000 --> 00:16:19,000 like integrated and running by default. 337 00:16:19,000 --> 00:16:22,000 I was nodding along as I read your comment 338 00:16:22,000 --> 00:16:24,000 about formatting on save. 339 00:16:24,000 --> 00:16:26,000 I'm glad at least we're in agreement, 340 00:16:26,000 --> 00:16:29,000 because that's a good start. 341 00:16:29,000 --> 00:16:33,000 Somebody did actually drop me a note saying 342 00:16:33,000 --> 00:16:40,000 that they had published an Xcode plugin 343 00:16:40,000 --> 00:16:45,000 using the new single-file Xcode extension architecture 344 00:16:45,000 --> 00:16:51,000 that you combine Command-S to, and effectively what it does 345 00:16:51,000 --> 00:16:54,000 is it runs Swift format instead of saving, 346 00:16:54,000 --> 00:16:56,000 but of course the Swift format then does the save. 347 00:16:56,000 --> 00:16:59,000 So effectively, you can do what I was asking for. 348 00:16:59,000 --> 00:17:02,000 And if anyone's clueless about what we're talking about here, 349 00:17:02,000 --> 00:17:06,000 just go and read the latest issue of iOS Dev Weekly, 350 00:17:06,000 --> 00:17:13,000 which is issue 682, and I talked about Swift format 351 00:17:13,000 --> 00:17:16,000 and code formatting. 352 00:17:16,000 --> 00:17:19,000 But I think my point was--and that's-- 353 00:17:19,000 --> 00:17:23,000 an extension like that is fine, but my point was a bit bigger 354 00:17:23,000 --> 00:17:27,000 than that in that I'd love to see--first of all, 355 00:17:27,000 --> 00:17:29,000 I'd love to see a standard, and I don't-- 356 00:17:29,000 --> 00:17:32,000 nobody's going to agree on the standard, 357 00:17:32,000 --> 00:17:34,000 but I'd love for Apple to just say, 358 00:17:34,000 --> 00:17:36,000 "This is how we format Swift code," 359 00:17:36,000 --> 00:17:38,000 just like Go did, just like JavaScript did. 360 00:17:38,000 --> 00:17:42,000 And this problem just goes away after somebody does that, 361 00:17:42,000 --> 00:17:45,000 but it needs to be somebody who's with authority. 362 00:17:45,000 --> 00:17:49,000 It needs to effectively be Apple who'd do it. 363 00:17:49,000 --> 00:17:51,000 And then, of course, I would also love to see 364 00:17:51,000 --> 00:17:54,000 auto-format on save, which is the key thing, 365 00:17:54,000 --> 00:17:57,000 because at that point, you can just forget about formatting. 366 00:17:57,000 --> 00:18:01,000 And I say this with experience, because I've had this switched 367 00:18:01,000 --> 00:18:04,000 on in JavaScript and CSS for a very long time now, 368 00:18:04,000 --> 00:18:09,000 and I don't even bother trying to get the indentation right. 369 00:18:09,000 --> 00:18:13,000 I just type whatever I want and hit save, and it's done. 370 00:18:13,000 --> 00:18:15,000 - Yeah, yeah. - It's so freeing. 371 00:18:15,000 --> 00:18:19,000 It's great. 372 00:18:19,000 --> 00:18:22,000 It's just a thing you don't have to worry about anymore. 373 00:18:22,000 --> 00:18:23,000 It's great. 374 00:18:23,000 --> 00:18:28,000 Anyway, so before you set me off on my rant again, let me stop. 375 00:18:28,000 --> 00:18:32,000 All right. 376 00:18:32,000 --> 00:18:35,000 And finally, I wanted to mention something really neat 377 00:18:35,000 --> 00:18:37,000 that I saw on the Swift forums. 378 00:18:37,000 --> 00:18:41,000 I think it was just yesterday at time of recording, 379 00:18:41,000 --> 00:18:44,000 and there's a pitch up for the vector type, 380 00:18:44,000 --> 00:18:47,000 which is a fixed-size arrays type, 381 00:18:47,000 --> 00:18:51,000 and there was Caroy Llorente. 382 00:18:51,000 --> 00:18:54,000 I think he certainly works at Apple, 383 00:18:54,000 --> 00:18:57,000 and I think he's also one of the authors of the proposal 384 00:18:57,000 --> 00:18:59,000 and the implementation. 385 00:18:59,000 --> 00:19:02,000 He talked about--as you might imagine, 386 00:19:02,000 --> 00:19:05,000 there's a discussion about naming on the Swift forums, 387 00:19:05,000 --> 00:19:06,000 and he talks-- 388 00:19:06,000 --> 00:19:08,000 I just can't remember naming. 389 00:19:08,000 --> 00:19:10,000 That should be quick and simple. 390 00:19:10,000 --> 00:19:13,000 Inconceivable. 391 00:19:13,000 --> 00:19:16,000 And he comes out in favor of the name vector 392 00:19:16,000 --> 00:19:21,000 and tells a little story how they arrived at the name. 393 00:19:21,000 --> 00:19:23,000 It wasn't actually named that initially. 394 00:19:23,000 --> 00:19:25,000 And he says, "That very same day, 395 00:19:25,000 --> 00:19:28,000 two separate groups of people independently realized 396 00:19:28,000 --> 00:19:33,000 that copyability has now turned this type into a true vector, 397 00:19:33,000 --> 00:19:37,000 and that vector is the obviously right name for this construct. 398 00:19:37,000 --> 00:19:40,000 This made for a comical scene when members of the two groups 399 00:19:40,000 --> 00:19:42,000 met later in the day, 400 00:19:42,000 --> 00:19:45,000 fully expecting that they need to convince the other." 401 00:19:45,000 --> 00:19:47,000 I thought that was really neat 402 00:19:47,000 --> 00:19:51,000 when people actually independently arrive at the same conclusion 403 00:19:51,000 --> 00:19:55,000 and then feel like, "Oh, God, I've got to convince someone 404 00:19:55,000 --> 00:19:58,000 of a different name," which I can imagine. 405 00:19:58,000 --> 00:20:02,000 We see these discussions happen all the time, right? 406 00:20:02,000 --> 00:20:04,000 When people have settled on a name, 407 00:20:04,000 --> 00:20:09,000 it can be really hard to convince them of a different name. 408 00:20:09,000 --> 00:20:11,000 So, yeah, I found that really neat. 409 00:20:11,000 --> 00:20:13,000 Yes, yeah. 410 00:20:13,000 --> 00:20:15,000 Shall we do some packages? 411 00:20:15,000 --> 00:20:17,000 Let's do some packages. 412 00:20:17,000 --> 00:20:20,000 I've only got two, so I'm going to let you kick us off. 413 00:20:20,000 --> 00:20:21,000 Sure thing. 414 00:20:21,000 --> 00:20:25,000 I can kick us off with a package from Christian Selig 415 00:20:25,000 --> 00:20:27,000 called TinyStorage. 416 00:20:27,000 --> 00:20:31,000 And it's a simple, lightweight replacement for user defaults 417 00:20:31,000 --> 00:20:34,000 that makes access a little more straightforward, 418 00:20:34,000 --> 00:20:36,000 plus some niceties. 419 00:20:36,000 --> 00:20:42,000 So the readme of this starts with a link to a blog post, 420 00:20:42,000 --> 00:20:46,000 actually, where Christian was having some issues 421 00:20:46,000 --> 00:20:49,000 with user defaults. 422 00:20:49,000 --> 00:20:54,000 And I think it was largely around needing to access user defaults 423 00:20:54,000 --> 00:20:57,000 kind of immediately at the app startup, 424 00:20:57,000 --> 00:21:01,000 and there were some kind of inconsistencies there 425 00:21:01,000 --> 00:21:07,000 with things not quite being ready when he needed them. 426 00:21:07,000 --> 00:21:14,000 So I think he looked at building an alternative, 427 00:21:14,000 --> 00:21:18,000 and it must admit it looks like he's done 428 00:21:18,000 --> 00:21:21,000 a very thorough job of doing this. 429 00:21:21,000 --> 00:21:25,000 So some of the features that it has, the primary one, 430 00:21:25,000 --> 00:21:29,000 the first bullet in the list is relating to that point 431 00:21:29,000 --> 00:21:31,000 that I just mentioned there, which is reliable access, 432 00:21:31,000 --> 00:21:35,000 either on first reboot or in application pre-warming states, 433 00:21:35,000 --> 00:21:39,000 TinyStorage will read and write data properly. 434 00:21:39,000 --> 00:21:41,000 It's got a code on support, of course. 435 00:21:41,000 --> 00:21:49,000 It's got a property wrapper for an app storage-like wrapper 436 00:21:49,000 --> 00:21:52,000 that you can use in SwiftUI and things like that. 437 00:21:52,000 --> 00:21:57,000 You can subscribe to notification center, 438 00:21:57,000 --> 00:22:00,000 notifications when things change. 439 00:22:00,000 --> 00:22:03,000 It uses OS log for logging. 440 00:22:03,000 --> 00:22:08,000 So it's really -- and I think I listed like four or five 441 00:22:08,000 --> 00:22:11,000 of the 12 bullet points that are in the features list there. 442 00:22:11,000 --> 00:22:14,000 So it's quite a comprehensive package. 443 00:22:14,000 --> 00:22:18,000 It is brand new, so of course, be a little cautious 444 00:22:18,000 --> 00:22:20,000 with a package that is brand new, 445 00:22:20,000 --> 00:22:23,000 because all brand-new code has bugs in it. 446 00:22:23,000 --> 00:22:24,000 Of course it does. 447 00:22:24,000 --> 00:22:27,000 It's only been in development for six days, 448 00:22:27,000 --> 00:22:30,000 and I believe it's been out a few days ago. 449 00:22:30,000 --> 00:22:35,000 So it is -- presumably it was a clean commit just before 450 00:22:35,000 --> 00:22:39,000 the open source release, because I am sure it had development 451 00:22:39,000 --> 00:22:43,000 before six days ago. 452 00:22:43,000 --> 00:22:46,000 But, yes, it is -- oh, and it looks like it also has 453 00:22:46,000 --> 00:22:51,000 a mechanism similar to app groups for sharing data 454 00:22:51,000 --> 00:22:55,000 between your applications on the same phone, 455 00:22:55,000 --> 00:22:57,000 so from the same developer. 456 00:22:57,000 --> 00:22:59,000 I haven't looked into that in great detail, 457 00:22:59,000 --> 00:23:00,000 but I just noticed it now. 458 00:23:00,000 --> 00:23:02,000 So it looks great. 459 00:23:02,000 --> 00:23:09,000 I mean, it's effectively user defaults, but different. 460 00:23:09,000 --> 00:23:11,000 Yes, and I think it's worth calling out -- you mentioned it 461 00:23:11,000 --> 00:23:13,000 in a quote from the readme. 462 00:23:13,000 --> 00:23:17,000 I think it fixes one of these -- the problem that spawned 463 00:23:17,000 --> 00:23:18,000 this whole thing. 464 00:23:18,000 --> 00:23:22,000 I saw the blog post, and I think it's worth calling out 465 00:23:22,000 --> 00:23:26,000 what actually can happen with stock user defaults. 466 00:23:26,000 --> 00:23:30,000 When an app is launched in the pre-warming phase 467 00:23:30,000 --> 00:23:34,000 or by some other means while the device is locked, 468 00:23:34,000 --> 00:23:39,000 it can happen that user defaults isn't accessible 469 00:23:39,000 --> 00:23:43,000 and then gets reset to the app's stock defaults, 470 00:23:43,000 --> 00:23:45,000 and then you lose the data that's in it. 471 00:23:45,000 --> 00:23:49,000 And that's the investigation that -- I think this triggered him 472 00:23:49,000 --> 00:23:52,000 to write this replacement, which doesn't have that problem. 473 00:23:52,000 --> 00:23:53,000 Right. 474 00:23:53,000 --> 00:23:56,000 I believe the keychain can also get in that state as well, 475 00:23:56,000 --> 00:23:59,000 because if the phone is locked and the keychain gets locked, 476 00:23:59,000 --> 00:24:01,000 and if you're trying to access keychain in the background, 477 00:24:01,000 --> 00:24:04,000 that can also be a similar problem. 478 00:24:04,000 --> 00:24:07,000 Yes, or it might be -- I think user defaults can be -- 479 00:24:07,000 --> 00:24:11,000 they can have an attribute, whether they're secured or not. 480 00:24:11,000 --> 00:24:14,000 It's worth looking into the details, 481 00:24:14,000 --> 00:24:17,000 looking at that blog post that outlines what the problem is, 482 00:24:17,000 --> 00:24:20,000 and this is apparently a real problem, 483 00:24:20,000 --> 00:24:23,000 and presumably the package doesn't have that problem, 484 00:24:23,000 --> 00:24:24,000 so that's nice. 485 00:24:24,000 --> 00:24:29,000 The blog post is linked from the top of the README file, 486 00:24:29,000 --> 00:24:32,000 so it's literally the first link in the file. 487 00:24:32,000 --> 00:24:34,000 Yes. There you go. 488 00:24:34,000 --> 00:24:37,000 So that's Tiny Storage by Christian Selig. 489 00:24:37,000 --> 00:24:38,000 Nice. 490 00:24:38,000 --> 00:24:43,000 My first pick is called Recap by Joe Fabicevic, 491 00:24:43,000 --> 00:24:49,000 and you've also linked to this package in IoStep Weekly from Friday. 492 00:24:49,000 --> 00:24:54,000 And this is a really nice "What's new" screen for your iOS app, 493 00:24:54,000 --> 00:24:55,000 and it's iOS only. 494 00:24:55,000 --> 00:24:57,000 I was actually surprised to see this. 495 00:24:57,000 --> 00:25:00,000 It doesn't even call out iPadOS, 496 00:25:00,000 --> 00:25:04,000 so I'm not sure what the state there is. 497 00:25:04,000 --> 00:25:07,000 It's worth looking into if you need this for the iPad. 498 00:25:07,000 --> 00:25:11,000 But it looks really simple to use. 499 00:25:11,000 --> 00:25:15,000 You have a YAML file where you configure what should be on that screen. 500 00:25:15,000 --> 00:25:22,000 You can give an entry, a title, a description, a SF symbol, name, and a color, 501 00:25:22,000 --> 00:25:24,000 and then it does a really nice layout. 502 00:25:24,000 --> 00:25:27,000 I mean, "What's new" screen, you know what these look like, 503 00:25:27,000 --> 00:25:31,000 and all you really need to do is add the dependency 504 00:25:31,000 --> 00:25:36,000 and write this little YAML file, and then it does it all for you. 505 00:25:36,000 --> 00:25:41,000 And I think this is one of these things that is getting more important 506 00:25:41,000 --> 00:25:47,000 because I hardly look at release notes in the App Store anymore 507 00:25:47,000 --> 00:25:51,000 because I have, like for ages now, I've had auto-update enabled, right? 508 00:25:51,000 --> 00:25:56,000 So apps just update, and I never see what's new. 509 00:25:56,000 --> 00:25:59,000 And I do actually quite like these screens. 510 00:25:59,000 --> 00:26:03,000 I mean, maybe not every small update needs a screen like that, 511 00:26:03,000 --> 00:26:06,000 but if you have, like, bigger changes, 512 00:26:06,000 --> 00:26:09,000 I think that's a really nice way to tell the user, you know, 513 00:26:09,000 --> 00:26:12,000 "This is what's new. Have a look," 514 00:26:12,000 --> 00:26:16,000 or explain why something might be in a different place or something like that. 515 00:26:16,000 --> 00:26:22,000 So a really nice package to deal with this aspect. 516 00:26:22,000 --> 00:26:24,000 I really like this, too. I thought it was great. 517 00:26:24,000 --> 00:26:28,000 And I think there's a couple of things worth mentioning with this. 518 00:26:28,000 --> 00:26:33,000 I think you're not alone in not reading release notes anymore. 519 00:26:33,000 --> 00:26:36,000 Nobody reads release notes because everybody-- 520 00:26:36,000 --> 00:26:39,000 because updates are on by default, 521 00:26:39,000 --> 00:26:42,000 and I don't remember the last time I went into updates 522 00:26:42,000 --> 00:26:44,000 to even see what was pending. 523 00:26:44,000 --> 00:26:47,000 It just takes care of itself, and I never check it, 524 00:26:47,000 --> 00:26:49,000 which means I never see any of the update notes. 525 00:26:49,000 --> 00:26:53,000 It was never the greatest place to put really important information 526 00:26:53,000 --> 00:26:57,000 because a lot of people never checked there. 527 00:26:57,000 --> 00:27:02,000 And even if they did manually update, all they did was hit Update All. 528 00:27:02,000 --> 00:27:04,000 So, yeah, it's never been the best place. 529 00:27:04,000 --> 00:27:09,000 But one thing I liked about this is that you can actually page back 530 00:27:09,000 --> 00:27:13,000 through previous--like it's almost a release notes, 531 00:27:13,000 --> 00:27:15,000 a changelog system as well. 532 00:27:15,000 --> 00:27:19,000 So, yes, you have the one that comes up on the screen when people launch, 533 00:27:19,000 --> 00:27:23,000 but if they're interested, they can page back through previous ones 534 00:27:23,000 --> 00:27:26,000 to see what happened to the app in previous updates. 535 00:27:26,000 --> 00:27:29,000 So I thought that was a nice feature worth mentioning as well. 536 00:27:29,000 --> 00:27:31,000 That's nice. I hadn't even seen that. That's great. 537 00:27:31,000 --> 00:27:32,000 That's great. 538 00:27:32,000 --> 00:27:37,000 So that's Recap by Joe Fabicevic. 539 00:27:37,000 --> 00:27:44,000 My next pick is Location Radius Picker by Eman Basic. 540 00:27:44,000 --> 00:27:50,000 And this is a UI view controller subclass. 541 00:27:50,000 --> 00:27:56,000 So I presume you could wrap it in a UI view controller. 542 00:27:56,000 --> 00:27:59,000 What's the wrapper class that you can wrap it into SwiftUI? 543 00:27:59,000 --> 00:28:06,000 It's designed initially for UI kits rather than SwiftUI, 544 00:28:06,000 --> 00:28:11,000 but it's just a really nice implementation of a control that you don't get 545 00:28:11,000 --> 00:28:14,000 for kind of built in with UI kits, 546 00:28:14,000 --> 00:28:19,000 which is selecting a radius over the top of a map kit map. 547 00:28:19,000 --> 00:28:25,000 So you don't want to just select a single pinpoint on the map, 548 00:28:25,000 --> 00:28:27,000 which I believe it does do. 549 00:28:27,000 --> 00:28:35,000 If you want to give the application a X meter radius around a point, 550 00:28:35,000 --> 00:28:38,000 then this is a really well-designed version of that. 551 00:28:38,000 --> 00:28:40,000 And when you zoom the map in and out, 552 00:28:40,000 --> 00:28:44,000 your selected radius also scales nicely with the map. 553 00:28:44,000 --> 00:28:47,000 It also tells you how big the radius is. 554 00:28:47,000 --> 00:28:51,000 So as you drag the circle out across the map, 555 00:28:51,000 --> 00:28:53,000 you'll see that it starts as, you know, 556 00:28:53,000 --> 00:28:55,000 you drag it once and it's a 50 meter radius, 557 00:28:55,000 --> 00:28:57,000 and you zoom out a little bit and drag it again. 558 00:28:57,000 --> 00:28:59,000 Now it's a two kilometer radius. 559 00:28:59,000 --> 00:29:05,000 And again, what caught my eye with this is a fantastic demo video 560 00:29:05,000 --> 00:29:08,000 at the top of the readme file, which is always really important 561 00:29:08,000 --> 00:29:11,000 if you're building anything that has a visual component. 562 00:29:11,000 --> 00:29:15,000 The very first thing you should do is show people what it looks like. 563 00:29:15,000 --> 00:29:18,000 And it was that that caught my eye. 564 00:29:18,000 --> 00:29:22,000 And yeah, I thought this was just a useful little thing 565 00:29:22,000 --> 00:29:24,000 that you're not going to need this every day, 566 00:29:24,000 --> 00:29:27,000 but when you need it, this seemed like a well-designed one. 567 00:29:27,000 --> 00:29:30,000 Nice. That sounds great. 568 00:29:30,000 --> 00:29:36,000 Okay. My second pick is called Swift Async Operations by Matsuji. 569 00:29:36,000 --> 00:29:39,000 And I only got this GitHub handle here. 570 00:29:39,000 --> 00:29:43,000 Unfortunately, GitHub itself only lists that name as well. 571 00:29:43,000 --> 00:29:46,000 And that's a really interesting library that deals with an API 572 00:29:46,000 --> 00:29:48,000 that I kind of struggle with. 573 00:29:48,000 --> 00:29:53,000 I mean, it's fine, but it feels a bit... 574 00:29:53,000 --> 00:29:57,000 I don't know how to describe it. I'll explain what it's about. 575 00:29:57,000 --> 00:30:02,000 So Async Let is a simple way to start concurrent tasks, right, 576 00:30:02,000 --> 00:30:06,000 in Swift Async Await land. 577 00:30:06,000 --> 00:30:10,000 And you use that when you have a certain number of... 578 00:30:10,000 --> 00:30:12,000 a fixed number of tasks that you want to fire off. 579 00:30:12,000 --> 00:30:15,000 You know, for instance, you know I've got these two URLs to fetch, 580 00:30:15,000 --> 00:30:17,000 and you do Async Let for both of them, 581 00:30:17,000 --> 00:30:21,000 and then you await, and then they run concurrently. 582 00:30:21,000 --> 00:30:26,000 Now, if you have a number n of tasks, 583 00:30:26,000 --> 00:30:29,000 and you don't know an indeterminate number, 584 00:30:29,000 --> 00:30:32,000 and you want to, for instance, create them, 585 00:30:32,000 --> 00:30:34,000 spin off these tasks in a loop, 586 00:30:34,000 --> 00:30:37,000 you would use the With Task Group API. 587 00:30:37,000 --> 00:30:42,000 And that's the thing that I find really, like, 588 00:30:42,000 --> 00:30:44,000 I don't know how to describe it. 589 00:30:44,000 --> 00:30:46,000 Suddenly you need a lot of boilerplate, 590 00:30:46,000 --> 00:30:49,000 where previously Async Let is so lean, right? 591 00:30:49,000 --> 00:30:53,000 You don't even realize, maybe that's even a problem. 592 00:30:53,000 --> 00:30:55,000 You don't realize you're spinning up a task, 593 00:30:55,000 --> 00:30:57,000 but it's a really lean API. 594 00:30:57,000 --> 00:31:02,000 And then suddenly when you need, you know, I don't have just two. 595 00:31:02,000 --> 00:31:04,000 I have n. I need to... 596 00:31:04,000 --> 00:31:07,000 I can't just write a for loop or something, or have a map, 597 00:31:07,000 --> 00:31:09,000 and this is what this package does. 598 00:31:09,000 --> 00:31:11,000 You then have to employ this whole With Task Group thing, 599 00:31:11,000 --> 00:31:14,000 and then the group thing needs to do the add task, 600 00:31:14,000 --> 00:31:16,000 and then at the end you have to await the results, 601 00:31:16,000 --> 00:31:18,000 and there you'd loop. 602 00:31:18,000 --> 00:31:20,000 It's a weird... 603 00:31:20,000 --> 00:31:23,000 You know, you have this progressive disclosure normally, 604 00:31:23,000 --> 00:31:25,000 and this feels like, oh, I'm progressively... 605 00:31:25,000 --> 00:31:28,000 Boof, there's a truck. That hits me. 606 00:31:28,000 --> 00:31:30,000 It's not really progressive. 607 00:31:30,000 --> 00:31:32,000 It's like a cliff you're hitting. 608 00:31:32,000 --> 00:31:33,000 A progressive brick wall. 609 00:31:33,000 --> 00:31:35,000 Yeah, exactly. 610 00:31:35,000 --> 00:31:40,000 So this introduces an Async Map and an Async For Each. 611 00:31:40,000 --> 00:31:43,000 And I know For Each is controversial. 612 00:31:43,000 --> 00:31:46,000 Some people argue it shouldn't even be in the language, 613 00:31:46,000 --> 00:31:51,000 but there is sort of a reason why it perhaps should exist here 614 00:31:51,000 --> 00:31:58,000 in this specific case, and the reason is that both these method calls 615 00:31:58,000 --> 00:32:02,000 have taken optional parameter number of concurrent tasks 616 00:32:02,000 --> 00:32:05,000 where you can control, like map over something, 617 00:32:05,000 --> 00:32:08,000 Async Map over a collection, 618 00:32:08,000 --> 00:32:10,000 and then you can say number of concurrent tasks, 619 00:32:10,000 --> 00:32:13,000 and it'll fan out up to that concurrency 620 00:32:13,000 --> 00:32:16,000 and do the things in concurrent tasks. 621 00:32:16,000 --> 00:32:20,000 And Async For Each is the same, just not-- 622 00:32:20,000 --> 00:32:25,000 it's like a proper for loop without returning something like the map does. 623 00:32:25,000 --> 00:32:28,000 I mean, obviously you could abuse map in that same sense, 624 00:32:28,000 --> 00:32:32,000 but just API-wise, that's the distinction. 625 00:32:32,000 --> 00:32:35,000 Now, I haven't looked at the implementation. 626 00:32:35,000 --> 00:32:39,000 Take all of this with a grain of salt because there's lots of Async Awaits 627 00:32:39,000 --> 00:32:42,000 stuff happening, and people are still finding their way 628 00:32:42,000 --> 00:32:44,000 how to best do things. 629 00:32:44,000 --> 00:32:47,000 I really wanted to highlight the package, perhaps not so much 630 00:32:47,000 --> 00:32:51,000 as a thing you should jump and use immediately. 631 00:32:51,000 --> 00:32:57,000 Certainly, if you need it, have a look at the implementation, 632 00:32:57,000 --> 00:33:03,000 but also maybe in talking about whether the With Task Group API 633 00:33:03,000 --> 00:33:09,000 could perhaps have a more sugary variant. 634 00:33:09,000 --> 00:33:15,000 That is a bit nicer to use because I feel like I really-- 635 00:33:15,000 --> 00:33:17,000 A, I need to look it up. 636 00:33:17,000 --> 00:33:20,000 I can't just write a With Task Group thing and then the awaiting stuff 637 00:33:20,000 --> 00:33:21,000 at the end. 638 00:33:21,000 --> 00:33:22,000 I need to look it up. 639 00:33:22,000 --> 00:33:23,000 I can't-- for loop, I can write. 640 00:33:23,000 --> 00:33:25,000 A map, I can write. 641 00:33:25,000 --> 00:33:27,000 For each, I can write. 642 00:33:27,000 --> 00:33:28,000 With Task Group, I can't. 643 00:33:28,000 --> 00:33:29,000 I need to look it up. 644 00:33:29,000 --> 00:33:33,000 And I feel like there's a-- that's telling me something. 645 00:33:33,000 --> 00:33:37,000 I think that API could perhaps be easier, 646 00:33:37,000 --> 00:33:43,000 and maybe that package has ideas what that API could look like. 647 00:33:43,000 --> 00:33:47,000 Anyway, that's why I thought it was interesting. 648 00:33:47,000 --> 00:33:50,000 Swift Async Operations by Matsuchi. 649 00:33:50,000 --> 00:33:53,000 And it's worth mentioning-- you briefly mentioned it there. 650 00:33:53,000 --> 00:33:58,000 On the topic, we quite often say when we're talking about packages here, 651 00:33:58,000 --> 00:34:02,000 we quite often term them recommendations, 652 00:34:02,000 --> 00:34:08,000 but all we're ever saying with these picks of packages is this is something 653 00:34:08,000 --> 00:34:10,000 that we've found interesting. 654 00:34:10,000 --> 00:34:13,000 This is not a, you know, we've checked through every line of code 655 00:34:13,000 --> 00:34:16,000 and made sure that this package is perfect in every way. 656 00:34:16,000 --> 00:34:19,000 Like some of the packages we've talked about today are, for example, 657 00:34:19,000 --> 00:34:24,000 six days old, and they're being mentioned more as a notable event 658 00:34:24,000 --> 00:34:29,000 rather than an outright recommendation because we can't possibly have used 659 00:34:29,000 --> 00:34:33,000 all the packages we talk about on this podcast. 660 00:34:33,000 --> 00:34:36,000 Although we try, if you look at the number of dependencies 661 00:34:36,000 --> 00:34:42,000 in the Swift Package Index Server project, we are certainly trying. 662 00:34:42,000 --> 00:34:46,000 Well, a lot of those dependencies come with vapor, right? 663 00:34:46,000 --> 00:34:50,000 Well, I still maintain we are the Swift Package Index. 664 00:34:50,000 --> 00:34:56,000 We have an obligation to just try them all. 665 00:34:56,000 --> 00:35:01,000 And with that, it brings another episode to a close. 666 00:35:01,000 --> 00:35:09,000 So I think we will call it a day there and speak to you next time. 667 00:35:09,000 --> 00:35:11,000 And for now, we will say goodbye. 668 00:35:11,000 --> 00:35:13,000 Yep. See you next time. Bye-bye.