Swift Package Indexing

So it's been how long since we made the announcement?

A bit over a week, right?

And the response has been extremely positive.

From what I've seen, I think people are delighted to see that,

first of all, the package index is on a steadier footing when it comes to being around for the long term,

but also that Apple are supporting this project, along with a whole load of other companies.

And I think that's worth just talking about for a second.

They were keen to join that set of sponsors rather than replace them.

them. So our GitHub sponsorship is still really important to us, the sponsorship

of Stream and Emerge tools is really important to us, and of course the

infrastructure sponsorship of Microsoft and Mac Stadium remains completely

integral to how we keep this project running. What we've done is expanded the

amount of companies that are supporting the project rather than replaced

everybody with Apple. Yeah absolutely, feedback has been really great, just

great to have that in place and take some of our concerns away.

When we were planning out the project, we sort of had some early timelines

where we thought, how long can we run this given what support we had at the

time, and it's really a great relief to have this additional support by Apple

to give us that long-term trajectory and giving us the assurance that we can

keep running this site and also growing it.

And that's actually probably something we should also mention.

The site growth just over the last week has been tremendous.

The influx of unique users on the day alone was a record, but also since then,

the levels of unique visitors and page views has been a lot higher than previously.

And that's just really great to see.

And package submissions as well.

Oh yes.

We've woken up lots of people who were sitting on their packages, probably just

waiting to see if we're going to be around or what's the status of that project.

And then they all clicked on that button, just submit their packages.

And it's been absolutely wild.

But seriously, though, I say this to everybody who, whenever I talk about

marketing, you cannot talk about your project enough, like you may get sick

of hearing yourself talk about it, but, but it's impossible to, you know, I

would say that we were running a fairly successful project already, and yet the

number of people who had no idea it existed.

We were both on a Slack where somebody was talking about the announcement and

we were on that thread in the Slack.

And I think there were a couple of people in that thread who didn't know about

packageindex.com before, before this announcement.

Inconceivable.

And also they actually only saw the announcement through that thread in the

Slack, like you can't talk about it enough.

Yeah.

You can't talk about it enough.

Even an official post on swift.org is only part of the story.

And of course it was also nice to see.

It's a nice moment of recognition to have any post on a swift.org.

Have your name against it, but it was nice to see both of our

names up there on the swift.org too.

Yeah, that was really great.

So we asked whether the community had any questions about the

announcement or about the funding.

And we had a few people get in touch with questions.

Actually, mainly the questions come from contributors and people who are quite

close to the project, which of course you would expect.

And so I think we should go through some of these questions.

So the first question is from James Sherlock, who is a regular

contributor to the project.

Thank you, James, for all of your contributions.

Um, his first question is aside from improved financial safety, what else,

if anything, are you hoping to get out of the relationship?

So I think a big part of that is something I just touched upon, it's more visibility and more reach as the place to go for packages.

So as I just mentioned, we already have seen that effect straight away that we got a lot more visibility and I think people like the assurance that we're closely associated with Swift.org and are the place to go for packages.

packages. And it also validates our work. It's just great to see that this is seen,

the project has been seen as a component in the Swift ecosystem. I think that's just great.

It also gives us a line of communication into Apple, which we now have with the Swift team.

And that in itself is very valuable.

The second question is by Marin Todorov. And it is, how did the process happen? Who initiated

it? What was it like?

We talked to Tom Doran years ago now when package collections were being

put into the package manager.

And if you might remember that Swift package index was featured in a WWDC

video, I think in 2021, if I remember rightly, and that was the year

the package collections came out.

And we knew package collections were coming out in the Swift package manager

because that's all open source.

And we launched our support for package collections on day one or around day one.

So we were right there.

What we didn't know of course, was that package collections would

also be supported in Xcode.

I've already gone down a rabbit hole here.

So anyway, so we've been having conversations with Tom around package

collections, but that was nothing to do with funding or anything like that.

But that was the beginning of that relationship where we actually started

to talk to, to Apple.

We then initiated the conversation around funding.

I think it's no secret.

We've written on our blog many times that this project demands much more than

your average open source project, which is just code.

So the fact that there is a website to maintain, the fact that there is an

entire build system on the backend means that as an open source project, it

definitely it requires constant attention and constant maintenance.

Whereas with a code-based open source project, you might be able to

take some time away from it.

That's not something we're able to do.

And so, yeah, we reached out and said, look, we, we wonder if you have any

interest in, in helping support the project.

Yeah.

And maybe we should add it.

It almost felt like we were running into an open door because the feedback we got

is we were aware of what you're doing and really interested in, in having that

discussion.

The other thing I want to say here is that the support that we received from Ted Kremenek and Tom Doran was incredible.

They were nothing but helpful at every stage of the conversation and I want to thank them personally for all of their help to get to the fact that Apple now supports the project.

