Swift Package Indexing

Happy New Year! Yes, Happy New Year! We had a rather delayed start to podcasting in 2025,

but here we are back again. Yeah, we had a nice, longish Christmas break,

at least when it comes to the podcast. But lots has been happening while we've been away,

so we should catch up with a few announcements. Actually, there's one announcement which happened,

I think it was maybe even yesterday as we record this, which is a... So there's obviously a whole

load of Swift working groups that have been created and have been running for the last few

years. Things from like the Swift website work group is one that I'm a member of. There's a

Swift documentation work group, which both of us are members of. There's lots of these working

groups that have... There's a contributor experience one, I think, and probably some...

Oh, there's the diversity work group as well. So there's lots of these work groups that are going

on. And so far, they've all been organized by the Swift team. But I noticed a post yesterday,

which was the announcement of a community working group. So it is a Swift on Android

community work group organized by Yuenos Orlandos. And it's intending to, I guess,

either be a precursor to an official one or just for it to exist on its own, with the goal of

promoting and working towards broader and faster adoption for Swift on Android.

Yeah, I was actually wondering if that's an official group or what even makes an

official group. It sounded like this was a group as a peer to the other groups. But I guess community

work group is slightly different. It's a bit unclear. But then again, I mean...

Maybe I've assumed it's less official than it is. The only reason that made me make that

assumption is because it was called a community work group, which I guessed was being organized

without the involvement of the Swift team, although they may be involved.

Well, certainly, if you look through the announcement post, the replies, I think

immediately people started being active and interested in contributing, especially people

from other working groups, the platform steering group.

Ah, yes, there have been more posts since I checked it yesterday.

Yeah, yeah, there's a lot going on. Really interesting. And I think it sort of also

highlights that Android is looking at the activity. It seems to indicate that Android is

an interesting additional platform. It seems there's quite a bit of interest in

getting this off the ground. And yeah, maybe that's... I mean, some of this is...

So two members are Mark Prudhommeau and Abe White of SkipTools. And you had this in iOS Dev Weekly

recently, right? Yes.

Mark Prudhommeau's compatibility page where he's testing Android compatibility of packages.

It's actually, I think, based on our package list, a subset of it at least.

I believe it is, yeah.

And I think there's value in considering whether we should start running Android tests. And maybe

that's an indication of the amount of activity there and how well that's being received, whether

that's the next platform, one of the next platforms we should be looking at.

Yeah, I think it's always good to see people interested in bringing it to more platforms.

And to see people organize like this and kind of put some structure to it is even better.

And like you say, Mark and Abe from SkipTools, I'm very happy and not surprised to see them

involved in this because their product is also entirely around bringing apps

written in Swift to Android.

Yeah, absolutely.

So that's great. I mean, I think it's always nice to see community or maybe it is official,

maybe you're right that this is exactly an official work group, but it's just got a different

word in it.

Or it might be a precursor and become one. It's not entirely clear from the announcement. But

again, I mean, does it really matter all that much? I think the point is that there's a group

that deals with, sort of pulls all the different bits and pieces together, because there have been

a couple of efforts in the past targeting Android. And I think it's great to see that this is just

like becoming a joint effort where this is going to be turning into a proper SDK with proper

support and all that, and a group of people who look after it. Good to see.

And it's also great to see that the, as you say, the people in that thread, there are a mix of

Apple people, or should I say Swift team people and community members. So it's great to see,

even if this is not an official work group, it's great to see the Apple people immediately

getting involved, which is just lovely to see.

Yeah, yeah, absolutely. Right. There's been another bit of news quite recently at Fosdem.

That was the Swift build announcement. I think you had some notes on that, didn't you?

Yeah, I think this is a very exciting project. It's been a thorn in Swift's side for a little

while now that there are effectively two entire build systems. One, which is Xcode build, which

is part of Xcode, either running through the Xcode application itself or running through the

command line tool Xcode build. And then there is the entirely different Swift build command,

which is not as capable in terms of trying to build every type of product that Xcode can build,

but is cross platform compatible and works on Linux and works everywhere. And so they both have

advantages. And one of the artifacts of having to build systems for Swift is a little bit of

complexity that we've had to put into the Swift package index, which is in order to determine

macOS compatibility for a package, we have to attempt both the Swift build and an Xcode build,

