1 00:00:00,000 --> 00:00:05,440 I have a prediction for your recommendations on today's podcast. 2 00:00:05,440 --> 00:00:10,440 And I know we're not talking about recommendations yet, but I want to make this prediction before we even get started. 3 00:00:10,440 --> 00:00:18,440 I predict that all three of your package recommendations today will be Swift 5.9 only. 4 00:00:18,440 --> 00:00:23,440 Interesting. Should I give you the answer already? 5 00:00:23,440 --> 00:00:27,440 You can give me the answer. Yeah, sure. Not what they are, but the... 6 00:00:27,440 --> 00:00:37,120 [BUZZER] Well, actually, let me check because I'm pretty sure that it's not 5.9 only. Oh, 7 00:00:37,120 --> 00:00:44,800 it's not. No, no, I would have bet that it isn't. No, there's one that isn't. 8 00:00:44,800 --> 00:00:52,160 Oh, interesting. I have the other way around. I have one that is and two that aren't. So, 9 00:00:52,160 --> 00:00:55,840 between us, we have a full set of 5.9 only packages. 10 00:00:55,840 --> 00:00:58,080 - Yeah, I mean, there's lots of interesting stuff 11 00:00:58,080 --> 00:01:02,020 coming in, right, on 5.9, lots of macro-related packages. 12 00:01:02,020 --> 00:01:03,400 - Lots of macros, yeah. 13 00:01:03,400 --> 00:01:06,840 I think it proves that we did the right thing 14 00:01:06,840 --> 00:01:12,120 getting 5.9 into our compatibility testing 15 00:01:12,120 --> 00:01:13,680 as quickly as we could. 16 00:01:13,680 --> 00:01:16,640 - Yeah, yeah, I am a bit bummed out 17 00:01:16,640 --> 00:01:19,720 that we can't support or don't support 18 00:01:19,720 --> 00:01:21,380 the product filter yet. 19 00:01:21,380 --> 00:01:25,320 I mean, we might talk about that at least briefly now 20 00:01:25,320 --> 00:01:35,000 and as part of the news, right, the plan was to support the product colon macro clause as a filter. 21 00:01:35,000 --> 00:01:43,640 But we can't yet. And the reason is that products aren't declared in the, macros aren't declared in 22 00:01:43,640 --> 00:01:51,160 the Swift package manifest as products. They are targets. And then they get added to a library and 23 00:01:51,160 --> 00:01:56,600 the libraries, the products. So we have no way of distinguishing them at that level to support 24 00:01:56,600 --> 00:02:00,120 our filters because our filters really look at the products that are declared in a package. 25 00:02:00,120 --> 00:02:08,600 We have some thoughts around how to fix that. Unfortunately, the straightforward way of doing 26 00:02:08,600 --> 00:02:14,680 that and supporting that is not possible right now. So bear with us. I've seen that some packages 27 00:02:14,680 --> 00:02:20,120 actually have macro in their keywords. So if you search for macro, you still get them, you get a 28 00:02:20,120 --> 00:02:24,840 a decent list, but it's obviously, you know, there are some, I guess there's a package 29 00:02:24,840 --> 00:02:29,580 called macro that'll end up in there that has nothing to do with macros themselves. 30 00:02:29,580 --> 00:02:35,340 So this is not as strong a filter and we hope we'll be able to improve it, but some authors 31 00:02:35,340 --> 00:02:41,040 have worked towards being discoverable in that way. So that's actually nice. 32 00:02:41,040 --> 00:02:46,160 It's also probably worth just mentioning how people can add keywords to their packages 33 00:02:46,160 --> 00:02:49,440 is because it's a slightly opaque process 34 00:02:49,440 --> 00:02:54,440 of we pick up keywords out of GitHub keywords. 35 00:02:54,440 --> 00:02:58,360 So if you would like to add the macro keyword 36 00:02:58,360 --> 00:03:01,640 to your Swift package, you need to go to GitHub, 37 00:03:01,640 --> 00:03:03,360 add the keyword there, 38 00:03:03,360 --> 00:03:06,200 and then we'll pick that up within a few hours. 39 00:03:06,200 --> 00:03:08,420 And then once you do a search 40 00:03:08,420 --> 00:03:10,360 on the right-hand side of the search results, 41 00:03:10,360 --> 00:03:13,200 you can filter on keywords. 42 00:03:13,200 --> 00:03:15,320 And if you then hit the macro keyword, 43 00:03:15,320 --> 00:03:18,840 then you'll get everything that's tagged with a macro. 44 00:03:18,840 --> 00:03:20,640 But I've been working the last couple of weeks 45 00:03:20,640 --> 00:03:23,160 on something that has absolutely nothing to do 46 00:03:23,160 --> 00:03:24,720 with Swift 5.9. 47 00:03:24,720 --> 00:03:28,640 And it's actually something we've talked about before. 48 00:03:28,640 --> 00:03:32,160 And I'm not gonna go into a huge amount of detail 49 00:03:32,160 --> 00:03:36,040 because much of it is not particularly interesting, 50 00:03:36,040 --> 00:03:37,280 but there are a couple of things 51 00:03:37,280 --> 00:03:39,020 that I think are worth mentioning. 52 00:03:39,020 --> 00:03:44,020 So just to clarify what the feature is, first of all, 53 00:03:44,400 --> 00:03:48,620 I've been working on sorting out 54 00:03:48,620 --> 00:03:52,660 our Google indexing problems. 55 00:03:52,660 --> 00:03:57,540 So Google has, Google loves our package pages. 56 00:03:57,540 --> 00:04:01,020 It sends a lot of people towards our package pages. 57 00:04:01,020 --> 00:04:04,900 And I think it understands that bit of the site really well. 58 00:04:04,900 --> 00:04:08,900 And then as we put documentation hosting onto the site, 59 00:04:08,900 --> 00:04:12,100 Google loves us less for the documentation hosting. 60 00:04:12,100 --> 00:04:14,540 And there were a couple of problems. 61 00:04:14,540 --> 00:04:18,780 The first problem was we were hosting multiple versions 62 00:04:18,780 --> 00:04:21,960 of each package's documentation. 63 00:04:21,960 --> 00:04:25,340 And some of those package documentations are identical 64 00:04:25,340 --> 00:04:28,420 because even though the package has had a new release, 65 00:04:28,420 --> 00:04:30,860 the documentation may not have changed. 66 00:04:30,860 --> 00:04:34,260 It may have changed, but it also may not have changed. 67 00:04:34,260 --> 00:04:39,260 And so Google really hates duplicate content in the index. 68 00:04:41,880 --> 00:04:43,480 And so what it saw is it saw, 69 00:04:43,480 --> 00:04:45,680 okay, here's one set of documentation 70 00:04:45,680 --> 00:04:47,480 and here's another set of documentation. 71 00:04:47,480 --> 00:04:50,080 And I don't think there's any differences between the two. 72 00:04:50,080 --> 00:04:53,320 And it actually started to punish us for that 73 00:04:53,320 --> 00:04:56,880 by removing some of those pages from its index, 74 00:04:56,880 --> 00:04:57,720 which is what it'll do 75 00:04:57,720 --> 00:04:59,000 if it thinks you're trying to game it, 76 00:04:59,000 --> 00:05:02,080 which our intentions were true, 77 00:05:02,080 --> 00:05:04,920 but our actions made it look like we were trying to game it. 78 00:05:04,920 --> 00:05:06,320 (laughs) 79 00:05:06,320 --> 00:05:08,240 So obviously we want to have 80 00:05:08,240 --> 00:05:09,800 multiple versions of documentation. 81 00:05:09,800 --> 00:05:12,640 That's part of the feature that we built. 82 00:05:12,640 --> 00:05:15,160 We want people to be able to go back 83 00:05:15,160 --> 00:05:16,820 to previous major versions. 84 00:05:16,820 --> 00:05:20,440 We want you to be able to see the difference 85 00:05:20,440 --> 00:05:23,100 between the documentation on the default branch 86 00:05:23,100 --> 00:05:26,200 and like the latest stable release and that kind of thing. 87 00:05:26,200 --> 00:05:30,680 But so the first thing we had to do was let Google know 88 00:05:30,680 --> 00:05:35,000 which version of each package's documentation is canonical. 89 00:05:35,000 --> 00:05:37,800 And so every page in the documentation, 90 00:05:37,800 --> 00:05:42,520 In fact, most pages on the site now have a meta tag 91 00:05:42,520 --> 00:05:47,080 inside the HTML that says, if you fetch this page 92 00:05:47,080 --> 00:05:49,200 and it's not the canonical version, 93 00:05:49,200 --> 00:05:51,820 here is a pointer to the canonical version. 94 00:05:51,820 --> 00:05:55,460 So all of our documentation pages now link 95 00:05:55,460 --> 00:05:58,800 their canonical page as the latest 96 00:05:58,800 --> 00:06:01,620 stable releases documentation. 97 00:06:01,620 --> 00:06:03,320 So that was step one. 98 00:06:03,320 --> 00:06:08,320 And the second step is then to start to tell Google 99 00:06:08,320 --> 00:06:10,840 about all the different pages we have 100 00:06:10,840 --> 00:06:14,320 on the documentation site. 101 00:06:14,320 --> 00:06:17,600 And that is actually what I want to talk 102 00:06:17,600 --> 00:06:21,200 a little bit more about and in more detail about, 103 00:06:21,200 --> 00:06:23,240 because that's where it gets more interesting 104 00:06:23,240 --> 00:06:25,800 that for people who are not running a package index, 105 00:06:25,800 --> 00:06:30,880 which the first one is like very much a specific problem 106 00:06:30,880 --> 00:06:33,280 that we just had, we've tried to fix it. 107 00:06:33,280 --> 00:06:35,080 hopefully, you know, these things, 108 00:06:35,080 --> 00:06:38,540 it'll take Google time to trust the site again. 109 00:06:38,540 --> 00:06:41,440 And it's, we're already seeing some results, which is good. 110 00:06:41,440 --> 00:06:44,600 Pages are going back into the index, 111 00:06:44,600 --> 00:06:46,640 but it's a slow process. 112 00:06:46,640 --> 00:06:49,940 So before we move on to going into detail 113 00:06:49,940 --> 00:06:52,700 about how we're gonna tell Google 114 00:06:52,700 --> 00:06:54,320 about all these documentations, 115 00:06:54,320 --> 00:06:58,200 I do just want to mention that we had some contributions 116 00:06:58,200 --> 00:07:02,880 on solving this canonical URL problem from Toby Herbert, 117 00:07:02,880 --> 00:07:07,880 who noticed several issues with our canonical URLs, 118 00:07:07,880 --> 00:07:12,020 mainly to do with kind of casing, 119 00:07:12,020 --> 00:07:14,120 letter casing in some of the URLs, 120 00:07:14,120 --> 00:07:18,400 because we honor the case from GitHub of like, 121 00:07:18,400 --> 00:07:21,440 if you have your owner name and your repository name 122 00:07:21,440 --> 00:07:23,160 with a specific case, we honor that. 123 00:07:23,160 --> 00:07:26,160 And our canonicals, we're not honoring that correctly. 124 00:07:26,160 --> 00:07:30,440 So in addition to some of the work that I did on that, 125 00:07:30,440 --> 00:07:33,600 others like to thank Toby for all of his work on that. 126 00:07:33,600 --> 00:07:35,220 That was incredibly helpful. 127 00:07:35,220 --> 00:07:38,480 Most helpful actually was spotting the errors, 128 00:07:38,480 --> 00:07:43,120 which is always difficult. 129 00:07:43,120 --> 00:07:45,920 So yeah, the bit that I actually wanted to talk about 130 00:07:45,920 --> 00:07:49,920 in a bit more detail is how we tell Google 131 00:07:49,920 --> 00:07:52,800 or any search engine about all the pages 132 00:07:52,800 --> 00:07:56,320 that we have hosted on our documentation site. 133 00:07:56,320 --> 00:08:00,040 And we use a feature, it's actually an undocumented feature 134 00:08:00,040 --> 00:08:02,280 of DocC for this. 135 00:08:02,280 --> 00:08:04,740 And what I'll do is I'll link an article 136 00:08:04,740 --> 00:08:08,960 in the show notes from Joe Heck, 137 00:08:08,960 --> 00:08:13,960 who documented or wrote up a potential use for this flag 138 00:08:13,960 --> 00:08:18,440 and also how to find and add this flag 139 00:08:18,440 --> 00:08:20,800 to your documentation processing. 140 00:08:20,800 --> 00:08:23,320 So the flag is emit digest. 141 00:08:23,320 --> 00:08:25,660 And if you add that flag onto the end 142 00:08:25,660 --> 00:08:28,140 of your documentation generation command, 143 00:08:28,140 --> 00:08:32,920 you will get a few extra JSON files in the output. 144 00:08:32,920 --> 00:08:35,900 And one of those files is called linkable entities. 145 00:08:35,900 --> 00:08:39,780 And it's a collection of effectively 146 00:08:39,780 --> 00:08:43,460 every individual piece of documentation 147 00:08:43,460 --> 00:08:47,540 in the built documentation that you've just generated. 148 00:08:47,540 --> 00:08:50,380 And so what we're doing is we're using that file 149 00:08:50,380 --> 00:08:53,220 to pull out all of the paths 150 00:08:53,220 --> 00:08:56,500 to every single documentation page 151 00:08:56,500 --> 00:08:59,160 in a packages documentation. 152 00:08:59,160 --> 00:09:03,580 And then we are creating a sitemap 153 00:09:03,580 --> 00:09:06,280 out of that set of URLs. 154 00:09:06,280 --> 00:09:07,700 So we're effectively saying, 155 00:09:07,700 --> 00:09:11,060 give me all of the URLs in this documentation. 156 00:09:11,060 --> 00:09:14,140 And then we'll make a sitemap that will tell Google, 157 00:09:14,140 --> 00:09:16,500 look at all these different pages that we have 158 00:09:16,500 --> 00:09:21,500 underneath this packages documentation URL. 159 00:09:21,500 --> 00:09:24,340 And if Google then goes and fetches those, 160 00:09:24,340 --> 00:09:27,000 it will get correct canonicals for all of those. 161 00:09:27,000 --> 00:09:31,880 So we're hoping that the combination of those two things 162 00:09:31,880 --> 00:09:35,340 is gonna be a good fix to the Google problem. 163 00:09:35,340 --> 00:09:38,920 But the reason I wanted to mention this flag 164 00:09:38,920 --> 00:09:42,320 is that it is something that you may want to run yourself. 165 00:09:42,320 --> 00:09:46,240 So if you are creating Doxy documentation, 166 00:09:46,240 --> 00:09:51,840 you might want to extract or generate this file 167 00:09:51,840 --> 00:09:54,360 as part of your documentation build 168 00:09:54,360 --> 00:09:57,680 so that you can have a sense of all of the different paths 169 00:09:57,680 --> 00:09:59,320 in your documentation 170 00:09:59,320 --> 00:10:03,320 so that you might create a manual curation 171 00:10:03,320 --> 00:10:06,680 of here are the most interesting bits of this documentation 172 00:10:06,680 --> 00:10:10,800 or maybe the order in which the documentation gets presented. 173 00:10:10,800 --> 00:10:14,720 And again, Joe, in that article 174 00:10:14,720 --> 00:10:15,880 that we're gonna link in the show notes, 175 00:10:15,880 --> 00:10:20,240 he has a good bits of advice on how you can do that 176 00:10:20,240 --> 00:10:22,560 in the real world. 177 00:10:22,560 --> 00:10:26,080 - Right, and that's actually a massive amount of links, 178 00:10:26,080 --> 00:10:26,920 isn't it? 179 00:10:26,920 --> 00:10:29,720 The site map and the total number of pages 180 00:10:29,720 --> 00:10:31,960 that we're effectively, or have been serving, 181 00:10:31,960 --> 00:10:34,480 we just never really realized how many it is. 182 00:10:34,480 --> 00:10:36,460 You had a figure, didn't you? 183 00:10:36,460 --> 00:10:37,800 - We do have a figure, yeah. 184 00:10:37,800 --> 00:10:42,040 When Google ingested all of these site maps, 185 00:10:42,040 --> 00:10:45,340 it now tells you how many URLs it found, 186 00:10:45,340 --> 00:10:47,360 not only in the kind of master site map, 187 00:10:47,360 --> 00:10:50,480 but also in all of the different site maps that it found. 188 00:10:50,480 --> 00:10:55,480 And it found over 250,000 URLs in the swiftpackageindex.com, 189 00:10:55,480 --> 00:11:00,480 which is way more than I thought we served. 190 00:11:00,480 --> 00:11:02,980 - Yeah, well, we've got 6,000 packages, 191 00:11:02,980 --> 00:11:07,800 but the documentation obviously dwarfs everything, right? 192 00:11:07,800 --> 00:11:09,600 That's just lots of symbols. 193 00:11:09,600 --> 00:11:11,600 - It does, and I think there's actually something 194 00:11:11,600 --> 00:11:14,480 that's kind of interesting in that as well in that. 195 00:11:14,480 --> 00:11:16,960 So, it's actually, in fact, it's one of us, 196 00:11:16,960 --> 00:11:26,080 supporters stream the company who kindly helps to sponsor the site. They have a package which, 197 00:11:26,080 --> 00:11:34,240 on its own, has 50,000 or 48,000 URLs in their documentation. 198 00:11:34,240 --> 00:11:34,880 Mason: Wow. 199 00:11:34,880 --> 00:11:43,120 Hartmanis: And yes. So first of all, congratulations on being the biggest 200 00:11:43,120 --> 00:11:50,640 documentation site by an order of magnitude on the Swift package index. That in itself is remarkable. 201 00:11:50,640 --> 00:11:58,800 I think one of the things that potentially needs looking at in terms of Doxy in general 202 00:11:58,800 --> 00:12:04,560 is how many pages it creates, because I can assure you there are not 48,000 203 00:12:04,560 --> 00:12:12,240 useful documentation pages in that package's documentation. The vast majority of those are 204 00:12:12,240 --> 00:12:15,760 are contain almost no more information 205 00:12:15,760 --> 00:12:16,720 than you could get from just looking 206 00:12:16,720 --> 00:12:18,100 at the function signature. 207 00:12:18,100 --> 00:12:21,200 And in fact, a lot of them are because they're inherited 208 00:12:21,200 --> 00:12:23,000 from like Vue or something like that, 209 00:12:23,000 --> 00:12:25,400 they pick up a whole load of documentation pages 210 00:12:25,400 --> 00:12:27,920 for that as well. 211 00:12:27,920 --> 00:12:28,960 And I think- 212 00:12:28,960 --> 00:12:30,120 - Right, right. 213 00:12:30,120 --> 00:12:32,640 - That's potentially something that, you know, 214 00:12:32,640 --> 00:12:34,040 it's a difficult problem to solve. 215 00:12:34,040 --> 00:12:36,960 Like, do you just not generate pages 216 00:12:36,960 --> 00:12:40,160 for if they don't have like proper document, 217 00:12:40,160 --> 00:12:42,960 Like what even is proper documentation, right? 218 00:12:42,960 --> 00:12:45,080 It's a difficult problem for DocC to solve. 219 00:12:45,080 --> 00:12:48,760 But I think that potentially there is 220 00:12:48,760 --> 00:12:52,600 an interesting discussion to be had around 221 00:12:52,600 --> 00:12:54,660 what that balance is. 222 00:12:54,660 --> 00:12:57,640 And certainly I don't think 50,000 URLs 223 00:12:57,640 --> 00:12:59,500 is the right balance. 224 00:12:59,500 --> 00:13:04,760 It certainly seems like the wrong side of useful. 225 00:13:04,760 --> 00:13:06,400 Now there's the other side of that, 226 00:13:06,400 --> 00:13:14,020 which is who should care whether we host 50,000 documentation URLs for one package? As long 227 00:13:14,020 --> 00:13:19,480 as you can find the bit of documentation that actually solves your problem, it doesn't matter 228 00:13:19,480 --> 00:13:27,040 that there's a whole load of unused documentation pages. So there's no kind of clear cut, like 229 00:13:27,040 --> 00:13:32,280 there's a clear solution to this problem. But it is something that I would really enjoy 230 00:13:32,280 --> 00:13:34,360 talking to the Doxy team about actually. 231 00:13:34,360 --> 00:13:40,040 Well, it does matter a bit, right, because we are running up to certain limits in sitemap 232 00:13:40,040 --> 00:13:42,040 files, aren't we? 233 00:13:42,040 --> 00:13:43,040 That's true. 234 00:13:43,040 --> 00:13:44,040 Yeah. 235 00:13:44,040 --> 00:13:49,200 So we do need to think about chunking stuff and it sort of gets a bit more complicated 236 00:13:49,200 --> 00:13:55,020 downstream or, you know, at our end and putting it all together because, you know, it's not 237 00:13:55,020 --> 00:13:56,120 just a single package. 238 00:13:56,120 --> 00:14:00,800 It's like we have, I believe, 400 documented packages now. 239 00:14:00,800 --> 00:14:03,880 And obviously, you know, that they all come together in the sitemap. 240 00:14:03,880 --> 00:14:07,600 Now we can treat them individually as package pages, 241 00:14:07,600 --> 00:14:10,260 but this is a place where they all come together 242 00:14:10,260 --> 00:14:13,680 and we need to funnel them through one site map. 243 00:14:13,680 --> 00:14:15,940 And that creates certain challenges, 244 00:14:15,940 --> 00:14:17,360 just like it created challenges 245 00:14:17,360 --> 00:14:21,140 with the size of the doc sets early on 246 00:14:21,140 --> 00:14:22,560 that we needed to solve. 247 00:14:22,560 --> 00:14:26,540 - So the limit that Sven is talking about there 248 00:14:26,540 --> 00:14:31,540 is that site maps themselves have a 50,000 URL limit. 249 00:14:33,160 --> 00:14:35,240 So if you have one sitemap, 250 00:14:35,240 --> 00:14:38,460 and we are now doing one sitemap per package, 251 00:14:38,460 --> 00:14:42,820 if you hit that 50,000 URL limit, then Google, 252 00:14:42,820 --> 00:14:44,880 actually, I'm not quite sure what it does. 253 00:14:44,880 --> 00:14:46,840 Does it just stop reading at 50,000, 254 00:14:46,840 --> 00:14:49,380 or does it invalidate the entire file? 255 00:14:49,380 --> 00:14:52,040 That's a good question that I don't know the answer to. 256 00:14:52,040 --> 00:14:58,040 But what we should probably do there, 257 00:14:58,040 --> 00:15:00,180 and you know, Srinivas talked about this the other day, 258 00:15:00,180 --> 00:15:03,220 but since then I've thought about it a little bit more. 259 00:15:03,220 --> 00:15:04,780 I think that we should potentially, 260 00:15:04,780 --> 00:15:07,940 rather than go into the rather complex solution 261 00:15:07,940 --> 00:15:10,700 of having multiple sitemaps for a single package, 262 00:15:10,700 --> 00:15:12,960 which we're not actually quite there yet 263 00:15:12,960 --> 00:15:14,500 because the biggest package we have 264 00:15:14,500 --> 00:15:19,020 does only have 48,000 URLs in it. 265 00:15:19,020 --> 00:15:24,020 But I wonder if we just clip the sitemap at 50,000 266 00:15:24,020 --> 00:15:29,020 because a sitemap is a guide to Google 267 00:15:29,020 --> 00:15:35,900 to Google and what it you can tell Google about all your pages with a 268 00:15:35,900 --> 00:15:41,860 sitemap but from each of those pages it should go and crawl from there so it's 269 00:15:41,860 --> 00:15:45,020 not like if those pages are not in the sitemap they'll never get crawled 270 00:15:45,020 --> 00:15:48,280 they're less likely to get crawled and less likely to get crawled more often 271 00:15:48,280 --> 00:15:53,800 but if we're at 50,000 per package I think we may we may cut our losses at 272 00:15:53,800 --> 00:15:57,380 that point. Well it would be nice if there was a way of ordering them right I 273 00:15:57,380 --> 00:16:01,460 I mean, if Doc C had a means of putting the ones at front 274 00:16:01,460 --> 00:16:04,300 at the front that actually have, you know 275 00:16:04,300 --> 00:16:07,840 user contributed documentation, because I suspect lots 276 00:16:07,840 --> 00:16:11,660 of them just have the default pages perhaps, right? 277 00:16:11,660 --> 00:16:14,700 Because no one has documented 50,000 symbols. 278 00:16:14,700 --> 00:16:17,800 So if there was a way to put that to the top 279 00:16:17,800 --> 00:16:20,060 then that would solve the problem really. 280 00:16:20,060 --> 00:16:20,900 - It really would. 281 00:16:20,900 --> 00:16:23,900 And at that point we could potentially even say, 282 00:16:23,900 --> 00:16:26,840 well, actually the maximum that we'll have is 283 00:16:26,840 --> 00:16:28,560 let's say 10,000 or something like that. 284 00:16:28,560 --> 00:16:32,940 But there are lots of different ways to solve this problem, 285 00:16:32,940 --> 00:16:35,160 but I thought it was an interesting point of discussion, 286 00:16:35,160 --> 00:16:36,600 first of all. 287 00:16:36,600 --> 00:16:38,120 And secondly, that people may not know 288 00:16:38,120 --> 00:16:40,440 about this emit digest flag at all, 289 00:16:40,440 --> 00:16:42,920 because it is an undocumented flag. 290 00:16:42,920 --> 00:16:43,760 - Yeah. 291 00:16:43,760 --> 00:16:45,920 Nice. 292 00:16:45,920 --> 00:16:50,160 Well, the other thing we can briefly talk about, I suppose, 293 00:16:50,160 --> 00:16:53,280 is the big thing that happened last week, right? 294 00:16:54,440 --> 00:16:58,760 VisionOS was released, like the SDK was released. 295 00:16:58,760 --> 00:17:01,960 And that happened a bit sooner than I thought. 296 00:17:01,960 --> 00:17:04,800 - Are you saying that the release of VisionOS 297 00:17:04,800 --> 00:17:06,640 is more important than my site map? 298 00:17:06,640 --> 00:17:09,640 (both laughing) 299 00:17:09,640 --> 00:17:14,360 - Well, you know, it's funny, I'm interested in this, 300 00:17:14,360 --> 00:17:18,120 but I haven't actually watched a single WWDC session 301 00:17:18,120 --> 00:17:20,440 about VisionOS. 302 00:17:20,440 --> 00:17:24,400 I've been more interested in some of the 5.9, 303 00:17:24,400 --> 00:17:26,600 macro stuff, tooling. 304 00:17:26,600 --> 00:17:28,440 And I, I thought about this. 305 00:17:28,440 --> 00:17:34,380 I've early on when iOS, you know, the SDK came out, I dabbled a bit with it, but 306 00:17:34,380 --> 00:17:38,560 I've always been, I've always been interested in writing apps and creating 307 00:17:38,560 --> 00:17:38,760 that. 308 00:17:38,760 --> 00:17:44,120 And I've done a bit of that, but I always ended up drifting towards tooling. 309 00:17:44,120 --> 00:17:49,440 And I think, I think this time around, I've, I've sort of, I'm leaning in because 310 00:17:49,440 --> 00:17:53,320 it seems like, you know, it's the gold rush again, or I suspect it will be to a 311 00:17:53,320 --> 00:18:06,320 When this becomes really mainstream, I mean, the $3,500 device won't be the thing that starts this, you know, bringing AR apps into the mainstream, but the subsequent devices will. 312 00:18:06,320 --> 00:18:13,320 So at some point, I suspect we'll have another gold rush where people come up with cool app ideas and put them out. 313 00:18:13,320 --> 00:18:21,320 But I feel like I'm going to be the one that sells the shovels, not the one that's going after the nuggets. 314 00:18:21,320 --> 00:18:23,740 (laughing) 315 00:18:23,740 --> 00:18:26,100 And I think with the index, we're in a good position 316 00:18:26,100 --> 00:18:29,480 and we actually have started shoveling a bit, right? 317 00:18:29,480 --> 00:18:34,480 We have rushed to start supporting VisionOS 318 00:18:34,480 --> 00:18:38,360 on top of the 5.9 that we've just added. 319 00:18:38,360 --> 00:18:41,360 I mean, we weren't completely caught by surprise, 320 00:18:41,360 --> 00:18:43,100 but it came earlier than I thought. 321 00:18:43,100 --> 00:18:44,960 I thought when they said later this month, 322 00:18:44,960 --> 00:18:47,900 I really thought, well, it's going to be this week 323 00:18:47,900 --> 00:18:49,080 that it's going to drop. 324 00:18:50,060 --> 00:18:53,840 but it happened just one week after WWDC. 325 00:18:53,840 --> 00:18:57,400 So yeah, do you have any plans? 326 00:18:57,400 --> 00:19:01,260 Are you curious about VisionOS and building apps? 327 00:19:01,260 --> 00:19:04,780 - Yeah, I'm tremendously excited about the platform. 328 00:19:04,780 --> 00:19:09,740 I think it's the kind of thing that watching people explore, 329 00:19:09,740 --> 00:19:11,680 I also haven't actually written a line 330 00:19:11,680 --> 00:19:13,840 of VisionOS code yet, 331 00:19:13,840 --> 00:19:16,660 but watching people experiment and bring their apps 332 00:19:16,660 --> 00:19:19,220 into the environment and kind of start to build them 333 00:19:19,220 --> 00:19:24,220 with that SDK, but actually just thinking more about 334 00:19:24,220 --> 00:19:28,260 now that we have a road that we're kind of, 335 00:19:28,260 --> 00:19:31,420 we've got a wheel on the road 336 00:19:31,420 --> 00:19:35,380 towards what AR could potentially become one day. 337 00:19:35,380 --> 00:19:37,340 And I am quite excited about what AR 338 00:19:37,340 --> 00:19:39,020 could potentially become one day, 339 00:19:39,020 --> 00:19:40,940 and this is the start of that path. 340 00:19:40,940 --> 00:19:43,660 And so while I haven't written anything yet 341 00:19:43,660 --> 00:19:48,020 and I don't have any plans for a VisionOS app, 342 00:19:49,060 --> 00:19:51,100 I am quite excited about it. 343 00:19:51,100 --> 00:19:52,720 - Yeah, well, it's certainly, I mean, 344 00:19:52,720 --> 00:19:54,180 the samples look nice. 345 00:19:54,180 --> 00:19:59,180 I think I came out of WWC a bit unconvinced 346 00:19:59,180 --> 00:20:02,400 regarding the use cases. 347 00:20:02,400 --> 00:20:05,140 I mean, we had the discussion beforehand 348 00:20:05,140 --> 00:20:08,040 and I recall saying, I'm really curious 349 00:20:08,040 --> 00:20:11,620 what Apple are going to present as the use cases. 350 00:20:11,620 --> 00:20:16,340 And I don't think that has truly happened yet, perhaps. 351 00:20:16,340 --> 00:20:17,180 Who knows? 352 00:20:17,180 --> 00:20:18,660 I mean, there's still time. 353 00:20:18,660 --> 00:20:23,820 There's certainly going to be a, another sort of introduction once it actually 354 00:20:23,820 --> 00:20:24,320 ships. 355 00:20:24,320 --> 00:20:25,740 So maybe that will change. 356 00:20:25,740 --> 00:20:34,620 But, um, I, I haven't seen any super, super obvious app, you know, that, that 357 00:20:34,620 --> 00:20:40,340 would make you jump up and say, right, this, I need this, this, this is a thing 358 00:20:40,340 --> 00:20:43,820 that's, that's totally different from, from all other apps. 359 00:20:43,820 --> 00:20:45,380 Have you seen anything like that? 360 00:20:45,380 --> 00:20:46,860 Is there anything convincing? 361 00:20:47,020 --> 00:20:52,020 I think the convincing bit is actually the fact 362 00:20:52,020 --> 00:20:58,220 that it is going to run what are quite standard apps 363 00:20:58,220 --> 00:21:00,700 that you might see on your iPad or your iPhone 364 00:21:00,700 --> 00:21:01,820 or something like that. 365 00:21:01,820 --> 00:21:03,780 And I think that the, 366 00:21:03,780 --> 00:21:06,140 I think there's two exciting things going on here. 367 00:21:06,140 --> 00:21:09,180 We're on a path to a potential very exciting, 368 00:21:09,180 --> 00:21:12,720 very futuristic AR type device. 369 00:21:12,720 --> 00:21:14,860 But I think that's a long way away still. 370 00:21:14,860 --> 00:21:18,100 And then you have this potential device that could, 371 00:21:18,100 --> 00:21:23,100 I think, be used quite effectively in a work context. 372 00:21:23,100 --> 00:21:28,580 And I think having apps around you and having, 373 00:21:28,580 --> 00:21:32,780 I think the concept of kind of screens is interesting 374 00:21:32,780 --> 00:21:35,600 and having apps separated from screens is interesting. 375 00:21:35,600 --> 00:21:38,880 And I don't think there's any specific app 376 00:21:38,880 --> 00:21:39,900 that I'm excited about, 377 00:21:39,900 --> 00:21:43,860 but I'm excited about seeing what that work environment 378 00:21:43,860 --> 00:21:52,500 maybe looks like. Yeah. Yeah. I mean, I think it's, it's easier to see the useful AR app 379 00:21:52,500 --> 00:21:59,520 that'll completely change how you do things once the device is like actual glasses. Right. 380 00:21:59,520 --> 00:22:06,760 I mean, I think that's, for me, at least it's, it's hampered by, you know, I wouldn't, I 381 00:22:06,760 --> 00:22:10,680 wouldn't walk around with that thing. I mean, even if I had one, right. You're not, you're 382 00:22:10,680 --> 00:22:16,000 not... Nor should you and nor do Apple want you to. Yeah, exactly. But I think they don't 383 00:22:16,000 --> 00:22:21,560 want you to because right now it's not that kind of device, right? I think if they were 384 00:22:21,560 --> 00:22:27,700 able to ship like real literal glasses, that would change the story of that thing. Which 385 00:22:27,700 --> 00:22:34,680 is, I think we're sort of seeing right now the prototype version of obviously way more 386 00:22:34,680 --> 00:22:40,580 polished than a prototype that Apple typically don't ship, right? This is like the breakout 387 00:22:40,580 --> 00:22:46,980 iPhone on a board with a screen and all the parts spread out a bit and a lot bigger than 388 00:22:46,980 --> 00:22:55,180 it was in its final first 1.0 shipping shape. It almost feels like it's a change in that 389 00:22:55,180 --> 00:23:00,940 they actually released this now to give everyone a glimpse of what's to come way earlier. 390 00:23:00,940 --> 00:23:07,860 Yes. And I think I wrote a little bit about this in Friday's iOS Dev Weekly, but one of 391 00:23:07,860 --> 00:23:13,300 things that I was convinced was just a, you know, it was a feature that was being lined 392 00:23:13,300 --> 00:23:20,780 up for whatever AR device that they released was last year in iOS 16 they added an AR feature 393 00:23:20,780 --> 00:23:28,580 for accessibility where if you were holding your phone up and approaching a door, it detected 394 00:23:28,580 --> 00:23:32,340 the door and it warned you about the door and it told you the information about the 395 00:23:32,340 --> 00:23:36,940 door whether it was push or pull or that kind of thing and that was such a 396 00:23:36,940 --> 00:23:44,840 clear feature for a headset of some sort. Like nobody holds their phone up in 397 00:23:44,840 --> 00:23:48,820 front of them while they're walking around. It's not practical to 398 00:23:48,820 --> 00:23:53,260 really do that and so it felt like this is so clearly a feature 399 00:23:53,260 --> 00:23:56,760 for a headset and yet of course the headset doesn't do that and the reason 400 00:23:56,760 --> 00:24:00,260 is you shouldn't be walking around with this headset any more than you 401 00:24:00,260 --> 00:24:02,220 you should be walking around with your phone in front of you. 402 00:24:02,220 --> 00:24:04,660 - Yeah, it's not that kind of headset yet, right? 403 00:24:04,660 --> 00:24:07,780 That changes the whole pitch, yeah. 404 00:24:07,780 --> 00:24:10,380 - Yeah, I'm confident that we'll see that feature 405 00:24:10,380 --> 00:24:13,780 at some point in a device that you are intended 406 00:24:13,780 --> 00:24:15,220 to walk around outside with. 407 00:24:15,220 --> 00:24:17,140 - Yeah, yeah, absolutely. 408 00:24:17,140 --> 00:24:20,660 Right, maybe to just bring this briefly back 409 00:24:20,660 --> 00:24:23,060 to what we're doing. 410 00:24:23,060 --> 00:24:26,740 So, platform, VisionOS platform compatibility testing 411 00:24:26,740 --> 00:24:28,900 is coming, it's coming along. 412 00:24:28,900 --> 00:24:32,600 In fact, the builder tests have just all passed. 413 00:24:32,600 --> 00:24:35,980 So there aren't any, we're all set up. 414 00:24:35,980 --> 00:24:38,660 We just have to just, 415 00:24:38,660 --> 00:24:41,340 we just need to do a little more typing 416 00:24:41,340 --> 00:24:42,500 and then we're done. 417 00:24:42,500 --> 00:24:43,540 - It's not just typing. 418 00:24:43,540 --> 00:24:44,980 - Yeah. 419 00:24:44,980 --> 00:24:47,500 There have been some difficulties adjusting our test suite 420 00:24:47,500 --> 00:24:50,940 because we're once again in a state where 421 00:24:50,940 --> 00:24:53,500 there is no single macOS version 422 00:24:53,500 --> 00:24:56,020 on which you can run all of the Swift versions 423 00:24:56,020 --> 00:25:04,660 we support which is the four latest point releases so 6, 7, 8 and 5.9. And this is just my eternal 424 00:25:04,660 --> 00:25:10,740 wish that at some point we won't be forced to update the OS and Xcode versions and then have 425 00:25:10,740 --> 00:25:16,900 machines that can only run you know a small set of those four. I mean ideally would be even more 426 00:25:16,900 --> 00:25:25,940 than four. I just want this Linux docker thing where any Linux can run any Swift version in it. 427 00:25:25,940 --> 00:25:26,940 a Docker container. 428 00:25:26,940 --> 00:25:28,660 And you're not going to be happy on something else. 429 00:25:28,660 --> 00:25:30,220 Yes, oh god, I want this so much. 430 00:25:30,220 --> 00:25:31,220 I want this so much. 431 00:25:31,220 --> 00:25:36,780 I mean, I do think we need to consider virtualization at some point because it's getting really, 432 00:25:36,780 --> 00:25:42,940 really, it's tricky because it also impacts our regression test suite. 433 00:25:42,940 --> 00:25:50,380 It's really hard to keep testing package versions that used to fail on 5.5. 434 00:25:50,380 --> 00:25:55,340 I mean, we're not even testing for 5.5 anymore, so I've just moved them forward time and time 435 00:25:55,340 --> 00:26:01,900 again, to the oldest version that we support. But at some point you lose the capability to build 436 00:26:01,900 --> 00:26:06,940 those packages with the older Swift versions or the newer ones. And the test cases we were 437 00:26:06,940 --> 00:26:14,300 actually testing for aren't valid anymore. And it's really hard to keep that regression test in place 438 00:26:14,300 --> 00:26:20,140 in some shape or fashion. I mean, because there's still value in the test, it just happens that we 439 00:26:20,140 --> 00:26:24,940 don't have a package at the right version or Swift at the right version to still test that. So 440 00:26:24,940 --> 00:26:26,980 So that makes it quite difficult. 441 00:26:26,980 --> 00:26:31,980 And I wish that part of it was easier for our setup 442 00:26:31,980 --> 00:26:35,700 and not having to manage our machines like that 443 00:26:35,700 --> 00:26:38,180 and decide which one we're pulling forward. 444 00:26:38,180 --> 00:26:40,140 Then we lose capacity on other Swift versions 445 00:26:40,140 --> 00:26:43,580 because the latest one can only build 5.9 446 00:26:43,580 --> 00:26:44,420 - Yeah. 447 00:26:44,420 --> 00:26:45,740 - And so on and so on. 448 00:26:45,740 --> 00:26:48,180 And on Linux, we just never have to do anything. 449 00:26:48,180 --> 00:26:51,380 It just, any Swift version, we can just run. 450 00:26:51,380 --> 00:26:52,220 - Yeah. 451 00:26:52,220 --> 00:26:57,220 So we're currently split back across three distinct operating system versions. 452 00:26:57,220 --> 00:26:59,000 Again, we have, um, 453 00:26:59,000 --> 00:27:04,520 Monterey compiling five seven or anything with Xcode 13, 454 00:27:04,520 --> 00:27:07,600 um, Ventura compiling anything with Xcode 14, 455 00:27:07,600 --> 00:27:11,080 which is five seven and five eight maybe. 456 00:27:11,080 --> 00:27:13,920 And then we now have a Sonoma, uh, 457 00:27:13,920 --> 00:27:18,600 build machine that is now running, uh, beta two with the vision, OS SDK, 458 00:27:18,600 --> 00:27:21,760 which to bring us back to our original point, uh, 459 00:27:21,800 --> 00:27:28,720 we hope to ship soon. Yeah, I mean, by next time recording, we'll 460 00:27:28,720 --> 00:27:34,520 definitely have it. I think we'll have it next week, if not late this week. Depends 461 00:27:34,520 --> 00:27:39,800 a bit on when you would want to pull the trigger to actually deploy it, but it 462 00:27:39,800 --> 00:27:44,800 might happen tomorrow or the day after. So, and that will be 463 00:27:44,800 --> 00:27:49,840 very exciting because we'll then have compatibility status for all of our 464 00:27:49,840 --> 00:27:56,160 packages with with 5.9 and the VisionOS SDK. Yeah, yeah, first new platform 465 00:27:56,160 --> 00:28:01,140 since we added ARM testing, right, which was arguably, I mean it was a proper 466 00:28:01,140 --> 00:28:07,140 platform in our matrix at some point, so interesting times. So we've done 467 00:28:07,140 --> 00:28:11,760 quite a lot of talking about package index this week, so I think we should 468 00:28:11,760 --> 00:28:17,540 move swiftly on to to some package recommendations. Would you like to kick 469 00:28:17,540 --> 00:28:25,460 All right, I'll do that. The first package I have is called metacodable by Soumya Ranjan 470 00:28:25,460 --> 00:28:32,580 Mahunt, and I hope I pronounced that correctly. This is the first of two macro packages that 471 00:28:32,580 --> 00:28:41,340 I'm going to talk about, and it's a very nice package to tweak or empower codable performances. 472 00:28:41,340 --> 00:28:47,420 And the best way to describe this is, imagine you have a codable struct and you have a field 473 00:28:47,420 --> 00:28:53,060 And you've given it a nice name in Swift, but the codable, you know, the JSON 474 00:28:53,060 --> 00:28:58,020 file has a different name and you want to change the fields name, just that one 475 00:28:58,020 --> 00:29:02,360 fields name and imagine that struct has lots of fields, what you have to do is 476 00:29:02,360 --> 00:29:06,520 you have to spell out all the fields in the, I think it's called codable keys, 477 00:29:06,520 --> 00:29:11,120 to the protocol that you have to adopt, you know, to, to change or 478 00:29:11,120 --> 00:29:12,680 override the key definitions. 479 00:29:13,340 --> 00:29:20,140 And this package will give you an add-codable-path macro that you can tack on to your field just 480 00:29:20,140 --> 00:29:24,420 to rename a single field without having to spell everything else out, I suppose. 481 00:29:24,420 --> 00:29:27,620 Under the hood it just expands everything for you. 482 00:29:27,620 --> 00:29:30,580 That's just the perfect use case for a macro, right? 483 00:29:30,580 --> 00:29:33,000 Because that's a very tedious thing to do. 484 00:29:33,000 --> 00:29:35,340 It reads much nicer because there's no noise. 485 00:29:35,340 --> 00:29:39,220 It's really just about that one field that you're going to change. 486 00:29:39,220 --> 00:29:40,220 Really nice. 487 00:29:40,220 --> 00:29:42,920 It has a couple other tricks up its sleeves. 488 00:29:42,920 --> 00:29:45,040 It allows nested paths. 489 00:29:45,040 --> 00:29:51,440 So imagine you have a nested JSON struct and you want to pull out something that's like, 490 00:29:51,440 --> 00:29:58,840 you know, drill down a couple of objects into the JSON file and then pull it up to the outer 491 00:29:58,840 --> 00:30:02,520 layer, so to speak, and to assign it to a property there. 492 00:30:02,520 --> 00:30:04,120 It can do that. 493 00:30:04,120 --> 00:30:05,120 Also be the CodablePath. 494 00:30:05,120 --> 00:30:10,080 And there's a Codable Compose attribute, 495 00:30:10,080 --> 00:30:12,940 which is, it's difficult to describe. 496 00:30:12,940 --> 00:30:16,320 It allows you to layer or compose different Codable types 497 00:30:16,320 --> 00:30:18,180 into a common type. 498 00:30:18,180 --> 00:30:20,400 So you can do a little refactoring 499 00:30:20,400 --> 00:30:25,000 in case you're using object mapping onto JSON structs. 500 00:30:25,000 --> 00:30:27,600 It's best to look at the documentation, 501 00:30:27,600 --> 00:30:30,120 which is quite extensive, how that works. 502 00:30:30,120 --> 00:30:31,260 So it's a really nice package 503 00:30:31,260 --> 00:30:34,840 if you deal with these things in Codable, 504 00:30:34,840 --> 00:30:39,840 and it's called Metacodable by Soumya Aranjanmahunt. 505 00:30:39,840 --> 00:30:43,760 - Sounds like a package that's not so much revolutionary, 506 00:30:43,760 --> 00:30:45,080 but it's just gonna save you some time, right? 507 00:30:45,080 --> 00:30:46,260 - Exactly. 508 00:30:46,260 --> 00:30:51,260 - So my first pack of recommendation also includes a macro. 509 00:30:51,260 --> 00:30:54,580 It's both a very modern package 510 00:30:54,580 --> 00:30:57,240 in that it only works with Swift 5.9, 511 00:30:57,240 --> 00:31:02,020 but it's also a throwback to the Objective-C days, 512 00:31:02,960 --> 00:31:05,620 because it is a macro that wraps an Objective-C function, 513 00:31:05,620 --> 00:31:10,620 which is, I think, a nice little contrast between the two. 514 00:31:10,620 --> 00:31:14,340 It's called AssociatedObject, and it's by, 515 00:31:14,340 --> 00:31:16,420 I hope it's actually the second week in a row 516 00:31:16,420 --> 00:31:19,460 that we've had a package by p-x9. 517 00:31:19,460 --> 00:31:20,420 (laughing) 518 00:31:20,420 --> 00:31:25,420 So we're back with another p-x9 package. 519 00:31:25,420 --> 00:31:30,920 So AssociatedObject allows you to, 520 00:31:32,340 --> 00:31:37,340 in a Swift extension, declare an additional property, 521 00:31:37,340 --> 00:31:41,040 which is something that you can't currently do 522 00:31:41,040 --> 00:31:44,340 'cause you can't declare anything that includes storage 523 00:31:44,340 --> 00:31:45,560 and an extension. 524 00:31:45,560 --> 00:31:48,480 And the way that it works is that it uses 525 00:31:48,480 --> 00:31:52,400 the old Objective-C associated object API 526 00:31:52,400 --> 00:31:57,400 to store and retrieve values out of memory. 527 00:32:00,480 --> 00:32:02,940 And so then the implementation of it is really nice. 528 00:32:02,940 --> 00:32:06,060 As an annotation on a property that you're adding 529 00:32:06,060 --> 00:32:08,660 to whatever it is that you're extending, 530 00:32:08,660 --> 00:32:11,340 you just say @associated object, 531 00:32:11,340 --> 00:32:14,180 and you have to give it some memory management information 532 00:32:14,180 --> 00:32:15,540 about whether it should retain it, 533 00:32:15,540 --> 00:32:17,500 whether it's non-atomic, you know, 534 00:32:17,500 --> 00:32:19,860 real throwback to the old objective C days. 535 00:32:19,860 --> 00:32:24,120 But what it actually then does is it just lets you then, 536 00:32:24,120 --> 00:32:26,860 on the next line, create a variable, 537 00:32:26,860 --> 00:32:29,020 and that variable can have an initial value, 538 00:32:29,020 --> 00:32:32,460 and it can do all the things that you would expect it to do. 539 00:32:32,460 --> 00:32:35,780 And so it's, I don't know, 540 00:32:35,780 --> 00:32:40,100 I really liked the idea of this package. 541 00:32:40,100 --> 00:32:43,100 I'm not sure whether I'd put it into a project, 542 00:32:43,100 --> 00:32:46,840 but I've certainly used Objective-C associated objects 543 00:32:46,840 --> 00:32:49,100 many, many times, and they are very reliable. 544 00:32:49,100 --> 00:32:49,940 - Right. 545 00:32:49,940 --> 00:32:51,720 - So there's no reason you wouldn't, 546 00:32:51,720 --> 00:32:54,340 but it also feels like you're bending the language 547 00:32:54,340 --> 00:32:56,340 to something that it wasn't intended to do, 548 00:32:56,340 --> 00:32:59,060 which is always kind of, ah, should you do that? 549 00:32:59,060 --> 00:33:02,200 - Does it work on any type 550 00:33:02,200 --> 00:33:04,840 or would it have to be a class, the extension? 551 00:33:04,840 --> 00:33:06,240 - I think it has to be a class. 552 00:33:06,240 --> 00:33:07,180 - Has to be a class, right. 553 00:33:07,180 --> 00:33:09,300 Yeah, because it needs the Objective-C runtime 554 00:33:09,300 --> 00:33:10,920 and that only, it probably adds 555 00:33:10,920 --> 00:33:12,940 an Objective-C annotation, doesn't it? 556 00:33:12,940 --> 00:33:14,220 - Yeah, exactly, yeah. 557 00:33:14,220 --> 00:33:19,060 So, but I thought it was a curiosity and worth mentioning. 558 00:33:19,060 --> 00:33:19,900 - Nice. 559 00:33:19,900 --> 00:33:23,420 Right, well, I'm going to continue the theme 560 00:33:23,420 --> 00:33:25,380 of macro packages. 561 00:33:25,380 --> 00:33:30,380 And my second package is called Renamed by Joseph Duffy. 562 00:33:30,380 --> 00:33:33,800 And this is another really nice package, 563 00:33:33,800 --> 00:33:36,960 not a spectacular thing, but really neat. 564 00:33:36,960 --> 00:33:41,960 It allows you to rename entities with a deprecation warning. 565 00:33:41,960 --> 00:33:46,080 So effectively what it does, if you've renamed a property, 566 00:33:46,080 --> 00:33:50,060 you can add this @renamed macro annotation 567 00:33:50,060 --> 00:33:52,380 and spell out the old name that it had before. 568 00:33:52,380 --> 00:33:53,900 And what it does then under the hood, 569 00:33:53,900 --> 00:33:59,020 It creates a stub of the old property that forwards to the new one. 570 00:33:59,020 --> 00:34:05,340 And the, and the stub has a deprecation annotation that tells users that still 571 00:34:05,340 --> 00:34:09,280 use the old property, what new name it moved to, and, you know, none of that. 572 00:34:09,280 --> 00:34:13,960 All of this is very easy to, to do manually, but if you have this, you 573 00:34:13,960 --> 00:34:17,860 know, and you do a little refactoring, you don't need to sprinkle all this 574 00:34:17,860 --> 00:34:22,900 extra stuff throughout, you can just add this one single thing to your property 575 00:34:22,900 --> 00:34:27,780 and be done with it. And that's not just properties, that's also available for structs, classes, 576 00:34:27,780 --> 00:34:35,540 enums, properties, functions, and more. So quite nice. That's called renamed by Joseph Duffy. 577 00:34:35,540 --> 00:34:44,020 And not an Objective-C declaration in sight. My next package is one that we may end up using. 578 00:34:44,900 --> 00:34:48,940 So it is a package called SwiftyESBuild, 579 00:34:48,940 --> 00:34:52,940 and it's from the Tuist organization. 580 00:34:52,940 --> 00:34:57,100 So Tuist is a package, an open source package 581 00:34:57,100 --> 00:35:02,060 that will create and interact with Xcode projects. 582 00:35:02,060 --> 00:35:04,580 So instead of having, like if you're building an iOS 583 00:35:04,580 --> 00:35:06,540 or a Mac OS application, 584 00:35:06,540 --> 00:35:10,580 and you've either got a very complex or a big team 585 00:35:10,580 --> 00:35:13,340 working on a single Xcode project, 586 00:35:13,340 --> 00:35:17,180 TUIST is a way that you can create an Xcode project 587 00:35:17,180 --> 00:35:19,340 without actually checking an Xcode project 588 00:35:19,340 --> 00:35:21,300 into your repository. 589 00:35:21,300 --> 00:35:23,780 So you create the definition of an Xcode project 590 00:35:23,780 --> 00:35:26,300 and then it generates one for you, 591 00:35:26,300 --> 00:35:28,300 which is easier to work with in a big team 592 00:35:28,300 --> 00:35:30,900 and has other advantages as well. 593 00:35:30,900 --> 00:35:34,180 And one of the things that that organization has now added 594 00:35:34,180 --> 00:35:38,280 is a new package called Swifty ES Build. 595 00:35:38,280 --> 00:35:39,780 And it's actually part of a, 596 00:35:39,780 --> 00:35:43,340 I think a pair of packages, 597 00:35:43,340 --> 00:35:46,740 one that I think we will use and one that we won't use 598 00:35:46,740 --> 00:35:47,960 because we don't use that technology. 599 00:35:47,960 --> 00:35:50,180 So the first one is Swifty ESBuild 600 00:35:50,180 --> 00:35:52,200 and the second one is Swifty Tailwind. 601 00:35:52,200 --> 00:35:57,000 So ESBuild is the JavaScript build tool 602 00:35:57,000 --> 00:36:00,460 that we use to generate all our front end assets, 603 00:36:00,460 --> 00:36:04,060 JavaScript and CSS in the Swift package index. 604 00:36:04,060 --> 00:36:07,900 And it's a tool that takes, for example, 605 00:36:07,900 --> 00:36:12,900 TypeScript or SCSS or SAS files 606 00:36:12,900 --> 00:36:15,980 or any of these kind of intermediate formats 607 00:36:15,980 --> 00:36:18,820 that you have in front-end web world 608 00:36:18,820 --> 00:36:23,360 and generates JavaScript and CSS 609 00:36:23,360 --> 00:36:25,500 and minifies it and compresses it 610 00:36:25,500 --> 00:36:28,420 and makes sure it's efficiently stored 611 00:36:28,420 --> 00:36:29,500 and all the rest of it. 612 00:36:29,500 --> 00:36:31,180 So that's ESBuild. 613 00:36:31,180 --> 00:36:35,120 And the way that we currently build our front-end 614 00:36:35,120 --> 00:36:37,300 is that we have two separate build processes. 615 00:36:37,300 --> 00:36:42,140 We have the package build, which compiles the Swift code 616 00:36:42,140 --> 00:36:46,660 and generates the vapor application. 617 00:36:46,660 --> 00:36:48,500 And then we have a separate process 618 00:36:48,500 --> 00:36:50,900 that runs as part of our deploy process, 619 00:36:50,900 --> 00:36:54,180 which runs esbuild just in a Docker container 620 00:36:54,180 --> 00:36:59,020 and generates the front end side of things. 621 00:36:59,020 --> 00:37:00,540 And then the two things are combined 622 00:37:00,540 --> 00:37:03,180 and we ship the application out to the servers 623 00:37:03,180 --> 00:37:04,500 so it can be hosted. 624 00:37:06,060 --> 00:37:10,240 What I want to play with is whether we can finally bring 625 00:37:10,240 --> 00:37:14,740 those two build processes together using ESBuild. 626 00:37:14,740 --> 00:37:19,740 So this is gonna be very specific to people doing web work. 627 00:37:19,740 --> 00:37:24,900 I mean, I'm gonna say web work more than server-side Swift 628 00:37:24,900 --> 00:37:28,700 because you could generate this for any web package. 629 00:37:28,700 --> 00:37:32,260 This is not specific to vapor or server-side Swift 630 00:37:32,260 --> 00:37:39,220 specifically. But it certainly is specific to web work. So maybe one slightly off to one side of 631 00:37:39,220 --> 00:37:42,740 what most people will want, but it's something that I'm going to look at for the project. 632 00:37:42,740 --> 00:37:47,060 Right, and this is a... I'm not sure if you've said it and I missed it. This is a build plugin, 633 00:37:47,060 --> 00:37:49,540 right, that would run in the build phase or something? 634 00:37:49,540 --> 00:37:53,060 You're right, I didn't say it and yes it is. 635 00:37:53,060 --> 00:38:00,740 My final pick is... I'm sorry to say I'm going down that road again. It's called SwiftMath. 636 00:38:00,740 --> 00:38:10,220 by Michael Griebling or Michael Griebling. I'm never sure if this person is of German heritage 637 00:38:10,220 --> 00:38:16,820 and moved or is actually German. The name certainly looks German. And this is a bit 638 00:38:16,820 --> 00:38:25,600 of a follow up to the package, Mars Jax Swift that I talked about, I guess at length in episode 27. 639 00:38:25,600 --> 00:38:31,120 But this is a bit different, so I want to bring it up again, because this is a Swift 640 00:38:31,120 --> 00:38:35,680 implementation of a LaTeX MATH renderer. 641 00:38:35,680 --> 00:38:43,160 For those who may recall, the other package is actually using JavaScript's core and web 642 00:38:43,160 --> 00:38:49,360 views to do the rendering, and this is based on a JavaScript LaTeX renderer. 643 00:38:49,360 --> 00:38:54,500 The advantage of this one is that it's a Swift implementation, it claims to be significantly 644 00:38:54,500 --> 00:39:01,060 faster than using web views. It's actually based on another package called iOS MATH, which is 645 00:39:01,060 --> 00:39:06,500 in Objective-C, but this is a Swift translation of that, but the Readme specifically calls out 646 00:39:06,500 --> 00:39:11,620 that package. It isn't just a straight up translation, it also has some claims to have 647 00:39:11,620 --> 00:39:18,180 some bug fixes and improvements on top of it. So I think it sounds like Swift MATH is the successor 648 00:39:18,180 --> 00:39:29,220 of iOS MATH. I think both support UIKit and AppKit. So, they aren't. It's called iOS MATH, 649 00:39:29,220 --> 00:39:35,860 but I think it also supports macOS, the other one. But I only tried this one, and the really nice 650 00:39:35,860 --> 00:39:42,180 thing is you can just stick it in a playground. So, you can use our feature, try in a playground, 651 00:39:42,180 --> 00:39:47,540 which I get never tired of mentioning. But I just absolutely love it. I can throw it in there and 652 00:39:47,540 --> 00:39:54,740 create a SwiftUI view and then have LaTeX expression rendered and this time it actually 653 00:39:54,740 --> 00:40:03,460 doesn't pull in any extra stuff. It's all in a Swift package itself. So really nice. 654 00:40:03,460 --> 00:40:09,700 And that opens up again of course the whole world of rendering all sorts of math expressions wherever 655 00:40:09,700 --> 00:40:16,980 you use SwiftUI or UIKit or AppKit actually in that case. So really nice Swift math by 656 00:40:16,980 --> 00:40:21,980 by Michael Gribbling, I'm going to go with the US version 657 00:40:21,980 --> 00:40:25,100 of the name. (laughs) 658 00:40:25,100 --> 00:40:27,760 - Well, I'm gonna say that that could potentially 659 00:40:27,760 --> 00:40:32,020 be even more niche than my ES build plugin. (laughs) 660 00:40:32,020 --> 00:40:33,800 - Well, here you go, you're coming here 661 00:40:33,800 --> 00:40:36,020 for the niche package recommendations. 662 00:40:36,020 --> 00:40:38,100 (laughs) 663 00:40:38,100 --> 00:40:41,200 - The final, my final package recommendation 664 00:40:41,200 --> 00:40:42,680 for this week is definitely not niche. 665 00:40:42,680 --> 00:40:46,360 I think it fits in to almost, I would say, 666 00:40:46,360 --> 00:40:51,360 any macOS or iOS package, sorry, application. 667 00:40:51,360 --> 00:40:55,200 And it's a package called ReviewKit. 668 00:40:55,200 --> 00:40:59,600 And again, it's another repeat author. 669 00:40:59,600 --> 00:41:04,600 So it's by Cihat Gündüz and it's called ReviewKit. 670 00:41:04,600 --> 00:41:08,520 And so there's been an API now for a long time 671 00:41:08,520 --> 00:41:13,280 where you can request or offer the opportunity 672 00:41:13,280 --> 00:41:18,280 for somebody using your application to fill in a review 673 00:41:18,280 --> 00:41:20,920 or submit a star rating for your application 674 00:41:20,920 --> 00:41:22,320 on the App Store. 675 00:41:22,320 --> 00:41:26,720 And that API is quite unusual in Apple APIs 676 00:41:26,720 --> 00:41:31,040 is that you can call it as many times as you would like to, 677 00:41:31,040 --> 00:41:35,140 but it will only actually fire a certain number of times 678 00:41:35,140 --> 00:41:38,240 within a 12 month period. 679 00:41:38,240 --> 00:41:41,760 So if you call that function three times 680 00:41:41,760 --> 00:41:44,800 within the first week of somebody using your application, 681 00:41:44,800 --> 00:41:47,360 no matter how many times you call it in the future, 682 00:41:47,360 --> 00:41:49,940 there is no, it will never display 683 00:41:49,940 --> 00:41:52,420 to the person using your app. 684 00:41:52,420 --> 00:41:57,380 And so a good practice way of offering 685 00:41:57,380 --> 00:42:02,160 that kind of opportunity to review your application 686 00:42:02,160 --> 00:42:07,160 is to present that prompt at carefully curated times. 687 00:42:08,080 --> 00:42:11,760 And quite often, you know, it seems to be good practice 688 00:42:11,760 --> 00:42:15,460 to say, well, when somebody has done something positive 689 00:42:15,460 --> 00:42:16,620 in your application, 690 00:42:16,620 --> 00:42:20,340 that's potentially a good time to ask them for a review. 691 00:42:20,340 --> 00:42:23,980 So if they've just, if you write them a to-do application, 692 00:42:23,980 --> 00:42:25,740 when somebody completes a to-do, 693 00:42:25,740 --> 00:42:29,540 that's a, it's an opportunity that they've just done 694 00:42:29,540 --> 00:42:31,200 something that they're happy with, 695 00:42:31,200 --> 00:42:34,480 and they're done using your app at that point. 696 00:42:34,480 --> 00:42:37,000 So they're probably gonna, the next step of, 697 00:42:37,000 --> 00:42:40,320 after completing a to-do is probably to quit the application 698 00:42:40,320 --> 00:42:42,800 or to move contexts to somewhere else. 699 00:42:42,800 --> 00:42:44,460 So that's maybe a good opportunity 700 00:42:44,460 --> 00:42:48,520 to present one of these reviews, review prompts. 701 00:42:48,520 --> 00:42:53,520 And so the package allows you to record positive events 702 00:42:53,520 --> 00:42:58,100 and define criteria. 703 00:42:58,100 --> 00:43:00,560 So you can say, for example, 704 00:43:00,560 --> 00:43:05,560 I'm looking for five positive events within the last 30 days 705 00:43:05,760 --> 00:43:09,700 And it takes care of measuring those, keeping track of them. 706 00:43:09,700 --> 00:43:13,100 And then if the criteria is hit, it will present 707 00:43:13,100 --> 00:43:16,600 or it will attempt to present that review prompt for you. 708 00:43:16,600 --> 00:43:21,600 And again, this is the kind of thing that it's, 709 00:43:21,600 --> 00:43:24,260 there's no, as far as I know, 710 00:43:24,260 --> 00:43:25,320 I haven't looked at the source code, 711 00:43:25,320 --> 00:43:28,820 but there's nothing kind of terribly complex going on 712 00:43:28,820 --> 00:43:30,840 behind the scenes, but it's the kind of thing 713 00:43:30,840 --> 00:43:32,980 that you can just slot into your application 714 00:43:32,980 --> 00:43:36,940 and get a better experience for the people using it. 715 00:43:36,940 --> 00:43:38,820 And also for you, because these review prompts, 716 00:43:38,820 --> 00:43:42,060 when presented correctly, can really make a big difference. 717 00:43:42,060 --> 00:43:45,580 I've seen story after story after story of people saying, 718 00:43:45,580 --> 00:43:46,980 as soon as I put this in, 719 00:43:46,980 --> 00:43:48,740 the number of views just started to climb. 720 00:43:48,740 --> 00:43:51,780 Like it just, people do review if you ask them to. 721 00:43:51,780 --> 00:43:55,220 As long as you've made a good app, people do do it. 722 00:43:55,220 --> 00:43:58,080 - Yeah, it's nice to have that taken care of, isn't it? 723 00:43:58,080 --> 00:43:58,920 Really nice. 724 00:43:58,920 --> 00:43:59,940 - It really is. 725 00:43:59,940 --> 00:44:02,020 And talking of reviews, 726 00:44:02,020 --> 00:44:05,820 So I actually had a piece of feedback this week 727 00:44:05,820 --> 00:44:08,400 about the podcast, which was really nice. 728 00:44:08,400 --> 00:44:10,240 And it was from somebody who was saying 729 00:44:10,240 --> 00:44:14,620 that we should be a little more self-promotional 730 00:44:14,620 --> 00:44:17,440 in the podcast, and I'm not gonna do this every time. 731 00:44:17,440 --> 00:44:19,800 But it is just worth mentioning 732 00:44:19,800 --> 00:44:22,300 that if you enjoy the podcast 733 00:44:22,300 --> 00:44:26,280 or enjoy the package index, then sharing it, 734 00:44:26,280 --> 00:44:29,180 liking the video, telling somebody about it, 735 00:44:29,180 --> 00:44:33,380 I think more than the traditional like and subscribe, 736 00:44:33,380 --> 00:44:35,140 I would much rather, if you enjoy it, 737 00:44:35,140 --> 00:44:37,400 just tell somebody about it 738 00:44:37,400 --> 00:44:41,420 that would really be appreciated by us 739 00:44:41,420 --> 00:44:44,660 and is your opportunity to, 740 00:44:44,660 --> 00:44:47,900 hopefully we're presenting this review prompt 741 00:44:47,900 --> 00:44:49,340 after a positive experience. 742 00:44:49,340 --> 00:44:51,060 - Yeah, let us know. 743 00:44:51,060 --> 00:44:53,360 I'm curious what people think. 744 00:44:53,360 --> 00:44:54,360 - Absolutely. 745 00:44:54,360 --> 00:44:55,220 - Excellent. 746 00:44:55,220 --> 00:44:56,960 - So until next time. 747 00:44:56,960 --> 00:44:58,640 - Yeah, see you in two weeks. 748 00:44:58,640 --> 00:44:59,800 - Absolutely, see you then. 749 00:44:59,800 --> 00:45:01,160 - Bye-bye. - Bye-bye.