Swift Package Indexing

We actually got some follow up to talk about. Because we know nothing Jon Snow.

Remember we talked about extending our package usage popover last time.

I do. We were going to add a product to it and we, even better than that, we followed through

and actually did add a product clause to that use this package window. So tell me what went wrong, Sven.

Well, we talked and we even ranted about package names and all that, remember?

With the Swift prefix?

Yeah, how people should name their repository one way and then use the name inside the package as

something nice, you know, without the Swift prefix and stuff.

Well, it turns out the product clause that you need to put into your dependencies, you know,

when you have a, have a target depend on a product there, you specify the product name that you use

and you specify something called package colon is the, is the label for the, um, for the product,

thing, I said, this is the package name.

It isn't, it isn't.

We use the package name in the clause that we construct there, but it actually,

that, that actually produces a wrong product clause because what actually

needs to go in there is I think what Swift PM internally calls the package

identifier, and this is derived from the repository.

So I tried out a package which had a package name auto merge, but its repository is called

Swift-automurge. And what needs to be in that product clause is Swift-automurge.

I really, really hope that once we move to package registries, which will really have proper

package identifiers, and I think there's a scheme proposed where you have like an owner slash

package sort of scheme, which obviously then allows you to disambiguate in case,

probably common case that there will be overlap in package names. Once that's there,

that'll probably allow for better package names and still avoid clashes in names.

But currently what seems to be happening, and I vaguely recall seeing this, is that

Swift PM uses an identifier based on the repository name internally as a package ID,

and that's the thing you need to specify. And I guess that's perhaps why it's called just

"package colon" and not "package name", because it's not really the name but the identifier.

- So hold on, it's coming from the Git repository, nothing to do with the package?

- I think so. I can't think of another place where...

- Okay, wow.

As actually not Swift-automurge, it's automerge-swift is the name of the

repository and what Swift PM says needs to be.

So I tried this with just automerge as the package label there and Swift PM

package resolve says the only valid package it knows about is automerge-swift.

And the only place, the only other name, the manifest doesn't talk about

AutoMerge-Swift, if I recall correctly.

So the only other thing that has that name is the repository.

- So I'm learning about this for the first time

live on the podcast,

because I knew that there was the issue,

because you opened an issue this morning.

But this is the first I've heard of the solution.

And I think it says quite a lot that,

I mean, I would say both you and I

have a reasonably good understanding

of Swift package manager at this point,

after working on the package index for three years,

and if we get it wrong, it's too confusing.

- Well, maybe not.

(both laughing)

- So I guess are we gonna have to pass,

I suppose we have the repository name already

in our database, so this I think is fixable, isn't it?

- It is fixable, I wonder if we should,

so I'd love for the proper fix to be,

I know, so for instance, if you look in package resolved,

Um, the JSON file that gets, gets written out after you run Swift package resolve.

In there, the struct, if I recall correctly has an identifier.

So it says four packages, it has the URL and in the version two of that struct,

um, there is also an identifier.

And I, I think that's the thing I need to confirm this and I would rather try and

and grab it from there or some official source than try and guess it from the

repository name, you know, because that might change and then we have subtle breakage.

I'd really like, because also this will, this will certainly change once we move to registries,

because then I think the package format will use proper package identifiers and not, you know,

these names that we're guessing. And we should really try and have some canonical source for

what's actually used to identify what package you're looking at. And I think that'll solve

everything in the end. And I truly hope the thing that we arrive at there isn't a Swift-Dash thing,

but just a proper name that is disambiguated across projects and stuff, but is still

nice and readable and has maybe a subcomponent or just a separate name that is descriptive and

can be ambiguous because it's not the one used for identity matching, but can be the one that's

displayed elsewhere. But this thing we thought it was isn't that.

The downside is that we've already shipped and deployed the wrong version, but that's okay,

we can fix it and get it working shortly. Yeah, I think it's not a common problem.