because some packages will build with Swift build and some packages will build with Xcode.

And it's not necessarily the case that they'll always build with either one of those two. So

you have to kind of do both to get compatibility. So we've been in this situation where we've got

these two build systems, and that is really less than ideal. And as I understand it, the primary

purpose of Swift build is to get one unified build system across both of those situations.

Yeah, I just can't wait for this to be fully unified. And obviously, we won't be able to drop

our running of two builds in parallel with Swift build and Xcode build for a while. But

at least there's now a future where we can delete all that duplication and extra maintenance stuff.

Is it actually the case that we may have to in fact run three builds for a little while?

Oh God, no, no, no, no, no, no. I think the minute this is sort of switched on, which is,

I presume that that would be a WWDC announcement that this is the now official build system.

For what is it going to be Swift 6.2, I suppose. I think at that point,

And Xcode 17.

Yeah, I think at that point, we do whatever is the default. But there has to be a date when it's the

default. And I think that's the date for us to sort of unify it. And then we just have to wait

for the older Swift versions to drop off the matrix. And then we can finally delete the

duplication of running these builds and builds and the documentation generation, which is also

sort of, you know, we have to maintain two different ways of doing that. And it's just,

I'm just super glad about this.

Even if we won't be running three builds per package, we may end up running three build

systems for a while because for the Xcode 17, Swift 6.x, whatever that is, that will need the

new build system and the old two, as you say, will be there for previous versions until they

drop off, which is probably several years away.

Well, my hope is...

Complexity gets worse for a little bit, but this is in the pursuit of a better solution. So I'm

still happy to see it.

Yeah, absolutely. Plus, from what I've seen, it's effectively a flag on Swift build, I believe,

to use the new build system, obviously, with a corresponding toolchain. And I think an Xcode

build might even have the same that you can use Xcode build as the front end to use the build

system. I'm not sure how Swift, like the Apple platforms would work, because right now you can't

really build for iOS and to be US and stuff with Swift build. But I suppose all this will sort of

be part of that. I mean, this, the open sourcing of Swift build is sort of, I think, a requirement

to actually have Swift packages that you use, you know, that you build iOS apps from, like you do

with Swift build, which you right now need to use Xcode for. So there has to be a world where this

is also unified. And I suppose this is the first step towards that. Well, certainly I hope that's

the case, because otherwise we have gained nothing.

Right. Yeah. No, I'm confident that what you laid out there is their intention.

Yeah. Let's see what happens in June.

Exciting times for build systems on Swift. It's not a topic that a lot of people

imagine that they'll care a lot about. But here we are.

Here we are.

There's another bit of news, which is a bit older. I had this in my notes for a while. That was an

interesting forum thread on the Swift forums about open source funding. This was opened by Taylor

Swift, user Taylor Swift, Diana on the Swift forums. And this is interesting in itself. So

Diana, you know, raises some or brings up some thoughts on how open source can be funded and

maintained so such that it's not just on free labor of people who are volunteering their time

to work on stuff. But I also noticed an interesting link in that thread. So the thread is from

December. And someone brought up a bounty platform that's being used by tourists, apparently, and

it's called Algora. And a person jumped in the thread and said they've actually updated the

platform to be Swift specific. So I think there's some Swift specific stuff. And there's swift.algora.io

is the homepage. And it's a bounty and tipping platform where you can use GitHub commands to

put up bounties and give tips inside issues and pull requests. So you could have an issue

where you do a slash bounty and then a dollar amount or equally have an issue and you do slash

tip dollar amount and username and tip someone an amount of money, which I found really,

really interesting, like an interesting way to get funding into an open source project.

Also slightly, you know, what makes me a bit nervous that there's a slash command where you can

just spend money like real money that seems like super, super easy. But then again, that's the

point, right? To make it easy for people to actually fund stuff. And I thought that's really

interesting, maybe to think about and talk about and see if that's something you could use. I think

often, and we've talked about this in the past, the problem is not that companies don't have the

money or even the willingness to fund open source work. It's the how, right? There's a

how do I get the credit card into the right person's hands to then make a payment to the

maintainer? It's really strange or often difficult that an open source maintainer doesn't have a

company set up, doesn't have a billing set up and I can't really get to the money that might even be