Yeah. And at every point it was really important or is still is very clear that open source

and the swift aspect of open source and the ecosystem is really important to them. I think

that can't be overstated. And I think that reflects also in this support for the index.

Yeah, that comes across very clearly every time we talked. Back to James Sherlock for

the next question. And in fact, the next several questions are from James. James asks, is the

agreement time-bound or is there some other limit on the agreement? Without

going into specifics, any agreement of this kind would be time-bound. I think

that's very clear that this isn't... Are you trying to tell me Sven that they

haven't promised to support this project until the end of the internet? Well I'm

I'm hoping you tell me about a clause that I didn't see where it says that, but unfortunately I think that's not the case.

No, but it's a good question. It is a good question, but it's clear an agreement like

this has a period, but it also has the opportunity to be renewed and we're not expecting this

to be a short-term relationship.

And the surrounding circumstances change, right? I mean, whenever that comes up for

renewal, that sort of thing, the packet index might have very different usage, for instance,

then require different kind of time investments or hosting investments and that sort of thing.

And that's something you can't lock in at the moment for however many years down the

line.

That's just the nature of things.

You need to keep that in mind when you set this sort of thing up.

All right.

So the next question by James is, this is the first agreement of its kind that I've

seen.

What barriers did you have to break down?

What level in the business did it reach?

Timothy get involved.

Timothy being Tim Cook here.

I can confidently say that Tim Cook was not involved in this.

Although, of course, we have no idea.

I'm pretty sure he was not involved in this.

I would hope Tim Cook was not involved with this.

I'm confident that Tim would value the work that we did

for this fifth ecosystem greatly.

But I am almost certain he was not involved.

So dealing with a company of apple size

naturally a complex process and you can imagine a number of people would be involved in signing

that off. Throughout the process, effectively, our chief weapon was patience because it just

takes very long to have these sorts of discussions.

You're right that patience was definitely needed, but also this project felt important

to Ted and Tom as well. And without them fighting our cause, I think you're right that this

is an unusual agreement for any large company to support an open source

project like this. It's going to be no secret to anyone listening that you need

somebody inside the company who believes in what you're doing and those people in

this instance were Ted and Tom.

The next question by James is, do you think your partnership has opened

doors for other open source projects to achieve similar levels of support?

That's a great question.

And I would say, I hope so.

It's not our place to speak for Apple here, but I think any big company supporting an

open source project that benefits both the project and the company is a wonderful thing

to see.

And I personally hope that all big companies look at what we have arranged here with Apple

and decide that they can do similar things in whatever ecosystem they're working in.

Yeah.

I mean, it's a recurring theme that you see on social networks where open source projects are looking for support and often complaining that it's really hard to keep running.

And often it's just a labor of love that isn't financially viable.

People do it anyway often because they hope for some future support or employment, that sort of thing.

But it is very common for open source projects to be struggling.

And some people succeed, but it's often around the person

and their particular skills that make that succeed

or the avenues they choose to find that support.

So I think there's a problem to be solved.

And I'm not saying that we found that solution,

but it is a path.

And hopefully there are more instances where that works out

because just so much is built on open source and the value of the open source

projects are reaped by these big companies that it feels like it should

be easier for big companies to, to turn that around and also support these

open source projects.

There's been plenty of examples of open source projects that were very

important to very large companies that, that were not being supported in

anywhere near appropriate levels.

like for example there was the log4j

vulnerability that when obviously the

vulnerability is a separate issue and all

projects have vulnerabilities and that

wasn't the problem but what came out of

that was that log4j project was not

receiving enough support and it was at

the heart of every big tech company's

infrastructure. Next question is again by

James. Has Apple applied any restrictions

to what can be done by the Swift

package index or what contributions can be made. Is this the real reason for CLAs,

CLA being contributor license agreements, that we have in place on our GitHub project?

This is a very easy question to answer. In fact, there's a couple of

questions here. The first part, have they applied any restrictions? Absolutely not.

No, nothing changes on the open source side of this project. I don't think that

topic even came up. And then your question about the CLA is also no. So the CLA has happened,

so just to actually give a little bit of background there for people who are not familiar with this,

a good couple of years ago now, we changed the licensing of the package index open source

project. It was originally licensed, I think, as MIT. And I think as with many open source projects,

Not enough thought is given to licensing at the point where you start the project.

Like we definitely knew it was open source.

We'd both liked the MIT license.

I generally, MIT would be my, my, my default license to go to when

I want to open source something.

But actually it didn't fit particularly well with what we were

trying to do with the project.

And when we realized that we needed a little bit more structure

to our open source licensing, I did have a look at what the Swift project used,

But that was only part of the decision to choose Apache 2 and the Apache 2 CLA.

So a CLA is a contributor license agreement.

And really the reason that we put these CLAs in place is that what we wanted to