The vast majority of the packages actually have those aligned anyway.

Of course. Yes.

It's probably we're punishing the ones that actually do the right thing, sort of.

and we should absolutely fix it. No good deed goes unpunished. That's the way it

is isn't it? There is another piece of news that we have this week which is we

shipped a new feature to visualize the number of macros that a package includes.

So we've had this data in the database for a little while now and a few weeks

ago we shipped support for searching on whether a package has macro targets and

now we have a new bullet point on the metadata section in the package page

which shows you if it has any targets and if so how many targets it has and I

already found it useful today when I was looking through package recommendations

for the podcast and I looked at this one package and the name of this package

suggested to me that it might include a macro and I instantly opened the package

page and discovered that I was wrong and it didn't have a macro in it. But that was, you know,

that saved me a whole load of digging through the package for manually

trying to figure out that information. It was nice to be able to see that

right there on the package page. So nice, yeah. That's another small but

It's an important improvement.

- Nice to have that on there and not just in the search.

- It was a little bit of a struggle to come up with an icon

to represent the concept of a macro.

The closest I could get was macro photography.

So it looks like a shutter in a camera,

but I am aware that that is stretching it a little bit.

- Yeah, it's a bit very obvious icon I'd say.

- You try and represent macro better.

I don't know maybe a puzzle piece now

that I think of it. Okay with what what

connection? Well it sort of expands and

is a piece of a larger puzzle. That makes

perfect sense doesn't it? I mean in my

head that is. I'm very happy with a

camera shutter yeah. All right well I'm too late now anyway.

Right in in other news there's something worth mentioning and that is GitHub added

CodeQL support recently and there was a really nice introductory post by Tim Condon on the

Swift forums. I saw it yeah. And what this does is it allows you to add code quality checks

that run automatically on pull requests and your main branch.

So this is something, it's really simple, I just added this

this morning to one of our repositories to try it out.

It's really just a small YAML snippet that you put into a new

workflow file in your .github/workflows directory.

And then it runs a check automatically

and I guess it checks for specific quality metrics in Swift code, common bugs and stuff like that.

And the new thing is obviously that it now supports Swift. This has been around, I think,

for other languages for quite a while. And it's new that this is supporting Swift now.

As I said, we added this to a semantic version, one of our packages.

And we'll also add a link in the show notes what this looks like. There's a little overview page

for the most recent scan to show that it's working and it's done its job and

hopefully not found anything. So that's quite nice. And another thing that GitHub

added recently is in Dependabot there's now support for Swift. Now Dependabot

also is a feature that has been around for a while for other languages which is

a tool that checks for outdated dependencies in your package.

And so if you add this to your repository, it'll go through.

And now it's supporting Swift.

It'll check if there are any Swift dependencies that are outdated

that should be updated.

We've actually had this for a while now with a different package,

and that's a GitHub action by Mako Eidinger.

It's called Swift Package Dependencies Checker,

which is also really nice.

And we'll actually keep using that tool because this tool is, uh, supports the

latest Swift version.

Now the GitHub, the Penderbot feature only supports Swift 5.9, but with our

main repository, we're using it, we're already on the Swift 5.9 beta, so we

can't actually use it there yet.

So Marco's tool is, or action is still very useful for us and is also a really

nice thing to get the same feature effectively.

So what this does, it'll open a pull request on your repository when there

are changes in your dependencies.

You can review those and then just merge it if you're happy and have

one to all your dependencies to move up to the latest version.

Yeah, it's great.

And, um, I think, I mean, there was macro script is, is really good.

Um, and we've been using it happily for months now, if not maybe a year,

something like that a long time anyway.

Um, but obviously that takes, that takes investigation. And first of all,

you have to have the, the,

the idea to research whether anyone's figured out a way to do this.

And then one thing that's really important about some company like

GitHub taking a hold of this problem is that it

raises this issue into people's kind of into the

front of people's minds. You know, there'll be a lot of press around, um,

