Join us for our first episode in 2025 with news of a community Swift on Android working group, the announcement of swift-build at FOSDEM, a discussion of making open source funding easier, how to get feedback on Swift Evolution proposals from people outside the Swift forums, and of course our usual package picks!
News
News
- Swift on Android Working Group
- The Next Chapter in Swift Build Technologies
- Open Source Swift fundraising
- swift.algora.io
- Pitch: Last expression as return value
Packages
Creators & Guests
What is Swift Package Indexing?
Join Dave and Sven, the creators of the Swift Package Index open-source project, as they talk about progress on the project and discuss a new set of community package recommendations every episode.
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.