there. It's this disconnect between, you know, there's a service that's being offered effectively

and needed, but the person who needs it doesn't really control the money and needs to get

approval from somewhere. And, you know, big companies, that's often a huge headache.

It's easy to buy a book or to fly to a conference and then get money into a maintainer's hand is

effectively what I'm trying to say. And if maybe if companies were set up to be able to

have a pool of money for bounties, and then, you know, certain members of the team who

control that and could dole that out that way, that might even be interesting or might be a

good approach to help fix this problem. - I think there's two sides of it. I think

you're absolutely right that one of the sides is getting that credit card into the system,

actually being able to make the payment. But the other part, especially as the companies that you're

dealing with get bigger, the other part is having approval. So like people will have,

like you mentioned, it's easy to get approval for a book or, you know, something like that,

that will help you learn something because companies have in place the mechanism for

staff training and that kind of thing. And so you can normally find a bucket to put stuff in.

You can find a bucket to put almost everything you want in a company. And open source funding is

there is no bucket for open source funding in most companies. - And that's the unfortunate thing,

isn't it? - Yeah. And so it's all very easy for a company to wave their hand and say, "Oh yeah,

we should support open source software." And it's a whole different thing to actually get to the

point where getting that credit card is the problem. So you have to have that pre-credit

card bit, which is the, well, let's make a bucket for open source funding. And that's obviously

a much bigger and more difficult conversation inside most companies. I do think though,

that just looking at this site, that this seems like a great way to do that second step in the

chain. And I wonder if there's anything they can do, like, can they prepare, like, here's a kit

that you can take to your, you know, your finance department to explain why you should support open

source and get that first bit done as well. Because that's obviously, I think, the bigger of

the two problems. Although I think this is great. - Yeah, I think it's a bit like, you know, at some

point companies decided, well, it's actually helpful to have a training budget, you know,

a conference budget. But companies at some point need to realize, well, it's actually not only

helpful, but even critical to also have an open source maintenance budget because they're leaning

on that work. And there's going to be a point where the risk is just going to be really high

if stuff falls in disrepair and is being maintained. And I think it's about time that

this gets on people's radar, that this is really critical. But there's another point I wanted to

make, and I actually replied in the forum thread about this. And that's that this sort of stuff

is often quite transactional in the sense that, and slash bounty is an example of it. I put a

bounty on this issue. I think open source work doesn't always fall into a clear feature or a

clear bug fix. Sometimes it's just maintenance. And that can be updating dependencies, updating CI,

modernizing the code base, you know, with language or dependency changes, that stuff.

A CVE popping up, and you know, you can't start a bounty program once the CVE has already happened,

you sort of need to have someone there who knows the code base and can jump in and fix it. And

there needs to be an understanding that there's just base level maintenance that needs to be

paid. And that is doing these tasks that are listed, but also having someone who actually

knows the code base, because you can't start ramping up when stuff is really urgent. You

know, you sort of need to keep the engine running on some level to have actually people there who

can make the changes. And I think that that sometimes gets overlooked in these discussions

when open source is talked about, because it's about, you know, a next big feature,

a big bug fix or stuff like that. And it just doesn't always come in nice little packages like

that, if that makes sense. Yeah, I think that the maintenance point is really well made. And

certainly, for some, you know, the more popular your open source project becomes, the more

important things like that becomes, because it is impossible to ignore CVEs at some point,

if you have an open source project, which has got significant usage out in the wild.

But that's the kind of stuff that's really hard to get people to, like you say, it's hard to

Yeah, that's not bounty work. That's, that's, that's work that you need. I guess that's what

a core team is for, right? On most projects, most projects of any significant size have

a core team of maintainers. And funding that core team of maintainers is, is a different problem.

Which, yeah, I mean, open source funding, we could talk for hours on open source funding is,

I think it's something we both have lots of thoughts on. But I'm glad to see any kind of

initiative like this to help. And this one does look good. Yeah, let's see what comes of it.

Yeah, absolutely. Before we get on to recommendations this week, there's just a

little kind of public service announcement that I want to make, which is, as I was looking through

all of the packages to, you know, figure out what I was going to talk about this week.

There's a common problem, and I'm finally going to talk about it, which is

readme file. So as you as you've, you've made this new package, you've created something that

you're very passionate about, and you want to tell the world about it. So you write your readme file.