blog posts and people talking about it and us talking about it on the

podcast and other podcasts talking about it and that kind of thing.

And half of the advantage of that is just letting people know, "Oh, if you haven't yet

done this, then this is a great thing to think about for your projects or repositories."

- Yeah, and in particular, because the onboarding is so easy, there's a couple of things you can

just do with a click of a button. And the most extensive dependency check, because it can actually

do a dependency check also beyond your major version. So it can actually alert you to a new

latest major version that you're actually not opting into. And that requires additional

configuration. But all the basic stuff is actually just a click of a button. So it's so easy to

to configure that there's really no reason not to do it.

Um, the only slight downside is that GitHub doesn't have a great history,

um, supporting the latest, um, beta versions of stuff, you know, like macros

version in particular, that runners are always a bit behind and the Swift version.

I, it doesn't support it right now, but it's also a very new feature.

So we can't judge it based on that.

Um, we'll have to see how that goes, but I suspect if you're.

tracking the latest beta version of Swift, that might not be the tool for you then in that case.

- Yeah. Although there's another way to look at that, which is that now this tool supports Swift

and more and more people would be relying on this tool. I don't think they'll go into beta versions

just yet, but it might increase the urgency of upgrading to latest release versions because

If they don't, then this tool will stop working for a certain amount of projects, and maybe that

will slightly up the priority of those upgrades a little bit. I think there's one other thing worth

mentioning here, which is part of this feature I think is actually switched on by default,

and you have to opt out rather than opting in. And that is that if there is a security

CVE raised against any Swift package, it will depend upon will automatically, without you opting

into anything, it will automatically alert you to that problem. And you can then opt in as well to

have it raise a pull request to increase the version of just that one package

outside of the global dependency update thing. Oh, that's really nice. I wasn't aware of that.

That's really cool. Yes. This whole automatic tracking and reporting is just so great because

it's the thing, if you don't think about that and set up the schedules for that, it's really easy to

just miss out on all of this. And you might have an idea to sometimes run Swift package update and

absorb that, but you know, who does that manually? It's just something you easily forget. Yeah.

Right. Another thing we might want to talk about is an upcoming feature.

I mean, not upcoming in the sense of next week or the week after, but it's something that we've been

working on for quite a while. And it got sort of pulled to the forefront again, because as part of

Dependabot, there is something in GitHub that will obviously deal with dependencies. And I think

there's also a way to see package dependencies of Swift projects. I haven't actually seen the UI,

but I saw some mention of it. I need to go back and check if it's actually in the

Git UI, but it reminded me that we had started work a while back on displaying dependencies

on the package page in the Swift package index. Now we do something already. We do show the total

dependency count of a package on the package page. And all of this is based on package resolved,

which is the file that SwiftPM writes out when it does the package resolution.

Now this dependency count is nice. It is useful, but it's also, it captures all dependencies.

that is both the transient dependencies as well as the test dependencies. And

that might not always be the thing you're looking for. And we certainly want to extend this. And

we spent some time quite a while ago to look into how to extend this, in particular to

break out the test targets so we can actually display these separately. I call them product

dependencies, which are the dependencies that your products, your package products depend on,

and the test dependencies separately, and in particular to make those dependencies navigatable

on the package page. And I think it's just worth mentioning at this point how this problem is

manifesting itself with the current implementation that we have. So if you look at a package at the

moment, you might see this package has four package dependencies. And let's say, for example,

that package uses one dependency in the actual package, and then QUIC and Nimble and maybe

another test dependency to run their tests. Seeing on a package page, this package has

four dependencies might put somebody in a frame of mind of like, oh, actually, that's quite a

quite a lot of dependencies to have for what might be a small package, but actually three of them are

only there to run the tests, which I mean, in my opinion, test dependencies are much less important

when I'm choosing a potential dependency for my project than if it were a product dependency.

And also, it's also not clear on our webpage

whether those dependencies are direct or transient.