make sure is that anybody who contributed to the project had the permission

to contribute to the project.

So if you contribute to the Swift package index open source project, your

contributions remain your own.

They are still yours, even with a contributor license agreement.

A lot of people think that contributor license agreements assign the IP of

the contribution to the project.

That's actually not the case.

What they do as I understand, I'm not a lawyer, but as I understand it, the

main thing that they do in this instance is they give us the confidence that you

had the permission to make that contribution.

So for example, if you work for a big company, let's say Google.

I'm not picking Google for any specific reason, but they're just a big, a large

tech company and you use a Google laptop and you're being paid by Google as you

make a contribution to the Swiss package index, the contributor license agreement

is your declaration that you basically didn't do that.

And it makes sure that the IP is clean to go into the project rather than

assigning us the IP, but that was really just part of this project becoming more

serious and part of us putting a few protections in to the project.

And it was nothing to do with Apple.

Nothing to do with them.

Okay.

I think the last question we have is from Joe Heck, who is also

a contributor to the project.

He says, I don't know how much support by Apple intermix is interbound by

the same rules as Apple employees, but I'd love to hear a bit on your opinion

of how the famously closed source only company is growing to embrace more

community and open source aspects of development and how package index fits

into that expansion. I think we've touched on this a couple of times how

very clear it's been in our discussions that the open source aspects are core to

what Apple and Swift.org are doing and I think that's very clearly reflected in

just how many open-source packages Apple have created. If you look at the Swift

package index, there are currently 57 packages by Apple in the index. Apple are the

most prolific open-source Swift package authors according to our tracking. I

think all of this speaks to the strategy and that's actually, if you think about it,

a very familiar strategy by Apple. If you look at built-in apps on the iPhone,

Apple's signature move is to provide the foundation, like weather, notes, reminders,

like foundational features and apps, but then also leave lots of room for third parties

to add on top of that.

And it's very clear that the same is happening here in the open source space, like the very

foundational libraries and services like Swift itself, Swift Package Manager, Neo driving

all of the server-side Swift ecosystem, the package registry,

and the index is sort of naturally falling into this space.

I think this all lines up very, very nicely and very clearly

what the plans are here and what the expansion space really is.

I think that rounds out our questions, doesn't it?

It does.

We are definitely running long today.

I can see by the time on the clock

that we're not going to hit our length target today.

So let's maybe keep the package recommendations a little shorter today.

Do you want to kick us off with your first one?

Yes.

So the first one is called Crayon and it's by David Walter.

And that's a really nice package for dealing with colors and color aspects.

It is very similar in API to the color from SwiftUI and then has extensions on

it, like is dark, is light, contrast.

So you can get contrast values out of it and like a Boolean, whether you have

enough contrast, like for accessibility, that sort of thing, and also gives you

extensions to do color manipulation, like negative, inverted, saturated,

desaturated, that sort of thing.

So that's a really nice package for colors and it's called Crayon by David Walter.

I would love to have this package in CSS.

Darkening and lightening the colors.

You can do it in SAS, which is the pre-process of a CSS, but the way that

we do colors on the package index, we're doing our colors in pure CSS.

And I would love a library like this.

Okay.

My first package this week is a package that is called with, and

it's by Slip Douglas Thompson.

So this package reminded me of a language feature of C#.

I, this has been a very long time since I did any C# development, but I was

at one point a C# developer, and there was a statement in the language called

with, that basically says you can declare a variable and say with this newly

declared variable, do something with it before you complete the initialization

of this object or this variable.

And it's a really nice technique.

And you can do this already in Swift.

You can say let X equals and then open up an inline closure and return

something from that closure and that's your initiated object, but you have

to do that with thing where you do the kind of braces and then the round brackets

at the end to make it into a closure.

And what this does is it's not a with statement like it was in C#, but it's

a with function where you get a closure that you can do something with.

and whatever comes out of that closure gets returned as the value.

And I found that a useful tool 15, 20 years ago in C#,

and I find it a useful tool with inline closures in Swift,

and this just gives a little bit more structure to that.

Yeah, what I really like about that pattern is that it scopes,

like configuration you might have to do on an object,

it really scopes it together and it's easy to see,

and I'll group it together and not have a variable leaking around

that you really just use temporarily to set something up.

- It's not a big library.

In fact, it even describes itself as a micro library.

So it does one thing and that's all it does.

It has documentation, it has a good readme file.

It's been in development for three years

and only has seven stars.

In fact, I'm gonna go right now and give it a star.

- Excellent, live starring.

- Done.

- Excellent.

So my second package is a package you also mentioned on iOS Dev Weekly last week,

but I will say I actually had it in my list before that.

You were using it before it was cool, right?

Exactly.

I'm always on the fence with this sort of stuff.

Everything is about chat GPT and I am ambivalent about that whole AI.

We had an episode where we talked about this a little bit,