And of course, as the package author, you're very familiar with the subject matter

area. And so you start writing, and it's very easy to assume a lot of knowledge that the people

reading it might not have. And I see this problem all the time in terms of package readmes. And I

came across one, this is not part of the picks for this week. But I will mention this one package,

because it was, I think it was a great example of this. And it was a package called fit parser,

F-I-T parser, which has a great readme file. And it explains exactly how to use the package. And it

tells you how to import it. And it tells you how to add it to your dependencies, and all the rest

of it. But it doesn't tell you what these fit files that it's dealing with are. And only at the

very bottom of the readme file, did I spot a mention of Garmin. And it turns out that these

fit files are Garmin kind of workout data, or root data, or something like that. But we get into the

bottom of a, you know, 500,000 word, sorry, 500 or 1000 word readme to figure that out. And I thought

it was just worth mentioning that, that try and read your readme file from the perspective of

someone who has absolutely no domain knowledge at all, before, before publishing a package,

because I'm not sure whether I would have picked this to read, but there's a good chance that I

wouldn't, that most people wouldn't even have got to the bottom of the readme file, they would have

just moved on. Yeah, I was actually going to do a conference talk once I even started to write it,

but I forget why the conference, I think the conference was postponed or cancelled or

something like that. And I was going to talk about readme files for open source projects,

and relate it to kind of marketing your app to the public. Because what you're actually doing

with the readme file is you're marketing your package to developers. And so there's a whole

load of similarities between what you need to do to get a successful app marketed to people

in the real world on the App Store, and what you need to do to do that for developers on the Swift

Package Index. Maybe I'll resurrect that conference talk and do it at some conference sometime,

because I think there's a lot to be, there's a lot that could be improved in that area.

Absolutely. I suppose we sort of look at more readmes than normal, but still it is quite

noticeable that sometimes people assume a bit too much about their package. And the other thing is,

I often see lengthy installation and usage instructions, which...

Me too. I don't understand it.

It's a bit tricky, right? Because if your package is just on GitHub, and it's not surrounded by

any of Swift.org, or maybe even the Swift Package Index, where there are other places on how to use

it, right? We have the pop-up, "Use this package," where it guides you through that. If you look at

a package outside that context, there is no other immediate surrounding context to fill that in.

But I guess at some point, you know...

My issue there is, it's not the mention of installation. It's the depth which people go to.

Yeah, and then there's Carthage and Exkoda.

Exactly. Like, mentioning this is compatible with Swift Package Manager,

CocoaPods, and Carthage...

And then link out.

That's all you need to say. You don't need to say how. Maybe you need the pod name.

Exactly, yeah. But it's quite often half the README file is installation.

I guess in some cases, it's from an era when it wasn't that obvious, right? When you had to sort

of... "Well, how do I use it? Was it pod, or is it Carthage?"

Of course. And it also becomes a standard within the community. "Oh, well, everyone else is telling

people how to install it, so surely I need to do the same." I think there's a bit of that happening

as well.

We've been running quite long, but there is actually one other topic I'd like to bring up

before we do our recommendations. And that's another interesting thread. It's a pitch on

the Swift forums. It's about last expression as return value. And the reason is twofold. I wanted

to talk about this. So A, it's an interesting technical discussion. It's quite lengthy. It's

a super popular thread. And so what it's about is, you know, like in a map, you can omit return,

and it'll return the value. And that's sort of a rule. If it's a single line expression,

you can elide the return. That makes code more concise.

And there's now a discussion to make that a general rule, like the last expression will

be taken as the return value. And you're a very passionate Ruby developer as well,

right? Where that is actually normal, right? That's a standard in Ruby, as I understand,

isn't it?

It is. And it's something that... So I am or I was a Ruby developer. And it's something that never

really quite sat right with me in Ruby. I think there are situations where it makes sense. If

you've got one exit from a function, and it's the last line, then that's fine. But in almost

every other situation, I thought that was a negative point of the language, actually. And

I agreed. I thought it was great when Swift added the single line return. So it's...

Where there is nothing else that could be happening other than a return, it's fine. And I

thought that was a reasonable change to the language. But I'm not sure I would want to see it

fall down.

It's an interesting discussion. And I like these threads that are bounced back and forth. And