And I think if I saw four dependencies

or three dependencies or two,

I'd assume that's two top level,

but we have no current way of showing that information.

- Yeah, and it'll be really nice

if the top level dependencies were shown, right?

And you could click through

and then if there are actually a package in the index,

it'll land on that package page.

would be really nice to have that graph traversable.

You know, obviously, if if it's not in the index, which is unlikely

because we actually add them automatically,

if we find we have a nightly job that goes through

and if a package is referenced by another package that's in the index,

it's then added to the index in the next day.

So we should actually have a fully onboarded graph of packages.

But it would be really nice to have those exposed

and make them navigatable.

So yeah, that's certainly something we want to do.

And what we did first is look at package resolve

because that's really easy to do.

And Swift PM does all the heavy lifting

of actually accounting for all those dependencies.

But the problem is--

- Actually doing the resolving.

- Yeah, that's the problem.

And there is nothing in package resolve

that will tell you afterwards what are direct dependencies,

What are transit dependencies?

What are test dependencies?

It's just a flat list of dependencies.

And that's why we have that fixed number and we can't really separate those out.

There is a way of doing that.

That's not too crazy that we spent some time, um, figuring out how to do, and,

and this is the approach we'll take.

Um, but it's maybe worth thinking of the main queries where we're

wanting to support with this.

Um, and obviously all of this is up for discussion and we actually have an issue

where we currently tracking our thoughts around this, which we linked to in the

show notes.

Um, and I think, I mean, you alluded to this, the product dependencies are really

where the meat of the matter is because those are the ones that go into your app

or your service, whatever it is.

Those are the ones that partake in your, in your, um, artifact that you're shipping.

So those are the ones that going to be impacted by CVs and the like.

Or just source code breakage, right?

If you want to assess ahead of time, how exposed am I to potential API changes

and having to deal with them, the lower the number of packages, the less likely that is.

So that's why that's important.

And this also assumes that in a pinch, right, if there's breakage due to something in test

dependencies, you can ignore those, right? If your test dependencies depend on a package

that has a change so that you can't run your tests and you really need to get out a hot fix,

I think you're going to have an argument and say, right, okay, we need to fix this. We can do some

manual testing, we get this out, and then we deal with the test dependency after the fact. That's

probably something you can get away with. If that's a product dependency, you can't.

100%.

So that's why that distinction is certainly important.

But test dependencies are still important because there's this other thing that comes up

again and again, and that's being referred to as the software bill of materials.

And that's effectively your complete attack surface to supply chain attacks.

and test dependencies do play a role there because you run stuff. You run your tests,

and anything you do in CI or locally, anything you run and any source code that goes into

impact what you run there is open to any malicious package messing with what you're running and where

you're running it. A while back, way back, there was a compromised Xcode version that got shipped

and or got, you know, people were tricked into downloading it and that impacted how you ran your

stuff. And then downstream from there are all sorts of problems, you know, like secrets being

leaked because of stuff like that. So you still want to know what your total surface is, you know,

what code are you actually pulling in across your whole package, but there's a bit of a difference

in, in importance, I guess, or, and because these supply chain chain attacks are, are

probably not targeted at an indie developer or if, if it is, you know, you're probably.

You're probably not going to be picked on it.

They're going to pick the, the big targets, the important targets.

Um, but it's certainly a good thing to have exposed and to be able to see ahead of time

what the list of packages really is, what that bill of materials really is.

And maybe the last thing that's interesting is usage tracking.

And that's how many packages depend on this package P that you're looking at.

And while that's an interesting metric, that's probably one that we can never

really produce in a useful sense, because we only see open source packages.

So any usage we would ever see in these metrics is open source

packages using this open source package.

And given that we currently track 6,000 packages and there's like, it's

millions of apps out there, right?

This is going to be dwarfed.

Like it's the number of, of actually packages using a package like alarmofire.

It's not the package that we have in index that use alarmofire that are

