Swift Package Indexing

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.