there's lots of people making great points this way and that way. It's like, I just don't want

to be the person who has to decide this in the end. But I loved reading it and seeing people,

throwing around ideas and explaining why it's a good idea or a bad idea.

And it's sort of a meta discussion about how this is being debated that I wanted to talk a bit

about. I find the quality, the general quality of discussion, the depth and the breadth to be

really, really good. Like in the forums in general, I know people have conflicted thoughts

about the Swift forums. But I, in general, find the discussion is really high quality. And

sometimes it flames up a bit, but I think it's for internet forums, it's actually really good.

One thing I noticed in this thread in particular, and there are threads like this where there's

lots of participation, and that's around topics that are not as technical, right? Whether to

return and how to return in the last expression isn't on the same level as talking about some of

this existential stuff or distributed actors. And that's where you really, I find it impossible to

contribute there because it's so technical. But here, the audience is broader, it's easier to

add thoughts. But even so, it struck me that when the developer experience is brought up in this

context, it's typically brought up by people on behalf of other groups. So it struck me that

it almost always only enters the discussion via representative. The Swift forums are really

technical, and it isn't a fair, unbiased representation of the whole Swift ecosystem

of developers, right? Only the people who are really interested in the language and are typically

quite experienced end up on the Swift forums and then end up entering these discussions, right? So

it's really highly selective towards a more experienced crowd, which then means these,

the opinions only get related. Now, people will say, "Well, I teach Swift, and this is what people

struggle with." But it's not the people themselves who are struggling who actually come to the

forums and say, "Look, this might be problematic." And I think there's a... That is kind of a bit

problematic. I'm sure the people who make the decision will look very carefully at who's making

these points on behalf of others. But I think it's important to understand a single person

raising a concern about a whole group of people, you know, pupils, students, has to be weighed

differently. And there is not going to be a fix, you know, like, it's not going to change overnight,

or maybe even in general, that suddenly, this would be representative to the whole demographics.

But I wonder if it might help if certain topics are perhaps highlighted to be explicitly inviting

people who aren't as experienced to come and look and contribute and give their points of view,

like call out, your opinion is really valuable, because you can't undo your experience, right?

It's really hard sometimes to participate in discussions that shouldn't be about the

most experienced people entering and saying, "Well, I don't have a problem with it, because

I understand Swift, and I've been doing this for two decades." This maybe should be called out

specifically, we're talking about last expression. What do you specifically as a beginner think,

you know, would this confuse you? Would this make it perhaps easier for you to work with Swift?

Yeah, I think I get your point here. And it's a good point. I think,

looping back to what you said at the beginning of your discussion there about the Swift forums

being, I think the Swift forums have improved an enormous amount since they started. When they

started, I was so put off by them, and the kind of the conversations and the attitude of in threads

on them that I completely stopped visiting them for maybe even years. And they have improved

beyond belief since that point. But they are still quite an intimidating place to post.

I certainly feel intimidated before posting anything there. And that stops me from contributing

to everything that I would potentially otherwise contribute to. And I think, even if you were being

requested to, your feedback was being requested, I think it would still be quite an intimidating

place to enter one of those threads, because it's full of, as you say, people who are very

passionate about Swift and who spend a lot of time thinking about language design, which is

not something a novice even considers. Language design is something that by almost by definition,

you only have an opinion on once you know the language.

Yeah, definitely. I get that.

So I think it's, I get your point. And it's a good point. I just don't know. I don't know how

to solve it. I think the Swift forums are still quite intimidating. And I think finding the people

who would have those opinions and would be able to post them, I think would be challenging.

I think that's the point, to try and make it more inviting. I think it's a huge problem for the

forums if someone like you, who's very experienced and a very well respected member in the community,

feels intimidated by the forums for the programming language of that community. I think that's a huge

problem. And I don't want to point, I feel the same. There's topics where I'm not considering

contributing, even if I have a remote thought that might be useful, because this is out of my

league. But I think that's a problem. I think for the forums to be really representative of the

people actually using the language, it is a problem when people are intimidated by the main platform

where discussion is happening. And I think that's why maybe pitches, some pitches, not all of them,

for some pitches, there's just no hope. You need people who are super technical. But I think it

might be worthwhile considering some pitches or evolution proposals to specifically call out,