the actual clients of alarmofire.

The clients of alarmofire are all the apps in the app store that actually

embed that library and we have no usage stats on those.

So that is probably not really even a useful thing

to try and expose.

- Yeah, it's tragic in a way because we do have,

well, we will have a really nice set of data,

but I would say that unless we come up with a way

for people who build apps to anonymously report

what packages they are depending on in their app,

which we could do. And we don't need to go into how we could do that, but we could do that.

But I also think that, you know, even if we went down that route, there's so much work to do to get

people to adopt that, that I'm not sure we could ever trust that data. And I think it's almost a

little bit of a tragedy that we'll have a subset of this, but we won't really ever be able to do

anything useful with it.

Yeah, I think it might be really nice. And maybe that's an option if a package registry had a way

of reporting that back to us or some service, because I think there's value in that for

you, even for the clients of Alarm or Fire to report that back.

Because then on the way back, that could be reporting of CVEs.

Imagine someone is, for instance, using Swift Neo and there could be just like Dependabot,

it could be a service maybe based on the package index in combination with the registry to

report back to application authors that there's something wrong and notify them

that there's a CVE against a package that they're using.

So that might be a nice avenue to incentivize people to opt in if it's an

opt in process to this kind of reporting.

And that data is in many ways much better than a lot of the data that language,

other language indexes use.

So for example, a lot of dependency indexes

for other languages use downloads as a metric

of how popular something is.

So whenever a package is grabbed by the package manager,

they'll take up a count on the number of downloads.

And that's certainly an indicator,

but there's enough downloads

that someone trying out a package

or just testing something.

Whereas if you actually have what packages

are actually in use at build time,

that's really different information.

And I think it's probably a better indicator,

but we've got such a long road to go down

for that to be anything like useful.

And I think step one is exactly what we're planning

to do here, which is give people some information

about the dependencies of the packages

that they are considering using themselves

and not to worry about the bigger picture.

- Yeah, and I'm hopeful that we can break this down further

because it's quite a large piece.

I went through my notes this morning

to sort of recap where we left it.

And this is going to be quite complicated.

And hopefully there's some intermediate things

that we can release to make that incrementally more useful

than it is now with the total count.

- Even if it's just the case of bringing the data

in bit by bit or adding the extra bits of analysis

on the data bit by bit before we expose anything

to the user interface.

So yeah, I think it would be good to chip away at this

in smaller chunks.

It's always better to approach things that way.

- Yeah, definitely.

- Right, we've actually,

we've whitted on quite extensively today.

Let's get into some package recommendations.

Do you wanna give us the first one?

- My first one is called DataKit by Paul Kraft,

Paul Kraft, he's German, so I'm confident in the pronunciation of the name.

That's not what I got from the way you said that.

I didn't get any confidence at all.

Damn.

DataKit is a really great package.

I loved, I loved seeing this.

Um, it's a great package when you're working with custom binary data formats.

And this sort of brought me back to a time several years ago when I had to

decode a proprietary proprietary data format.

Um, and even way back further in the physics days, where we're losing, using

lots of proprietary custom data formats, because it really, every bit even counted

at the time, and this can be really fiddly, but what this package does, it

gives you a, um, result builder based DSL where you can actually specify this.

It's really nice.

It sort of looks like Swift UI layout, but for your data, you can define static data

blocks, like certain byte patterns that you want as markers.

You can then specify your values, properties, do conversions where needed.

So by values, properties, I mean, you know, like data types.

And obviously specify quite in detail ways, the bit size of them.

Use conversions where needed.

really nice. The reading and writing can be driven by different conformers to a read format

and a write format protocol. That's if you have to do different things or if you only implement a read

of a format, for instance, or you can do it jointly by conforming to a format. It's a bit like

codable, you know, that has a encodable and a decodable form protocol that you conform to.

And it also has a CRC checksum support component so you can tack this on and then

