I have a prediction for your recommendations on today's podcast. And I know we're not talking about recommendations yet, but I want to make this prediction before we even get started. I predict that all three of your package recommendations today will be Swift 5.9 only. Interesting. Should I give you the answer already? You can give me the answer. Yeah, sure. Not what they are, but the... [BUZZER] Well, actually, let me check because I'm pretty sure that it's not 5.9 only. Oh,
it's not. No, no, I would have bet that it isn't. No, there's one that isn't. Oh, interesting. I have the other way around. I have one that is and two that aren't. So, between us, we have a full set of 5.9 only packages. - Yeah, I mean, there's lots of interesting stuff coming in, right, on 5.9, lots of macro-related packages. - Lots of macros, yeah. I think it proves that we did the right thing getting 5.9 into our compatibility testing as quickly as we could.
- Yeah, yeah, I am a bit bummed out that we can't support or don't support the product filter yet. I mean, we might talk about that at least briefly now and as part of the news, right, the plan was to support the product colon macro clause as a filter. But we can't yet. And the reason is that products aren't declared in the, macros aren't declared in the Swift package manifest as products. They are targets. And then they get added to a library and
the libraries, the products. So we have no way of distinguishing them at that level to support our filters because our filters really look at the products that are declared in a package. We have some thoughts around how to fix that. Unfortunately, the straightforward way of doing that and supporting that is not possible right now. So bear with us. I've seen that some packages
actually have macro in their keywords. So if you search for macro, you still get them, you get a a decent list, but it's obviously, you know, there are some, I guess there's a package called macro that'll end up in there that has nothing to do with macros themselves. So this is not as strong a filter and we hope we'll be able to improve it, but some authors have worked towards being discoverable in that way. So that's actually nice.
It's also probably worth just mentioning how people can add keywords to their packages is because it's a slightly opaque process of we pick up keywords out of GitHub keywords. So if you would like to add the macro keyword to your Swift package, you need to go to GitHub, add the keyword there, and then we'll pick that up within a few hours. And then once you do a search on the right-hand side of the search results, you can filter on keywords.
And if you then hit the macro keyword, then you'll get everything that's tagged with a macro. But I've been working the last couple of weeks on something that has absolutely nothing to do with Swift 5.9. And it's actually something we've talked about before. And I'm not gonna go into a huge amount of detail because much of it is not particularly interesting, but there are a couple of things that I think are worth mentioning.
So just to clarify what the feature is, first of all, I've been working on sorting out our Google indexing problems. So Google has, Google loves our package pages. It sends a lot of people towards our package pages. And I think it understands that bit of the site really well. And then as we put documentation hosting onto the site, Google loves us less for the documentation hosting. And there were a couple of problems.
The first problem was we were hosting multiple versions of each package's documentation. And some of those package documentations are identical because even though the package has had a new release, the documentation may not have changed. It may have changed, but it also may not have changed. And so Google really hates duplicate content in the index. And so what it saw is it saw, okay, here's one set of documentation and here's another set of documentation.
And I don't think there's any differences between the two. And it actually started to punish us for that by removing some of those pages from its index, which is what it'll do if it thinks you're trying to game it, which our intentions were true, but our actions made it look like we were trying to game it. (laughs) So obviously we want to have multiple versions of documentation. That's part of the feature that we built. We want people to be able to go back to previous major versions.
We want you to be able to see the difference between the documentation on the default branch and like the latest stable release and that kind of thing. But so the first thing we had to do was let Google know which version of each package's documentation is canonical. And so every page in the documentation, In fact, most pages on the site now have a meta tag inside the HTML that says, if you fetch this page and it's not the canonical version, here is a pointer to the canonical version.
So all of our documentation pages now link their canonical page as the latest stable releases documentation. So that was step one. And the second step is then to start to tell Google about all the different pages we have on the documentation site.
And that is actually what I want to talk a little bit more about and in more detail about, because that's where it gets more interesting that for people who are not running a package index, which the first one is like very much a specific problem that we just had, we've tried to fix it. hopefully, you know, these things, it'll take Google time to trust the site again. And it's, we're already seeing some results, which is good. Pages are going back into the index, but it's a slow process.
So before we move on to going into detail about how we're gonna tell Google about all these documentations, I do just want to mention that we had some contributions on solving this canonical URL problem from Toby Herbert, who noticed several issues with our canonical URLs, mainly to do with kind of casing, letter casing in some of the URLs, because we honor the case from GitHub of like, if you have your owner name and your repository name with a specific case, we honor that.
And our canonicals, we're not honoring that correctly. So in addition to some of the work that I did on that, others like to thank Toby for all of his work on that. That was incredibly helpful. Most helpful actually was spotting the errors, which is always difficult. So yeah, the bit that I actually wanted to talk about in a bit more detail is how we tell Google or any search engine about all the pages that we have hosted on our documentation site.
And we use a feature, it's actually an undocumented feature of DocC for this. And what I'll do is I'll link an article in the show notes from Joe Heck, who documented or wrote up a potential use for this flag and also how to find and add this flag to your documentation processing. So the flag is emit digest. And if you add that flag onto the end of your documentation generation command, you will get a few extra JSON files in the output. And one of those files is called linkable entities.
And it's a collection of effectively every individual piece of documentation in the built documentation that you've just generated. And so what we're doing is we're using that file to pull out all of the paths to every single documentation page in a packages documentation. And then we are creating a sitemap out of that set of URLs. So we're effectively saying, give me all of the URLs in this documentation.
And then we'll make a sitemap that will tell Google, look at all these different pages that we have underneath this packages documentation URL. And if Google then goes and fetches those, it will get correct canonicals for all of those. So we're hoping that the combination of those two things is gonna be a good fix to the Google problem. But the reason I wanted to mention this flag is that it is something that you may want to run yourself.
So if you are creating Doxy documentation, you might want to extract or generate this file as part of your documentation build so that you can have a sense of all of the different paths in your documentation so that you might create a manual curation of here are the most interesting bits of this documentation or maybe the order in which the documentation gets presented.
And again, Joe, in that article that we're gonna link in the show notes, he has a good bits of advice on how you can do that in the real world. - Right, and that's actually a massive amount of links, isn't it? The site map and the total number of pages that we're effectively, or have been serving, we just never really realized how many it is. You had a figure, didn't you? - We do have a figure, yeah.
When Google ingested all of these site maps, it now tells you how many URLs it found, not only in the kind of master site map, but also in all of the different site maps that it found. And it found over 250,000 URLs in the swiftpackageindex.com, which is way more than I thought we served. - Yeah, well, we've got 6,000 packages, but the documentation obviously dwarfs everything, right? That's just lots of symbols.
- It does, and I think there's actually something that's kind of interesting in that as well in that. So, it's actually, in fact, it's one of us, supporters stream the company who kindly helps to sponsor the site. They have a package which, on its own, has 50,000 or 48,000 URLs in their documentation.
Wow.
And yes. So first of all, congratulations on being the biggest documentation site by an order of magnitude on the Swift package index. That in itself is remarkable. I think one of the things that potentially needs looking at in terms of Doxy in general is how many pages it creates, because I can assure you there are not 48,000
useful documentation pages in that package's documentation. The vast majority of those are are contain almost no more information than you could get from just looking at the function signature. And in fact, a lot of them are because they're inherited from like Vue or something like that, they pick up a whole load of documentation pages for that as well. And I think- - Right, right. - That's potentially something that, you know, it's a difficult problem to solve.
Like, do you just not generate pages for if they don't have like proper document, Like what even is proper documentation, right? It's a difficult problem for DocC to solve. But I think that potentially there is an interesting discussion to be had around what that balance is. And certainly I don't think 50,000 URLs is the right balance. It certainly seems like the wrong side of useful. Now there's the other side of that,
which is who should care whether we host 50,000 documentation URLs for one package? As long as you can find the bit of documentation that actually solves your problem, it doesn't matter that there's a whole load of unused documentation pages. So there's no kind of clear cut, like there's a clear solution to this problem. But it is something that I would really enjoy talking to the Doxy team about actually.
Well, it does matter a bit, right, because we are running up to certain limits in sitemap files, aren't we? That's true. Yeah. So we do need to think about chunking stuff and it sort of gets a bit more complicated downstream or, you know, at our end and putting it all together because, you know, it's not just a single package. It's like we have, I believe, 400 documented packages now. And obviously, you know, that they all come together in the sitemap.
Now we can treat them individually as package pages, but this is a place where they all come together and we need to funnel them through one site map. And that creates certain challenges, just like it created challenges with the size of the doc sets early on that we needed to solve. - So the limit that Sven is talking about there is that site maps themselves have a 50,000 URL limit.
So if you have one sitemap, and we are now doing one sitemap per package, if you hit that 50,000 URL limit, then Google, actually, I'm not quite sure what it does. Does it just stop reading at 50,000, or does it invalidate the entire file? That's a good question that I don't know the answer to. But what we should probably do there, and you know, Srinivas talked about this the other day, but since then I've thought about it a little bit more.
I think that we should potentially, rather than go into the rather complex solution of having multiple sitemaps for a single package, which we're not actually quite there yet because the biggest package we have does only have 48,000 URLs in it.
But I wonder if we just clip the sitemap at 50,000 because a sitemap is a guide to Google to Google and what it you can tell Google about all your pages with a sitemap but from each of those pages it should go and crawl from there so it's not like if those pages are not in the sitemap they'll never get crawled they're less likely to get crawled and less likely to get crawled more often but if we're at 50,000 per package I think we may we may cut our losses at
that point. Well it would be nice if there was a way of ordering them right I I mean, if Doc C had a means of putting the ones at front at the front that actually have, you know user contributed documentation, because I suspect lots of them just have the default pages perhaps, right? Because no one has documented 50,000 symbols. So if there was a way to put that to the top then that would solve the problem really. - It really would.
And at that point we could potentially even say, well, actually the maximum that we'll have is let's say 10,000 or something like that. But there are lots of different ways to solve this problem, but I thought it was an interesting point of discussion, first of all. And secondly, that people may not know about this emit digest flag at all, because it is an undocumented flag. - Yeah. Nice. Well, the other thing we can briefly talk about, I suppose, is the big thing that happened last week, right?
VisionOS was released, like the SDK was released. And that happened a bit sooner than I thought. - Are you saying that the release of VisionOS is more important than my site map? (both laughing) - Well, you know, it's funny, I'm interested in this, but I haven't actually watched a single WWDC session about VisionOS. I've been more interested in some of the 5.9, macro stuff, tooling. And I, I thought about this.
I've early on when iOS, you know, the SDK came out, I dabbled a bit with it, but I've always been, I've always been interested in writing apps and creating that. And I've done a bit of that, but I always ended up drifting towards tooling.
And I think, I think this time around, I've, I've sort of, I'm leaning in because it seems like, you know, it's the gold rush again, or I suspect it will be to a 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. So at some point, I suspect we'll have another gold rush where people come up with cool app ideas and put them out.
But I feel like I'm going to be the one that sells the shovels, not the one that's going after the nuggets. (laughing) And I think with the index, we're in a good position and we actually have started shoveling a bit, right? We have rushed to start supporting VisionOS on top of the 5.9 that we've just added. I mean, we weren't completely caught by surprise, but it came earlier than I thought.
I thought when they said later this month, I really thought, well, it's going to be this week that it's going to drop. but it happened just one week after WWDC. So yeah, do you have any plans? Are you curious about VisionOS and building apps? - Yeah, I'm tremendously excited about the platform.
I think it's the kind of thing that watching people explore, I also haven't actually written a line of VisionOS code yet, but watching people experiment and bring their apps into the environment and kind of start to build them with that SDK, but actually just thinking more about now that we have a road that we're kind of, we've got a wheel on the road towards what AR could potentially become one day.
And I am quite excited about what AR could potentially become one day, and this is the start of that path. And so while I haven't written anything yet and I don't have any plans for a VisionOS app, I am quite excited about it. - Yeah, well, it's certainly, I mean, the samples look nice. I think I came out of WWC a bit unconvinced regarding the use cases. I mean, we had the discussion beforehand and I recall saying, I'm really curious what Apple are going to present as the use cases.
And I don't think that has truly happened yet, perhaps. Who knows? I mean, there's still time. There's certainly going to be a, another sort of introduction once it actually ships. So maybe that will change. But, um, I, I haven't seen any super, super obvious app, you know, that, that would make you jump up and say, right, this, I need this, this, this is a thing that's, that's totally different from, from all other apps. Have you seen anything like that? Is there anything convincing?
I think the convincing bit is actually the fact that it is going to run what are quite standard apps that you might see on your iPad or your iPhone or something like that. And I think that the, I think there's two exciting things going on here. We're on a path to a potential very exciting, very futuristic AR type device. But I think that's a long way away still. And then you have this potential device that could, I think, be used quite effectively in a work context.
And I think having apps around you and having, I think the concept of kind of screens is interesting and having apps separated from screens is interesting. And I don't think there's any specific app that I'm excited about, but I'm excited about seeing what that work environment maybe looks like. Yeah. Yeah. I mean, I think it's, it's easier to see the useful AR app that'll completely change how you do things once the device is like actual glasses. Right.
I mean, I think that's, for me, at least it's, it's hampered by, you know, I wouldn't, I wouldn't walk around with that thing. I mean, even if I had one, right. You're not, you're not... Nor should you and nor do Apple want you to. Yeah, exactly. But I think they don't want you to because right now it's not that kind of device, right? I think if they were
able to ship like real literal glasses, that would change the story of that thing. Which is, I think we're sort of seeing right now the prototype version of obviously way more polished than a prototype that Apple typically don't ship, right? This is like the breakout iPhone on a board with a screen and all the parts spread out a bit and a lot bigger than
it was in its final first 1.0 shipping shape. It almost feels like it's a change in that they actually released this now to give everyone a glimpse of what's to come way earlier.
Yes. And I think I wrote a little bit about this in Friday's iOS Dev Weekly, but one of things that I was convinced was just a, you know, it was a feature that was being lined up for whatever AR device that they released was last year in iOS 16 they added an AR feature for accessibility where if you were holding your phone up and approaching a door, it detected the door and it warned you about the door and it told you the information about the
door whether it was push or pull or that kind of thing and that was such a clear feature for a headset of some sort. Like nobody holds their phone up in front of them while they're walking around. It's not practical to really do that and so it felt like this is so clearly a feature for a headset and yet of course the headset doesn't do that and the reason is you shouldn't be walking around with this headset any more than you you should be walking around with your phone in front of you.
- Yeah, it's not that kind of headset yet, right? That changes the whole pitch, yeah. - Yeah, I'm confident that we'll see that feature at some point in a device that you are intended to walk around outside with. - Yeah, yeah, absolutely. Right, maybe to just bring this briefly back to what we're doing. So, platform, VisionOS platform compatibility testing is coming, it's coming along. In fact, the builder tests have just all passed. So there aren't any, we're all set up.
We just have to just, we just need to do a little more typing and then we're done. - It's not just typing. - Yeah. There have been some difficulties adjusting our test suite because we're once again in a state where there is no single macOS version on which you can run all of the Swift versions we support which is the four latest point releases so 6, 7, 8 and 5.9. And this is just my eternal wish that at some point we won't be forced to update the OS and Xcode versions and then have
machines that can only run you know a small set of those four. I mean ideally would be even more than four. I just want this Linux docker thing where any Linux can run any Swift version in it. a Docker container. And you're not going to be happy on something else. Yes, oh god, I want this so much. I want this so much. I mean, I do think we need to consider virtualization at some point because it's getting really, really, it's tricky because it also impacts our regression test suite.
It's really hard to keep testing package versions that used to fail on 5.5. I mean, we're not even testing for 5.5 anymore, so I've just moved them forward time and time again, to the oldest version that we support. But at some point you lose the capability to build those packages with the older Swift versions or the newer ones. And the test cases we were actually testing for aren't valid anymore. And it's really hard to keep that regression test in place
in some shape or fashion. I mean, because there's still value in the test, it just happens that we don't have a package at the right version or Swift at the right version to still test that. So So that makes it quite difficult. And I wish that part of it was easier for our setup and not having to manage our machines like that and decide which one we're pulling forward. Then we lose capacity on other Swift versions because the latest one can only build 5.9 - Yeah. - And so on and so on.
And on Linux, we just never have to do anything. It just, any Swift version, we can just run. - Yeah. So we're currently split back across three distinct operating system versions. Again, we have, um, Monterey compiling five seven or anything with Xcode 13, um, Ventura compiling anything with Xcode 14, which is five seven and five eight maybe.
And then we now have a Sonoma, uh, build machine that is now running, uh, beta two with the vision, OS SDK, which to bring us back to our original point, uh, we hope to ship soon. Yeah, I mean, by next time recording, we'll definitely have it. I think we'll have it next week, if not late this week. Depends a bit on when you would want to pull the trigger to actually deploy it, but it
might happen tomorrow or the day after. So, and that will be very exciting because we'll then have compatibility status for all of our packages with with 5.9 and the VisionOS SDK. Yeah, yeah, first new platform since we added ARM testing, right, which was arguably, I mean it was a proper platform in our matrix at some point, so interesting times. So we've done quite a lot of talking about package index this week, so I think we should
move swiftly on to to some package recommendations. Would you like to kick All right, I'll do that. The first package I have is called metacodable by Soumya Ranjan Mahunt, and I hope I pronounced that correctly. This is the first of two macro packages that I'm going to talk about, and it's a very nice package to tweak or empower codable performances.
And the best way to describe this is, imagine you have a codable struct and you have a field And you've given it a nice name in Swift, but the codable, you know, the JSON file has a different name and you want to change the fields name, just that one fields name and imagine that struct has lots of fields, what you have to do is you have to spell out all the fields in the, I think it's called codable keys, to the protocol that you have to adopt, you know, to, to change or
override the key definitions. And this package will give you an add-codable-path macro that you can tack on to your field just to rename a single field without having to spell everything else out, I suppose. Under the hood it just expands everything for you. That's just the perfect use case for a macro, right? Because that's a very tedious thing to do. It reads much nicer because there's no noise. It's really just about that one field that you're going to change. Really nice.
It has a couple other tricks up its sleeves. It allows nested paths. So imagine you have a nested JSON struct and you want to pull out something that's like, you know, drill down a couple of objects into the JSON file and then pull it up to the outer layer, so to speak, and to assign it to a property there. It can do that. Also be the CodablePath. And there's a Codable Compose attribute, which is, it's difficult to describe.
It allows you to layer or compose different Codable types into a common type. So you can do a little refactoring in case you're using object mapping onto JSON structs. It's best to look at the documentation, which is quite extensive, how that works. So it's a really nice package if you deal with these things in Codable, and it's called Metacodable by Soumya Aranjanmahunt. - Sounds like a package that's not so much revolutionary, but it's just gonna save you some time, right? - Exactly.
- So my first pack of recommendation also includes a macro. It's both a very modern package in that it only works with Swift 5.9, but it's also a throwback to the Objective-C days, because it is a macro that wraps an Objective-C function, which is, I think, a nice little contrast between the two. It's called AssociatedObject, and it's by, I hope it's actually the second week in a row that we've had a package by p-x9. (laughing) So we're back with another p-x9 package.
So AssociatedObject allows you to, in a Swift extension, declare an additional property, which is something that you can't currently do 'cause you can't declare anything that includes storage and an extension. And the way that it works is that it uses the old Objective-C associated object API to store and retrieve values out of memory. And so then the implementation of it is really nice.
As an annotation on a property that you're adding to whatever it is that you're extending, you just say @associated object, and you have to give it some memory management information about whether it should retain it, whether it's non-atomic, you know, real throwback to the old objective C days. But what it actually then does is it just lets you then, on the next line, create a variable, and that variable can have an initial value, and it can do all the things that you would expect it to do.
And so it's, I don't know, I really liked the idea of this package. I'm not sure whether I'd put it into a project, but I've certainly used Objective-C associated objects many, many times, and they are very reliable. - Right. - So there's no reason you wouldn't, but it also feels like you're bending the language to something that it wasn't intended to do, which is always kind of, ah, should you do that? - Does it work on any type or would it have to be a class, the extension?
- I think it has to be a class. - Has to be a class, right. Yeah, because it needs the Objective-C runtime and that only, it probably adds an Objective-C annotation, doesn't it? - Yeah, exactly, yeah. So, but I thought it was a curiosity and worth mentioning. - Nice. Right, well, I'm going to continue the theme of macro packages. And my second package is called Renamed by Joseph Duffy. And this is another really nice package, not a spectacular thing, but really neat.
It allows you to rename entities with a deprecation warning. So effectively what it does, if you've renamed a property, you can add this @renamed macro annotation and spell out the old name that it had before. And what it does then under the hood, It creates a stub of the old property that forwards to the new one. And the, and the stub has a deprecation annotation that tells users that still use the old property, what new name it moved to, and, you know, none of that.
All of this is very easy to, to do manually, but if you have this, you know, and you do a little refactoring, you don't need to sprinkle all this extra stuff throughout, you can just add this one single thing to your property and be done with it. And that's not just properties, that's also available for structs, classes, enums, properties, functions, and more. So quite nice. That's called renamed by Joseph Duffy.
And not an Objective-C declaration in sight. My next package is one that we may end up using. So it is a package called SwiftyESBuild, and it's from the Tuist organization. So Tuist is a package, an open source package that will create and interact with Xcode projects.
So instead of having, like if you're building an iOS or a Mac OS application, and you've either got a very complex or a big team working on a single Xcode project, TUIST is a way that you can create an Xcode project without actually checking an Xcode project into your repository. So you create the definition of an Xcode project and then it generates one for you, which is easier to work with in a big team and has other advantages as well.
And one of the things that that organization has now added is a new package called Swifty ES Build. And it's actually part of a, I think a pair of packages, one that I think we will use and one that we won't use because we don't use that technology. So the first one is Swifty ESBuild and the second one is Swifty Tailwind. So ESBuild is the JavaScript build tool that we use to generate all our front end assets, JavaScript and CSS in the Swift package index.
And it's a tool that takes, for example, TypeScript or SCSS or SAS files or any of these kind of intermediate formats that you have in front-end web world and generates JavaScript and CSS and minifies it and compresses it and makes sure it's efficiently stored and all the rest of it. So that's ESBuild. And the way that we currently build our front-end is that we have two separate build processes. We have the package build, which compiles the Swift code and generates the vapor application.
And then we have a separate process that runs as part of our deploy process, which runs esbuild just in a Docker container and generates the front end side of things. And then the two things are combined and we ship the application out to the servers so it can be hosted. What I want to play with is whether we can finally bring those two build processes together using ESBuild. So this is gonna be very specific to people doing web work.
I mean, I'm gonna say web work more than server-side Swift because you could generate this for any web package. This is not specific to vapor or server-side Swift specifically. But it certainly is specific to web work. So maybe one slightly off to one side of what most people will want, but it's something that I'm going to look at for the project. Right, and this is a... I'm not sure if you've said it and I missed it. This is a build plugin, right, that would run in the build phase or something?
You're right, I didn't say it and yes it is. My final pick is... I'm sorry to say I'm going down that road again. It's called SwiftMath. by Michael Griebling or Michael Griebling. I'm never sure if this person is of German heritage and moved or is actually German. The name certainly looks German. And this is a bit of a follow up to the package, Mars Jax Swift that I talked about, I guess at length in episode 27.
But this is a bit different, so I want to bring it up again, because this is a Swift implementation of a LaTeX MATH renderer. For those who may recall, the other package is actually using JavaScript's core and web views to do the rendering, and this is based on a JavaScript LaTeX renderer. The advantage of this one is that it's a Swift implementation, it claims to be significantly
faster than using web views. It's actually based on another package called iOS MATH, which is in Objective-C, but this is a Swift translation of that, but the Readme specifically calls out that package. It isn't just a straight up translation, it also has some claims to have some bug fixes and improvements on top of it. So I think it sounds like Swift MATH is the successor of iOS MATH. I think both support UIKit and AppKit. So, they aren't. It's called iOS MATH,
but I think it also supports macOS, the other one. But I only tried this one, and the really nice thing is you can just stick it in a playground. So, you can use our feature, try in a playground, which I get never tired of mentioning. But I just absolutely love it. I can throw it in there and create a SwiftUI view and then have LaTeX expression rendered and this time it actually doesn't pull in any extra stuff. It's all in a Swift package itself. So really nice.
And that opens up again of course the whole world of rendering all sorts of math expressions wherever you use SwiftUI or UIKit or AppKit actually in that case. So really nice Swift math by by Michael Gribbling, I'm going to go with the US version of the name. (laughs) - Well, I'm gonna say that that could potentially be even more niche than my ES build plugin. (laughs) - Well, here you go, you're coming here for the niche package recommendations.
(laughs) - The final, my final package recommendation for this week is definitely not niche. I think it fits in to almost, I would say, any macOS or iOS package, sorry, application. And it's a package called ReviewKit. And again, it's another repeat author. So it's by Cihat Gündüz and it's called ReviewKit.
And so there's been an API now for a long time where you can request or offer the opportunity for somebody using your application to fill in a review or submit a star rating for your application on the App Store. And that API is quite unusual in Apple APIs is that you can call it as many times as you would like to, but it will only actually fire a certain number of times within a 12 month period.
So if you call that function three times within the first week of somebody using your application, no matter how many times you call it in the future, there is no, it will never display to the person using your app. And so a good practice way of offering that kind of opportunity to review your application is to present that prompt at carefully curated times.
And quite often, you know, it seems to be good practice to say, well, when somebody has done something positive in your application, that's potentially a good time to ask them for a review. So if they've just, if you write them a to-do application, when somebody completes a to-do, that's a, it's an opportunity that they've just done something that they're happy with, and they're done using your app at that point.
So they're probably gonna, the next step of, after completing a to-do is probably to quit the application or to move contexts to somewhere else. So that's maybe a good opportunity to present one of these reviews, review prompts. And so the package allows you to record positive events and define criteria. So you can say, for example, I'm looking for five positive events within the last 30 days And it takes care of measuring those, keeping track of them.
And then if the criteria is hit, it will present or it will attempt to present that review prompt for you. And again, this is the kind of thing that it's, there's no, as far as I know, I haven't looked at the source code, but there's nothing kind of terribly complex going on behind the scenes, but it's the kind of thing that you can just slot into your application and get a better experience for the people using it.
And also for you, because these review prompts, when presented correctly, can really make a big difference. I've seen story after story after story of people saying, as soon as I put this in, the number of views just started to climb. Like it just, people do review if you ask them to. As long as you've made a good app, people do do it. - Yeah, it's nice to have that taken care of, isn't it? Really nice. - It really is.
And talking of reviews, So I actually had a piece of feedback this week about the podcast, which was really nice. And it was from somebody who was saying that we should be a little more self-promotional in the podcast, and I'm not gonna do this every time.
But it is just worth mentioning that if you enjoy the podcast or enjoy the package index, then sharing it, liking the video, telling somebody about it, I think more than the traditional like and subscribe, I would much rather, if you enjoy it, just tell somebody about it that would really be appreciated by us and is your opportunity to, hopefully we're presenting this review prompt after a positive experience. - Yeah, let us know. I'm curious what people think. - Absolutely. - Excellent.
- So until next time. - Yeah, see you in two weeks. - Absolutely, see you then. - Bye-bye. - Bye-bye.