look, give it a thought if you have thoughts and post them and specifically invite contributions.

Maybe it does nothing, but it can't hurt. I think that's why it can't hurt to call that out and

maybe prod people into applying. And maybe then people could help along a bit by saying like,

applauding people who actually come to the front and post something and encourage them further.

I think that'd be a good thing to happen. - I agree.

- Okay, that was a longer news section than normal.

- Yes, maybe we'll keep the picks to a slightly shorter number of picks today.

I will kick us off. And actually, so my first pick is a double pick and also

related to something that you did on the Swift Package Index a little while ago.

I know that when we were doing the documentation build system and specifically uploading the

documentation to Amazon S3, what we do is we zip the documentation after we build it

and then ship it to S3 and then using a Lambda function on AWS, we unzip it and put it into

the right place on S3 because we found that moving lots of files individually was not practical up to

S3. But I know that over the years since that original system got implemented,

we've had a couple of issues where the zip tool that we used didn't quite do what we wanted to

do. I think there was a bug at one point which caused us to try a different one, which didn't

quite work in the same way. And it seemed like there were a couple of prominent kind of zip

tools, but none of them do exactly what we wanted, or at least we hit some issues with them.

And I noticed as I was looking through all the packages since the beginning of the year,

that there have been two new zip tools added to the Package Index, both of which look to be

completely new, as in not kind of forked from other things or created from other projects.

Although I may be wrong, I'm not an expert in either of them, of course. One of them is called

zip, Simply "zip" by Tomas Franzén, which has been in development for two months. And it can

deal with zip files, both file-based and in memory. You can configure the compression levels.

You've got a Swift API. You've got this kind of fairly nice API into a zip file. And the other

one is called swift-zip-archive from Adam Fowler. And that's been in development for about a month.

So both of them look to be completely new. And if you have hit problems with a zip tool in Swift

before, they might be something that you want to check out. Yeah, I was super excited to see. I

actually hadn't seen the first one you mentioned. I'd seen Adam Fowler's Zip. And I actually have

that on my to-do list because, as you mentioned, we had trouble with Zip. Zip is just fiendishly

annoying and complex and weird, where when you zip stuff, sometimes stuff gets pulled from a tree

and is a flat list of files inside the zip. And then you lose the power. It's super annoying.

So currently, we're actually using two different zippers, one that is zipping, the other is

unzipping because of compatibility issues. It's a nightmare. I really want to try at least Adam's,

and then also perhaps the other, if there's still problems, just to replace that contraption that

we're using right now. I just, yeah, I thought it was, I thought of that issue, obviously,

when I saw both of these. But it's also kind of interesting that both have popped up within a

month of each other. So there was obviously something in the air over the holidays that

made people go, maybe I should write a zip library. A little zip competition going on there.

Exactly. Yeah, exactly. But yeah, something to check out if you have, if you have files to zip

or unzip. My first pick is a package you, I believe, also mentioned in your iOS Dev Weekly

newsletter, and that's Forked by Drew McCormack. And this looks like a really, really nice and

powerful library to handle shared data in a Git-like model. So you have different data sources

and they just think, might have an editing, an app that edits text and you want to have edits

happening independently. And the nice thing about this is you can sort of branch stuff and then have

custom merging strategies per type, per data type. And it allows you to customize that. And there's

a really interesting example in the, I think it's in the Readme, if not the Readme, it's in a

documentation to explain how that can work. So there's an incrementing integer that is used in

two different apps. And the way the merging strategy works, you can easily see how that

could be conflicting, right? They increment, decrement independently, and then they want to

sync and they have different values, right? And it's unclear who should win. Because you make a

mistake if you just let the last win, because any counting that happened on the other side would

then be gobbled up. And the way you can easily fix that and make that really reliably syncing is

that each just takes the delta to its last non-merge state where it branched off, right?

And then you can actually add up the deltas and you get a reliable merge because any action that

happened in between would still be reflected in the total outcome. It would just happen

independently and asynchronously. And if you have a type, a data type that has that

domain knowledge, sort of domain behavior, and you can write a sync merging algorithm like that,

then this is really great because you can create a distributed system that actually

merges reliably without potential conflicts. And you can see how you can even build up larger

types if you can break it down into small components that have all sort of merging

strategies like that, that are actually resolvable. It's not always the case. Sometimes you just can't