I guess in some way ensure that what you've received and decoded is actually

came across the wire and is intact still. Really nice. This whole thing works in a playground so

you can use our feature to try in a playground which I always love calling out because that's

how I actually play with packages and look at them and you can and that I would have found really

really useful working and trying to load a file, stick this in and then piece by piece try and

parse a file back out. So really nice package. DataKit by Paul Kraft. How was that for the

pronunciation, Dave? Yes, much better, much more confident, absolutely. My first package is a

package that we don't use directly, but we do use the underlying technology behind it.

So the package is called SwiftWhisper by Aaron Taylor. And it is a wrapper around a C++ library

that interacts with the Whisper AI model from, I believe it's OpenAI that produces the Whisper

model. And Whisper takes audio files and will transcribe them with quite unbelievable accuracy.

It is a remarkable library. So we use it to transcribe all of these podcasts. We run it

through an application called MacWhisper by Jordi Bruin. There's also an app called Ico, which I

which I believe is by Sindre Sohus.

And both of those use the whisper model

to take in an MP3 file or a web file

and produce a transcript.

And I mean, I'll see how it does with the,

with your pronunciation of the previous author's name

this time, but it does actually get author names

like remarkably accurately transcribed.

It's an amazing bit of software.

And so this package is a way for you to interact

with that model from a Swift application.

It doesn't come with the models included,

but it does include a link where you can download

pre-trained models, 'cause obviously the model

is a huge part of that dependency.

But yeah, it seems like a really easy way

to get either offline or even potentially

real-time translation, transcription, sorry,

into an application that you're looking at.

And the nice thing about it is that these models

can be shipped along with your app.

So it's not the kind of thing

that requires an online connection.

- Nice, yeah, I'm really surprised

about the quality of these tools

and how quickly that evolved.

Cause I recall that being quite difficult and often, you know, especially with

technical terms and names and stuff, this, this is so amazing that this actually works.

I mean, there's still cases where this doesn't work correctly, but you can see

with, with, you know, bigger models that it'll, it'll get there.

And I, even, even humans fail at this at times, right?

You misunderstand something or you have a different term in mind and are

confused about what it is.

So it's not, not surprising that this goes wrong sometimes.

And we've talked about this on the podcast in the past and this idea of,

um,

uses for AI that don't involve the AI having to come up with kind of original

thought or original data or knowledge based answers and things like that.

And this is a perfect example of that. Yes,

it might not get every single bit of transcription correct,

but it's never going to just start hallucinating or at least in our experience

it doesn't, it doesn't hallucinate. It sometimes,

It sometimes makes mistakes, but it never hallucinates.

And it's because it's that problem domain

is very well suited to this kind of AI.

- Well, sticking with the theme,

my second pick is actually very similar.

It's called Cleverbird by BT Franklin.

And it's an open API, no, it's an open AI API wrapper.

And I actually mistyped this in my notes

because I always mix these up.

Open AI API wrapper.

And it's actually the package we're using in one of our packages to generate package

descriptions. So this is a little proof of concept kind of thing that we're doing.

And I had a really interesting use case this week for these package descriptions.

I actually used our tool to generate a package description for a package

called a ZuKeyKanaKanjiConverter.

And this is a package, we'll have a link in the show notes that has a readme in Japanese.

And because the GitHub page is in English and the readme is in Japanese, the Google's page,

webpage translation or Safari's webpage translation doesn't work or it's not offered as an option.

So I couldn't really tell what this package really does,

and I wasn't sure if I might want to mention it.

So I ran this tool on this package,

and it actually gave me an English description

of the package, what it does,

and it does appear to make sense.

So that's really nice,

how these tools open up these things.

Not only does it tell you what this page is about,

at the same time, it gives you a short summary.

So I think that's a really interesting use case

these open AI or general in general and AI tools?

Um, you may or may not know this, but, um, in the work that I did on the prompt for generating the

summaries, um, I actually looked into also translating and there are lots of different