but there is clearly something there.

I mean, this is not cryptocurrencies.

I don't want to open up that kind of worms, but there is clearly something there.

There's already use cases that you can see.

I don't think they are the ones that are commonly thrown around.

Well, we're not going to talk about it this week, but we actually have been discussing

whether there is a usage for the chat GPC API within Swift Package Index.

And I'll leave that as a little teaser.

We didn't look for a reason to use chat VPC like a lot of like a lot of projects

are looking for reasons to do it. But actually, there's something that, and like I say, we'll

tease this for a future episode, but there's something that we could legitimately use it for,

and it's already, from our little experimentation with it, it's doing a really good job at what

we wanted it to do. Yeah, and I think that that area is summarization, because that steps around

a lot of the problems with AI. But back to the packages I wanted to recommend, and that's called

DocCGPT, it's by Gonzalo Nunes, and it is a tool to generate documentation for your package.

It's not a library, it's an executable that you run on your package, and it will

stub out documentation on your properties, methods, functions, classes, structs,

everything really. And the really nice thing about that is, and I've tried this with a Swift

package index it does a really good job, an initial pass to give you something

and even if you might have to edit the preamble more, the thing that I can see

this help with is just dealing with the parameters and the return values but a

lot of times when I actually start documenting something and I'm happy to

write that one-liner that explains what this does but I get really annoyed

having to then pick out all the parameters that often have very obvious names already.

So I almost think like, leave me alone, the parameter speaks for itself as does the return.

Well, you just let me write that one line and then be done with it. But you can't really do that.

If you try to document it properly, you can't really leave those blank. And I can see this

being really powerful and giving, at the very least, giving you those stubs. But actually,

I found the one line is to be really good as well. So I think you can get, you can go a really long

way taking the tedium out of documentation and actually allowing to use the edge cases,

the special things about functions that you might actually, that's the strongest reason to document

something. Because it's not the return types or the input and parameter types, because those are

often documented by the Swift language types already.

It's about why you might want to use a function

or why you might not want to use a function.

When is it good or bad?

What are the special things about that?

And I think tools like this free your time

to deal with those kinds of things.

And I think that's where a lot of the power of AI lies,

to take the tedium away.

And I'll get off my soapbox now.

- I agree.

And I also, like you said,

I linked to this in IOSWP. I think this is a great package that will give you a really solid

starting point for documentation and take away some of that tedium. You might ask, what's the

value in documentation that is so obvious that it could be derived? But actually, there is value in

it. My second recommendation this week is TrustKit by, I presume this is a company, Data Theorem.

TrustKit is an open source framework that basically helps you with SSL public key pinning.

This is a technique that prevents man-in-the-middle attacks. You basically verify the identity of the

SSL certificate that you are expecting to be on the server that you're communicating with,

with a network request, and you can guarantee then that you're talking to the correct server

and not somebody pretending to be the server that you think you're talking to.

This has been possible for a long time, and in fact this package has been in development for

eight years. So it's a well-established package and it makes that process of pinning SSL keys

or verifying that you're talking to the right server much easier than it would be. You define

the hashes that you are expecting to find in your info.plist, and then you're given a method to then

basically be able to say, "Verify this." So this is the kind of package that solves a problem

that you might be tempted to skip if you are rushing through to a first release. Whereas

you might think, "Well, yes, I know I should pin my SSL certificates, but I'll do that later."

Here's a package that makes it relatively trivial to do that.

Well, you had me at "makes it easier to work with SSL"

because that always gives me nightmares.

My third and last pick is called Polykit by Anton Hestand.

And that package is very easy to talk about

because what it does, it gives you rounded polygons in SwiftUI.

Just look at the readme, it draws out a few shapes and it's really nice.

You get rounded triangles, squares, that sort of thing, hexagons.

Very easy to use, very painless, and it saves you from a lot of pixel math,

and it looks really nice.

- That is an extremely targeted package,

but I can't imagine an easier way to make that kind of shape.

- That's great.

All right, that's Polykit by Anton Hestand.

- I know we said that we were only going to do a couple each,

but my last one for this week is nothing more than a comical package name, so I'm going to sneak it in.

My last package for this week is a package called Mork & Middy,

which, if you have any recollection of the 70s TV show Mork & Mindy, Brad Howes, who is the author

of this package, has obviously got a fondness for that TV show and called his Middy library

Mork & Middy. And I'm not even going to tell you what it does. If you're interested in Middy,

Go and have a look at it, but we'll leave it there because we are trying to keep today's episode

under an hour. So with that, I think we should wrap it up. Thanks so much to everyone who submitted

questions for the opening section of today's episode. And thank you so much for all of our

supporters, including Apple, for making what we do here possible. Yeah, absolutely. Thanks everyone,

and see you next time. Bye bye. See you next time. All right, bye bye.