Subscribe
Share
Share
Embed
Join us as we talk about the CocoaPods maintenance plans and Swift macro expansions in Visual Studio Code, as well as hear our regular package recommendations.
News
Packages
Creators & Guests
What is Swift Package Indexing?
Join Dave and Sven, the creators of the Swift Package Index open-source project, as they talk about progress on the project and discuss a new set of community package recommendations every episode.
I think the biggest news in the last three weeks of Swift news is that the Swift Package Indexing
podcast last week or last episode had chapters. Did you see them? I did see the chapters. I love
them. It's great. We're getting there. We're like a nearing our anniversary of 50 episodes. We've
got transcriptions. Well, we've had those for a while. Now we got chapters. It's got everything,
all the bells and whistles. It's got almost everything. Yeah. All it needs is better content.
Well, there's nothing we can do about that, can we?
Yeah, it was not a big hassle at all to get the chapters in. I won't go into a huge amount of
detail, but after editing of the podcast, I placed some markers in Audition and then
exported it actually as a WAV file and used a free utility written by Marco Arment called Forecast,
which is actually... So I tried this tool first of all with just the MP3 file, the plain vanilla
MP3 file that hadn't got the markers in it and tried to add the markers in Forecast, but I don't
think it's designed to work that way. I think it's designed to work that you put your markers in your
source file, which is great because then if we ever need to re-export it, those markers are all
in the right place. And then it takes them and just kind of compresses the MP3 and inserts the
chapter markers at the right place. So it was a very smooth process. And I can say that we will
be continuing to do that in the podcast. Great. Now Forecast is not a Swift package, is it? That
wasn't your first recommendation? It's not. That's not a recommendation. No, it is a recommendation
of a tool, but not a Swift package or not as far as I'm aware. Nice. Yeah, I heard about that one.
Oh, speaking of podcasts and players, there's something interesting I discovered just today.
It's sort of only tangentially related to what we're doing, but because I mentioned transcripts
just a moment ago, did you realize that in the Apple's podcast player, if you listen to a podcast
and you switch to the transcript page, it's pretty much exactly like the lyrics in the music app.
It plays along like the text, it highlights the current position where you're at. I thought that
was really great. Yes, I think that's a fairly recent addition to the podcast app, like in the
last couple of months, maybe. But I was aware of it. Yes. That's really great. Out of interest,
what podcast app do you use? That's in... normally I use both Apple podcasts and
Marco Armand's Overcast. Those are my... Oh, interesting. Okay. Yeah, those are the two.
I use Castro, which I've used for many, many years now. And every time... it went through a bit of a
rough patch recently with a change of ownership. And before the change of ownership, it had some
problems. But the problem is I'm so spoiled by the workflow of Castro that I really struggled.
When it was having those problems, I tried a couple of alternatives and I just couldn't
get it to work as Castro works. And it really has ruined me. I'm completely stuck on Castro
forever. But luckily, I think the new owner seems to be doing a great job with it so far. So
I'm happily sticking with it. Yeah. Podcast players are really sticky, I find. Actually,
the reason I use two is that I've started listening to some stuff on each and I have a
hard time switching like podcasts over because I sort of know where they are and how the next episode
is going to be coming in. And it's just, you know, for this podcast, I go to this player and for the
others, I go to that player. It's really bizarre how that is segmented in my listening habits.
Yeah, it's a tough business. But I think once you get a customer, it is hard for them to switch
away. So in terms of news this week, I thought there was a post that was worth us discussing.
And the post was on the CocoaPods blog. And it's by Orta Therox. And it's,
I think it's a really great post for them to make, because we'll talk about the content of it in a
minute. But actually, the summary of the post is that nothing is changing. But they just want to
be a little bit more open about the state of CocoaPods these days and how it's getting maintained
and who's maintaining it and how long will it be maintained for and that kind of thing. Because
obviously, since Swift Package Manager got support for iOS and MacOS and other Apple platform
projects in 2019, the writing has kind of been on the wall for CocoaPods that that would become the
de facto standard at some point. But also, there are so many projects around that have CocoaPods
in them or had CocoaPods in them, that even if the writing is on the wall, that tool is going
to be needed in many environments for many, many years. And it left them in, I think, quite a
difficult situation because, as he says in the post, several of the people who are the core
maintainers don't use the project anymore. And this often happens with open source that's been
around a long time. And you end up in this situation where the people ultimately responsible
for maintaining it and supporting usage of this tool in enormous companies have mentally kind of
moved on in some ways. And Orta does an amazing job with lots of open source. And he is absolutely
not guilty of moving on because he sticks with these projects until... Well, he just sticks with
these projects. I've never seen anyone like him. And I'm sure there are lots of people on the team
who also feel the same way as him, that it's so important that they need to maintain it.
But what's difficult to do is communicate that because if you make a big post and say,
"CocoaPods is shutting down," or "What does that even mean with an open source project?"
Or if you make a post like he made, a lot of people will take that to be, "Well, this is
absolutely the end." And that's not what they're saying in this post. But I thought it was worth
discussing. Yeah, definitely. I mean, I've said in the past that I'm not a heavy
CocoaPods user. Certainly not now, but even in the past, I haven't been. I've sort of seen it
in a couple of projects that I was working on. But it's very clearly been a really instrumental
part of iOS and macOS development, right? So in that sense, it's kind of amazing how
many projects are leaning on this and how important it really is. And in that sense,
it's a really considered approach, right? They're laying out a multi-year timeline before they're
even considering to make stuff read-only and sort of very clear about how it's going to be
in maintenance mode. And that meaning they're not adding features, but they're still addressing
security issues and stuff like that. When I read this, I thought, "There are lots of paid
services that could probably take a look at this and not shut down as hard as they often do, right?"
They shut down with a couple of months notice. And it's remarkable. And that's the biggest point
that I want to make while we're talking about this, which is the commitment and the way that
this team has behaved, not just with this, but with the entire history of CocoaPods is remarkable.
And I cannot commend them enough for the way that they run and continue to run this project.
I was a big CocoaPods user. It was the first thing I did with every iOS project that I started.
And yeah, it was a fantastic tool that replaced kind of working with Git submodules, which I
don't think any of us really want to do. So yes, it was a fantastic tool in its day. And while
it's true that I wouldn't consider using it these days, that doesn't mean that there aren't a lot
of projects who still are using it. What's interesting is in the post, if you read through
it, one of the things that I was kind of surprised about is that I thought that if they did give any
details on traffic or usage, that it would show a peak and then a decline. But actually, that's not
the case. And in fact, most metrics of usage and traffic are still rising because it's found a home
in a couple of different technologies, React, Native, and Flutter, both I would imagine have a
happier path with CocoaPods than they do with Package Manager currently. And I'm not sure of
the details of that because I don't use either of those two technologies. But it's interesting
how these projects sometimes find a new home where they can continue to thrive, not maybe on the
scale that they were originally, but certainly within those two domains, it seems like it may
have an even longer life. Yeah. You said something earlier that made me pause and I'm not up to date
that it's replaced, Swift Package Manager has replaced CocoaPods on Mac and iOS. I was wondering,
has it actually fully replaced it? Because I recall there is no way in Swift Package Manager to
specify an app target, right? Like you normally do. Does that not impact its use in iOS apps?
In terms of only including some dependencies on some targets?
No. I mean, like as I recall, the Playgrounds app on the iPad introduced this new target,
I think it's called iOS application that allows you to deploy directly from the iPad. And I always
thought, well, that's the sort of thing that is still needed to make, to fully transition over to
Swift Package Manager. I always thought there was something left for CocoaPods to do in that realm
or any sort of Package Manager kind of thing, because Swift Package Manager can't do the whole
thing yet outside of that Playgrounds app. Right. I'm actually, I'm not sure on that
specific example, but I'm sure there are edge cases where people would at least need to make
significant changes to their build infrastructure to move away from CocoaPods. And that's why
it's going to live for a very, very long time. Yeah. I mean, I can see that. I mean,
even if everything is there in Swift Package Manager for a big project, a big company to move,
yeah, it's just not going to be feasible, you know, or something that's going to be tackled
unless there's huge outside pressure to actually invest that time to transition over.
Exactly. Yeah. So we should probably get to the meat of what was said, which is
in the post, Autu says that basically, in fact, I'll quote from it. It says, "Strictly speaking,
we don't plan on changing how we're maintaining CocoaPods. We're just going to start to be clear
about how CocoaPods has been maintained." So I think that's great because there's actually
nothing new here. This is already the state that CocoaPods is in. And the crux of it is
that they will make sure that they handle systemic security issues to Trunk. They'll aim to make at
least two releases a year to keep up to date with Xcode updates. They'll aim to look at support
requests for Trunk every six months. They'll keep the website infrastructure from not falling over.
And they're open to pull requests that make CocoaPods more future-friendly. But they have
said they will not be following GitHub issues actively. They're not planning on doing any
active feature development on the project. And they're not going to guarantee to handle pull
requests from adding new features or application or fixing application-level bugs. So I think that's
a really sensible way to do it. It means that if you have a project that does rely on this,
you know that it's going to at least continue to support the latest version of Xcode, which is
going to be the main thing. And of course, any security issues. There was recently a security
issue with CocoaPods with their login system. And that was fixed in an extremely timely fashion,
really quick response. And it does get the attention when it absolutely needs it. It just
doesn't get a lot of attention outside of those required tasks.
Yeah, absolutely. That makes perfect sense. I really like what they lay out there. I mean,
it's what you need, right?
Yeah, absolutely.
So the other bit of news we could briefly talk about is a post that I've seen on the Swift
forums. And that is a summary of a Google Summer of Codes project by Lokesh TR that adds macro
expansions to VS Code. Did you see that?
I did, but only after you sent it to me.
Well, that still counts. So just to explain what that does, unless it's obvious,
it adds macro expansions to VS Code. So macro expansion is the thing,
you know, in Xcode when you can, I think, right click is the command. Obviously, there's surely
there's a menu command as well that you can right click on a macro and then expand the source code.
Because macros, all they do, like in quotes, all they do is sort of type out lots of stuff,
you know, like have you not type out stuff and you put in a shortcut. That sort of does the
typing behind the scenes. But it's all source code that's generated and you can expand it so you can
see what it's actually doing. And this brings that feature to VS Code. And that's just great.
I just love that these things are appearing in other editors and VS Code is leading the front
of the pack here. And it should be mentioned that a lot of these changes are coming into the
source kit LSP. LSP is a language service protocol, I believe, or language server protocol.
It's a general protocol for IDEs, like where you, where a language backend sends information about
the source code that it knows about and editors can then hook into that and use it to drive
auto completion and features like this. And Lokesh has extended this and made this possible.
And I think he's even demonstrated this working in Vim. So it's currently like fully implemented
in VS Code. But there's nothing stopping other editors that support LSP to adopt this as well.
I guess that the part that needs work in the editor end is, you know, the UI bit, right?
Because you're bringing in and showing extra code and that needs to be presented somehow.
But all the plumbing is there to be able to do that. And yeah, there's this forum post that
explains it. And there's a second one that goes into a lot more detail in how it's done and what
the parts are. And I think also a bit like future plans and stuff. In case you want to try it right
now, that means you would have to use main branches of the Swift compiler and of source kit LSP and
of the VS Code extension. But the Swift version where that's targeted to be released in is 6.1,
which I guess isn't that far off. I mean, 6.0 is probably what we'll see
next month, I believe. But I don't think Swift 6.1 is that far behind.
And then VS Code, the next extension will have that, which certainly won't be later than the
compiler. So we should be seeing this in production soon. So you don't have to fiddle around with,
you know, main branch deployments and that sort of thing.
Yeah, the language server has been a huge step forward for not only Swift, it supports a lot
of languages. And you may not know this, but there is already documentation on swift.org
for how to use both Vim and Emacs with Swift, both taking advantage of language server support.
Yeah, I'm using Nova a lot. And that is also using LSP. And you get it's like it has, you know,
the completions, which is the thing I really need the most is language is the auto complete.
And that works great. And I love that that's available and is also automatically getting,
you know, any improvements in the LSP side sort of automatically benefits all these editors.
It's just great.
The other big feature that this makes possible is jump to definition, right?
Yeah, exactly. Yeah. I think that also works.
Which is another huge, huge benefit for navigation. So yes, I shall include links in the show notes to
the Emacs and Vim documents on the Swift website as well. But if you're just browsing it off the
menu, if you just go to the tools page, it's almost the first thing on the tool page. It's
Xcode, Visual Studio Code, and then Emacs and Vim.
Yeah. Great. I think that brings us to the packages, doesn't it?
Okay. Yeah. Then I will kick us off this week with a package called SVGPath by Nick Lockwood.
And this is, as you might imagine, a package that deals with SVGs and specifically the paths within
SVGs. And there are lots of SVG packages that will pass an SVG file and render it or whatever.
What I liked about this is it takes just one aspect of that problem and solves it for something
that actually is going to be extremely useful if you're writing graphics code in an iOS or a MacOS
app. And it takes a path inside an SVG and brings it in and gives you a CG path out of it. So it
doesn't try and render the entire SVG file, but if you're looking to try and get a hold of a complex
path inside your application, there's probably not an easier way to do it than to draw it in an
application that can export SVGs and then bring that path in and just get it as a native CG path,
which I think is great. Nice. So effectively, you're saying all
these lovingly handcrafted SVG icons that we've got on the Swift Package Index site
could be converted into code paths, which we could then use in the native app that we're
writing at some point, right, for the Swift Package Index?
Probably not all of them, because there's more in the icons that we have than just paths. Now,
all of the icons on the package page, so all those kind of two-color icons that are just
literally just paths, they could all be converted into paths. But the logo, I don't think could be,
because we have fills and things like that in there.
It's not just all paths all the way down.
No, it's not. I think anything with a fill would... The fill, probably, I don't know whether
it would make this fall over, but it certainly... This is not what that's intended to do. It's
intended to grab a path. So it's basically, it lets you use SVG as a data file to store paths
with. And the nice thing about that data file is it's editable in graphics editors.
Nice. Yeah, there are a number of these tools, right, that allow you to convert,
like, draw vector graphics into code. And I really like that because it's just nicer.
Some things are obviously really nice to work in graphical representation, but there's also
often a huge benefit to have something in code, right, that you can manipulate in a different
dimension, so to speak. Nice. I don't use it anymore, but there was a fantastic tool that
I did use for several years. Well, it's still around. It's still current, called PaintCode.
Which is a... It is a graphical editor. You can draw things in PaintCode. And as you draw them,
you can see a swift representation using CG paths and CG, you know, all the core graphics code
that actually gets dynamically created as you draw. Nice. You can have your code
live, updated if you wanted to. And that was nice. I mean, partly, I'm not using it because I'm not
writing my OS on my Mac apps anymore, because we're working on the server code. But what they
also did was they created a build process that could output, I think it was a XC framework,
or it was some kind of library, some kind of compatible library. So you could effectively
save all your drawings as a single framework and then bring that into your application and use it
from there. But that was an interesting way to go about things. I get the feeling that it's not a
very popular way to do it. I think the primary way most people work is bringing in SVGs or sometimes
bitmap files and using them in the application. I think it has, these days, I think it has
transitioned much more to using SVGs rather than bitmaps. But I don't think a lot of people are
turning those images into CG code. Yeah. Well, I guess the big advantage of the code
thing was that it was, you know, the resolution was resolution independent,
but SVGs solve that same thing, right? So you have less incentivized to convert that over.
Exactly. Yeah. Yeah. There was a time when paint code was really popular. It was paint code or
bitmap. I think you could import a PDF file in like icons in a PDF format, and that would work.
But there was trouble. There was difficulties with that.
There was trouble down that road.
There was trouble down that road. Exactly. Yeah.
All right. My first pick is called Swift Cloud by Andrew Barba. And I really like this one
because it looks like a really simple way to get started with deployments on AWS or cloud
providers in general. The first one and the only one supported right now is AWS, but I believe
Andrew has plans to make this a bigger thing like supporting other providers.
And the reason I like this is because AWS can be really daunting when you get started and you want
to do maybe even just a simple thing like a simple Lambda function. It has quite the learning curve
to get started. And the examples are laid out that really the thing you need is the account
credentials. And then you can start writing a creating a little package and writing your
service definition effectively in Swift and specifying it out. It's effectively like
think of having your Swift package manifest that describes your package. You have equally
like a code representation of your infrastructure that you want to deploy. And then you can run,
it's like a plugin, then you can run these plugin commands to deploy even to like different
environments, check your deployment, tear down the deployment and that sort of thing.
So that's really nice. It's early days for the package, but it already covers a lot of cloud
primitives like web server function, CDN bucket queue and more, all these things you might need.
But because it's early days, you probably might want to test this a bit or use it for a project
where you try something out. I'm not sure even if Andrew would recommend leaning on this too heavily
this early on, but give this a go. If you don't know a lot about AWS and want to learn how this
works, because I think another route might be to use this to deploy something and then check
the AWS side of things, what is actually being created. Because I find that often a very useful
way to learn what should this look like if I use the, if I then use other tools, what do I expect
actually to happen on the AWS side? Because sometimes there's so many things you don't really
know which ones are the ones you need. And if something is there that has this path plotted
out for you as a template, then you can go back and sort of compare, right? I've set this up
in the correct way, so to speak. Now, this is server-side Swift, and I realize it's very niche.
We use it a lot. We've just said, right, all we do these days is working on server-side stuff.
So this might not be interesting or probably isn't interesting for lots of people.
But there's actually something in the readme that is interesting, even if you don't do
server-side Swift, because you probably use Docker. - I'll be the judge of that.
- All right. Well, you already have been, I believe, because the readme says if you're on a Mac,
the easiest way to install Docker is Orbstack. And that's the thing I discovered.
I was interested in the packet, but I thought I'd talk about it, because people might find
this interesting, even if they don't care about server-side Swift, because even if you don't do
server-side Swift, you probably are dealing with Docker one way or another. It's almost unavoidable
that something in your dev tools, like spinning up a database or something, will probably involve
Docker. And for the longest time I've been using, and you have been too, Dave, I know,
Docker for Mac, like the Docker desktop application, which is an application, but it's not great.
And Orbstack, I've been using this for two weeks now, and it's a drop-in replacement for this.
And it's a really nice Mac app. I'm pretty sure it's SwiftUI. It looks like a proper Mac app.
It's beautiful. It's really nice. It has all the things you would expect. And we use Docker a lot
in our project. We build images, we push images, we run databases, we
run build ARM containers, we run Intel containers on ARM Macs,
all sorts of things. And everything works just fine. You wouldn't be able to tell whether you're
using this or Docker. And key is that the Docker CLI is actually, I think, the same. This is a
front end to see your containers. So if you don't know, Docker under the hood has an engine
and has an HTTP API in front of that engine, and clients can talk to that API. And this app is a
client that talks to that engine, just like the Docker for Mac application does. It's just a nicer
version of that. But your Docker CLI is actually the same in both cases. So that's interesting to
know. And that's why all these tools. So if you have any sort of scripts that rely on Docker
commands, you can expect these to just keep on working because they're actually the same.
So yeah, it's been a really great drop-in replacement for that. Looks great, works great.
It's free for personal use, $8 per month commercially available license for that.
And I believe nonprofits can ask for reduced or free licenses as well. So it really is great.
I believe you've started using it as well, haven't you, Dave?
I have, yeah. And I haven't really. So after you mentioned it, I installed it. And that's about
everything that I've done with it. And I haven't noticed a single difference apart from the fact
that I no longer have to use Docker Desktop, which is brilliant. I mean, it is absolutely the best
endorsement of it that you don't have to worry about it. You don't have to care that it is even
there. Although Docker Desktop did get much more, infinitely more usable when they finally
implemented command W to close the window. So that was the huge step forward. And that
happened about six months ago, I think. Well, there you go. So that's Swift Cloud
by Andrew Barber. And if that doesn't interest you at all, there's Orb Stack.
And actually on the Swift Cloud thing, I actually linked to that in iOS Dev Weekly,
I think last week. And Andrew dropped me a Discord message. So because in the newsletter, I said
that it only works with AWS Lambda initially, and he corrected me, and I think I updated the
poster with the correction that actually works with Lambda and Fargate. Now, I haven't even heard
of Fargate, but apparently it's a similar thing, but using EC2 resources. So there are already two
backend implementations that it can run on. And I believe the plan is for more of those,
maybe not AWS ones as well. So. Yeah, I believe so. My memory is that Fargate is a bit like a
droplet at DigitalOcean, where you get a machine that you can deploy to,
and it's a bit easier to set up and run than the EC2 instances directly. Yes, that's it. Yeah.
Okay, my next package is called PhraseKit by Mark Battistella. And
it's a package that generates random data, basically kind of human readable phrases using
customizable word combinations, perfect for creating unique file names, username, session
IDs, and more. And yes, I was reading most of that from the description of it.
So yeah, this is not a super complex package, although I shouldn't say that because I have
no idea what's going on internally. But like it says, it generates phrases or
strings of characters based on rules that you give it. So you can, for example, say,
just generate a two word phrase would be just generate phrase. If you wanted a three word
phrase, you could say generate phrase with a word count of three, pass that as a parameter.
And then you can say that every phrase must be unique. And you can give it inclusion and
exclusion lists of words to use. So you can say, if you want a specific set of words,
here are the sets, or please never use this if you're, for example,
if you have some kind of reserved words or something like that, you can exclude them,
but it does come with a word dictionary. So I can see this being useful for kind of test data
or sample data even better. And it's not the kind of thing that you're going to use every day,
but I thought it was interesting enough. Yeah, it's nice that sort of thing. We use
something similar in the past to generate like unique identifiers that aren't just numbers
for passing around. And I think that was also used in testing scenarios, but it was really nice to be
able to refer to something a bit more readable than, you know, just numbers and still identifiable.
And, you know, it's just a nicer thing to have. Yeah. I use the tool for many, many years in
Ruby called Faker, which was a library to specifically for testing to generate fake,
but real, but reasonable test data. Right. My second and sort of final pick,
because you, you Sherlocked one of mine there and plus, plus this is a double pick. Actually,
this is two packages. Was it the last one that I phrased kid? Yeah. Yeah. Phrase kid was on my
So my pick is two packages. One is called EditValueView by p-x9 repeat package author.
We've, we've had a package of theirs before. And the other is called UserDefaultsEditor. Okay.
The other one is called UserDefaultsEditor by Ryu which uses edit value view under the hood.
And what edit value view does is it gives you editable views that adapt to common types, like
giving a few examples, like a string would have a text field and that's not just a plain text field.
So you, you have a, obviously an attribute name and a type, and then it would give you a view
with the label name and the type name and a text field as a representation. And the same for bool
with a toggle enum with a picker as the element showing it. So it gives you standardized sort of
configured views to, to allow you to, to view a data type and edit it. And obviously that's,
that's sort of a techie sort of representation of it, but it allows you to very easily build UI
for a type for instance, that, that is completely configurable while still being,
being a proper UI, you know, like where you see all the data laid out and represented.
And it has more complicated views than these simple ones, like date comes with a date picker,
color with a color picker and array dict codable has entire editable JSON representations where
you get a little text view where you can edit the representation and has all the,
the other instrumentation. So as you can imagine, that's really nice for debug views,
but I think you can also adapt this to if you have a sort of techie oriented, you know,
developer tool where you have lots of data fields to, to present, but you don't want to make custom
UI for them because there's lots of them. And they're often just, you know, strings and,
and you know, like these core data types. And as you can imagine, one kind of area where that
is useful is a user defaults editor. And that's exactly the second package. It wraps around
edit value view and gives you like a very simple thing where you just say, well, I want a user
defaults editor for the standard domain. And this is the, you know, this is the storage key for that,
the data, and then you get a fully fleshed out view. Might not be perfect. Obviously,
you know, it'll, it'll miss lots of things like additional explanation for fields, but it'll get
you started if you have defaults views, defaults data that you want to represent and to be able to
see what's actually saved. So might save you a lot of time to get started with a, with a thing,
until you actually have a different UI, more custom UI. That's great. Yeah, there you go.
That's edit value view by PX9 and user defaults editor by Ryu. I, I will do my last pick because
it's only a short one. It's a, it's another, another little lighthearted one, which is
confetti kits by Simon Støvring, which actually there's, there should be a double credit on this
because it's, it's based from the readme file. It says it's based very heavily on the implementation
from the blog post, recreating iMessage confetti by Bryce Bostwick. And confetti kit is,
I would go as far as to say an essential package for any iOS or Mac application.
And as you can imagine, it is a confetti implementation of, of randomly colored
pieces of virtual paper that shower down from the top of the screen. And I would recommend reading
both the blog post by Bryce and also the readme file by Simon before you, before you pop this in,
because especially the blog post goes through step by step, the different stages to make
random squares of color look actually like confetti before animating them down on the
screen. And there's more to it than you might think. There is a practical, even though you
might be thinking, well, there's no, there's no practical use for this, but there's actually a
practical use for this, which is quite common in iOS and Mac applications. And I think it's a,
it's an appropriate use, which is if you have an in-app purchase screen or some kind of payment
gateway in your app, then at the point that a purchase has been successful, it's quite common
to show some kind of celebration or confetti at that point, which, which this will save you the
trouble of, of, of writing that code. And it's a very effective animation. Looks great.
Nice. Yes. Required. Confetti is required for purchase confirmation.
Exactly. Yeah, exactly.
Nice.
So, so yes, I would, I would say that even though it is, it's, it's fairly niche in what it does,
I think there's a place in most applications for it.
Great. Well, I'm done. I think that wraps it up. Isn't it? Doesn't it?
Yeah. I think with that, we'll, we'll call it an episode and, and we'll be back in three weeks time
with another one.
Yep. See you in three weeks. And if any of this episode doesn't make any sense at all,
like in terms of cutting, that's entirely down to my internet going down in the middle of it
having to retrace our steps. So if this, if this comes out, well, it's all thanks to Dave's
editing prowess.
Yes. You've given me, you've given me a fun job tomorrow. There we go.
See you in two weeks.
All right. I will speak to you in a few weeks. Bye-bye.