options that you can kind of get out of, um, uh, of GPT with translating or not translating. You can,

you can and it understands your wishes to summarize something and also translate it at the

same time or summarize it and keep it in the same language and there's lots of different options.

Especially with the translation, you're straying into stuff where

potential hallucination could be quite dangerous because you might not know whether if it was

translating something, you might not know whether that translation was accurate or not. But certainly

in summaries it's often operating on a very good set of initial data. But certainly that

translation, I think that actually made it into the prompt that we ended up using

in the end that it should also translate it to English.

Yeah. I recall, didn't you test it with a Chinese package or something when you wrote the prompt?

Yes, we did with Chinese. I think we tested it with both Chinese and Japanese text.

Nice. So yeah, that's so the the OpenAI wrapper, API wrapper is called Cleverbird and it's by BT Franklin.

That's good. My second package today is called Stores and it's by Omar Albeek.

And Stores is a key value store to store code of all types, but the destination of that store is

is configurable. So with the same data layer, you can store your data in user defaults on the file

system, into core data, into the keychain, and you've got the same interface to all of the

storage no matter what ultimate destination you're using. Now, obviously we've got Swift data, which

which is new this year and in beta at the moment.

And from what I've seen so far, I really like Swift data.

And I think it removes a lot of why I hesitated

to always recommend core data,

which is there's quite a lot of initial setup

and you've got to think about,

you've got to think about your storage quite carefully

before you pick a core data.

Where sometimes a plist file on a file system

a JSON file and file system might do just as good a job,

depending on what kind of data

and how much data you're looking at.

And what I quite liked about this package is that

you can almost defer that decision.

So with the same interface to the data store,

you could start with file system store

and then potentially move up to a core data store later.

Of course you are tied in

and with any data storage package,

or in fact, any package that goes in

at the root of your application,

it's a much, what's the best way to say it?

It's a much heavier dependency to take on

than something that's right at the edges

where you could easily replace it.

Once you make a decision in your data store,

you've gotta be really sure

you wanna stick with that data store.

- Yeah, that's load-bearing.

(laughing)

- It is load-bearing.

That's exactly the way to describe it, yeah.

But I quite like the idea of it,

and it looks to be fairly mature.

It's only been around for 11 months,

but it's already had 12 releases, so that's a good sign.

And it's well-documented.

The documentation is hosted on the package index,

which we know that always gives people a leg up

into getting picked on this podcast.

(laughing)

So that's Storz.

Right, my third pick is the Swift composable architecture package by Pointfree.

And the reason I want to mention it this week, and I think because I think I mentioned it before,

is that they've now made their 1.0 release. So I think that's certainly worth talking about

briefly here. We should also mention that Pointfree are sponsors of Swift package index.

But all their packages are open source and free so you know you can get a lot out of them.

They really have great packages and they have excellent documentation so

you don't need to subscribe to point free to make use of it.

This is all available and really really high quality even before 1.0 release.

I've been using the composable architecture for I think at least three years now.

Now I'm not writing a whole lot of UI apps. I think I count like four small ones over the last

four years, but they're all TCA based because I, once I learned how that works, it really resonated

with me to the extent that I, I really feel like I can't write UI apps anymore. Well, actually I

didn't, I never really felt comfortable writing UI apps before because of the way I tend to write

code which is really test based.

So I really like to test stuff and UI code is often really hard to test.

And that's perhaps the strongest argument for TCA that I can think of, at least

personally for me, is that it makes UI apps so testable and therefore manageable.

Because the thing is you might bang out an app really quick without tests, but

Where it really pays off is in the maintenance.

If you have, you know, add more features, have more releases, the bigger your test

suite, the easier that still stays and remains updating your dependencies, that

sort of stuff, all that stuff really scales much better, is easier, more easily

done if you have lots of tests and TCI really makes that possible.

Um, they have this, um, unidirectional data flow where actions modify a state