resolve and you have to let last change win or whatever it might be. But sometimes your domain

model is like that. You know exactly what the outcome should be and then you have the power

with this tool, with this package to implement it that way. And I found that really interesting.

I hadn't seen anything like it. So the other, we've talked about CRDTs, I think is the

acronym. I don't even remember what the conflict... Conflict Free Resolution something.

But what they try and do is giving you an auto merge. So you don't have to, you have no way of

actually injecting a merging strategy. But from what I've seen is that you will end up with

conflict free merges that are conceptually correct, but give you really weird result,

especially when it's around texts and edited texts, because you get stuff that is correctly

merged. Like in the sense, technically there was no conflict, but the result is kind of garbage

that comes out of it. Not complete garbage, but the edits would conflict in weird ways.

And my understanding is that's actually not resolvable. So in these cases, it really helps

if you have a data type that you fully understand and where you can define emerging strategy that

is actually, that makes sense, not just technically, but also semantically and allows you

to handle edits that happen independently. So if you have need for a shared data model,

I think that's a great package to look at. And I believe it can work on top of iCloud and stuff.

So it's not like it's tied to any sort of persistence strategy or even syncing mechanism.

It really deals with the model layer and you can have the underlying stuff. You just save files,

I think effectively, and handle the merging at an higher layer.

And Drew has been working on this kind of stuff for many, many years now. This has been

a kind of passion of his for a long time. And I think it probably came out of his work on,

I think it's Ensembles, which is the product that he makes, which is an open source, or you can buy

a version of it that gets the source or something like that, which is a synchronization framework

for cloud synchronization of local data. So yeah, this has been on his mind for many, many years.

So it's something that this is not someone who's just had an idea and has started writing stuff.

This is, I would imagine, extremely well researched and based on...

- Well, and Drew's the co-author of Agenda, the calendar note-taking app on Mac OS, iOS.

So he does syncing. His app does syncing. It doesn't come out of nowhere.

- He does syncing, yeah, exactly. Yeah.

My final package for this week is Skin Smoothing Filter by Shima. And this is a package that

effectively takes... So it uses metal and core image, and it takes an image. The example image

in the readme is a picture of a face and kind of shoulders portrait picture. And it smooths the

skin on the person's face. So there's obviously some kind of blurring going on because some bits

of the image are kind of blurry, but it's identified the bits that it needs to keep

in focus, like the eyes and hair and things like that. It doesn't mention the technology it uses

to identify the bits that it doesn't smooth or how it detects the skin that it wants to smooth.

But what it does say is it uses metal, which is the 3D framework underneath the entire iPhone.

This was the replacement for OpenGL. So I'm guessing that's how they're doing the actual

drawing and core image to actually turn it back into an image again. But it doesn't have any

huge detail on how it's doing the job, but it's doing a very good job. You can see the picture

in the readme file for an example. And the lady in the picture has freckles, and those freckles

are effectively smoothed out in the resulting image. So I thought it was not probably something

you're going to use every day, but it was something interesting that I came across as I was

looking through all the packages this month. Right. My second and final pick is called Numerix by

Gavin Wiggins. And that looks like a really great library for linear algebra, like vectors and

matrices. It's using the Accelerate framework under the hood. So that's probably very important

when you do this sort of thing. You know, in general, you typically don't have just one matrix

or small matrix to multiply. You often do this over and over. So you are quite performance,

you have performance concerns. That's probably something you're thinking about. And then

Accelerate framework will give you massive boosts. And I also noticed in the readme,

the package does really nice ASCII art printouts of matrices and vectors. So it lays them out a bit,

which I always find really nice, because you might be debugging that sort of stuff. And what do we

do when we debug? We put print statements in our code and print stuff out. And then it's just

really nice to see it, not just in a long flat list or stuff like that. So I found that really,

really neat about the package to also have that taken care of. So yeah, that's Numerics

with an X at the end by Gavin Wiggins. That's useful to include that information. I

would have searched for the spelling of numerics, regular spelling.

Well, we'll leave it there, then, shall we? So thanks for listening. And we will be back

in a few weeks with another episode. Promise not to leave it as long as we did over the holidays

for the next one. And yeah, we'll see you in a few weeks. See you next time. Bye bye. All right.