in a store and that's really the only way to modify your store and your views are really

just displays of the store. And that concept really makes it for me like really natural

and easy to work with UI because it then becomes less magical. I always struggle with UI apps

because stuff seems to be happening magically. One change, little change over here in the

would suddenly make things happen on another end.

And I never really got quite comfortable with that.

And TCA, I think is the thing that really made that click for me.

That you can test all the logic in unit tests and then have snapshot tests,

for instance, for your UI views.

So, yeah, there you go.

TCA, the composable architecture 1.0

after a long time of being in pre-release by point three.

- I think it's also worth mentioning

with Composable Architecture that they've done a great job

with obviously documenting it through their video series,

of course, but also documenting it through

actual documentation.

And they've also put together one of those Doxy tutorials,

which is an extensive,

I think it's like a four hour potential length tutorial

or something like that that I saw

that, you know, putting together a tutorial like that takes time and effort. And it's great to see

that kind of effort going into an open source package like this. Yeah, the other thing I really

want to call out is, you might think, well, 1.0, I'm going to wait for 1.1. The way they've dealt

with version changes, even leading up to 1.0, I don't recall a time when there was a breakage.

They always had releases with deprecation warnings and then the most detailed adoption

documentation.

You're like, when you adopt the new version and you get deprecation warnings, you need

to do this to fix those.

Or, you know, if you jumped a few versions, you could see, all right, I need to do this

and this to fix my compile errors because you skipped over the deprecation version,

ended up on the new version.

It's been, I've picked up apps that I'd written

three years ago and went through,

and it has always been really, really hassle-free

to move along, and I'd say this is a safe library to adopt

if you're concerned about breaking changes.

It's really amazing the way they've dealt with this.

- Although to use your phrase before,

this is very much a load-bearing library.

- It is, yes.

You have to be, you have to buy into the concept.

This is not something you'll pick up in one evening, I guess, unless you're

perhaps comfortable or you know React Native, which is I think very similar.

Or I think Elm also has this unidirectional data flow concept.

It's certainly different.

It's quite, and it is an architecture.

It's like an honest architecture that you need to adopt in your app.

It's not something you should do lightly.

Having said that, I do believe it's something you can adopt partially.

So, um, this might be something to look into.

I do believe you can do this in, you know, in a, in a screen or two in your app and

I see how it goes and take it from there.

So you don't need to onboard your whole thing into this, but it's certainly easier

to get to start out with this in a, in a new app or a smaller app to, to see how it

goes and that goes to Dave's point that there's a really, really good tutorial and extensive

tutorial. So there's lots of stuff there to get started with it and see if that's something

for you.

That's great. My last package is not this week a cleverly or amusingly named package,

It is an amusing content to this package.

The package is brand new, five days old,

and it's called Swift NRC by Joe Hinkle.

And I'm not entirely sure,

I may be misrepresenting this package terribly

in saying that it's kind of a music content,

but it's the description of this package is,

Swift objects without reference counting.

Do you ever wish you could go back

to manual memory management and Swift

is the kind of language that just does not let you do that?

Well, Swift NRC is here to help.

It's effectively a package with a macro inside it,

which allows you to use the unsafe pointers of Swift

in a slightly more,

is they wrap up the unsafe pointers

to allow you to do your own memory management.

I don't think you should use this package.

I think this package demonstrates

some interesting things with macros.

I don't think we should go back

to manual memory management,

although there are potentially uses

that may be performance or something like that.

Although even then, I'd be really surprised

if going back to pre-arc days was ever a good idea.

But I did, it did make me smile.

It did make me, it's an interesting little package

and I thought it was worth a mention.

- Very nice.

- But please don't use it.

Right, and with that, I think we should call it,

and we will be back in two weeks

with more package recommendations

and potentially an update on dependencies

potentially a fixed version of our use this package popover. Great, see you in two weeks.

So until then I will see you in a couple of weeks. Bye bye. Bye.