Subscribe
Share
Share
Embed
Interview with Orta Therox
Packages
- swift-configuration by Apple
- swift-configs by Daniil Voidilov
- RevenueCat by RevenueCat
- monocle by Dennis Müller
- SwiftForSwifts by Swift for Swifts
Creators and 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.
So it's been a little while since we've actually done an episode, right Sven?
It's been a little bit of a...
It's been a minute.
A little bit of a break in the system.
I've been away on holiday, just got back, and we've been fairly busy with other things.
So we're on a...
This is the end of a little bit of a hiatus on the podcast.
Yeah.
So, and as you maybe have heard then, we have a new voice on the podcast this episode.
We have a guest on this week's episode, Orta Thurrox, who I'm sure needs no introduction,
but just in case, would you like to introduce yourself, Orta?
Yeah, I guess I was sort of there at the beginning of the iOS community, I guess, and sort of
built out a lot of the foundational ideas and sort of hung out with a lot of people
trying to do odd things and share code of each other.
So people might know me from CocoaPods or from Danger, at least in this space.
I guess we were some of the first people to experiment trying to build production apps
with Swift.
So like Swift version one and two.
And we did some pretty intense write-ups on how to do that.
And I helped make it possible for getting Swift to run in CocoaPods at all, which was
quite a lot of work.
I mean, I think it really was a...
It was a time when lots of problems needed solving, right?
It was like a period where lots of...
When Apple were not providing many solutions for community style problems.
And so it usually required someone to step up and to do the work themselves because they
were still like a very...
They were still trying to figure out the iOS SDK, I think, in my head.
Whereas we were like, "I just want to share grabbing an image and putting it onto a flat
surface somewhere."
Right.
Yeah.
Well, it was...
I mean, CocoaPods, especially, but also Danger, have both been incredibly influential tools
in iOS development and macOS development over the years.
And we are going to talk about those more, but I'd also be interested in a quick update
on what you're up to these days.
I know I'm going to preempt you slightly.
I know what it is because I'm a big fan.
I play Puzmo regularly, especially I like the crossword, which is the first crossword
that I've ever stuck with.
I've tried many crossword providers over the years and never really stuck with one.
And Puzmo has grabbed me, which is great.
I guess a TL;DR of my career is that I ran a mobile team doing iOS native, and we concluded
that the set of abstractions that were provided by Apple were not probably optimal for the
type of clients we were making.
So we switched to React Native, and that just led me down into this JavaScript massive ecosystem,
semi hellhole.
And just before you carry on, just give people a quick rundown of what Puzmo is.
Sure.
Oh yeah.
Puzmo itself.
Yeah, I was going to get to that.
Sorry.
Yeah.
But Puzmo itself is like a daily games platform.
For a lot of people, that would just be, you'll have seen something like the New York Times
games with crosswords and Wordle and things like that.
We do that same type of thing.
We're probably the biggest competitor to them at this point.
And we have like a native app and lots of cool, interesting games that we build ourselves.
That's great.
Are you aware of Puzmo, Sven?
I am.
I followed it.
I saw it come out, but I'm not really a puzzle gamer.
This episode is fantastic because I don't have imposter syndrome.
I'm straight up imposter because the last time I've actually used CocoaPods in earnest
is more than 10 years ago.
And even then it was tangential.
I didn't set it up.
I just kind of used it as part of the team.
So I'm out of my depth today, but I'm going to have fun listening in mostly, I guess.
That sounds really cool because it gives you a good insight that I think more and more
people will have, which is that this is a tool that existed that has been around, but
you don't necessarily need it.
And so they don't actually know why it's a big deal that it's being deprecated and all
these sort of things.
Yeah.
Well, I guess it's also testament to the tool in that I, at the time, I didn't have to set
it up.
I knew the basic commands I needed to run to update things.
And then it wasn't really in the way.
It was just there and did its job.
That's actually the best thing you can say about the tool, right?
Yeah.
I mean, it is.
At one point it was absolutely ubiquitous.
But you're right that over the years since Swift Package Manager became a viable tool
for building iOS and Mac apps, it has certainly become less ubiquitous.
But it is a big deal that we're going to talk about today with it going into kind of maintenance
mode because these tools live forever.
Because unless there is a really good reason to switch, the things that are working tend
to stay working and tend to just persist by default, don't they?
It's like a build is fine.
You know, if it continues to work, it's just a dependency.
And for some people, they might even put their dependencies in their repo.
And so you might not even ever use CocoaPods to actually do the updates anyway.
That reminds me of a big, well not controversy, but a big talking point when CocoaPods was
at its height was, do you commit your dependency sources or not?
And at the time I was very much on the side of you should commit every source file that
you need to build your application because there's no guarantee that it will be there
in the future if you need to rebuild.
But actually with Swift Package Manager, making that probably a little bit more difficult
than it was with CocoaPods.
I certainly don't do that anymore and I don't think many people do, but that problem still
exists.
Like you may have a project that you can never build again because that dependency source
may have gone away.
Yeah, especially if it's distributed like CocoaPods and SPMR.
There's no VC backed company or megacorp holding all your source code in a single place because
it allows for many.
Unless you count GitHub as that VC backed megacorp.
Does SPM only support Git repos now?
Swift Package Manager, well no, Swift Package Manager has full support for the registry
specification that was defined and that works.
And you can, there are multiple registries out there.
You can do your own private registries if you want with various companies.
JFrog, I think has one and I think Amazon has one as well.
And there's also a mirror of all the packages in the Swift Package Index that's run by the
Tuist folks who they run a registry that vends any package that's in the Swift Package Index.
Well, also you don't even need a registry, just a different Git URL would work.
So you're not tied to the GitHub Git based URLs.
It could be GitLab or anything else.
So in that sense, it's, you know, even without a registry, it is fully distributed.
But we've kind of skirted around the main issue and I did mention it, but let's get
to the meat of what we're about to talk about here, which is that CocoaPods, the CocoaPods
team and Orta specifically have been posting for the last year and a bit on the CocoaPods
blog about the fact that CocoaPods is going to enter maintenance mode shortly.
So do you want to give us a quick rundown of what that means and what people need to
be thinking about if they're still using it?
Yeah.
So I guess one way to think about it is, you know, CocoaPods, I think this was the first
year where we didn't release an update to CocoaPods when there was an update to Xcode.
Right.
I don't think anything broke, which is actually kind of a really good news for the idea of
sort of moving it towards a much more like it through maintenance mode version of the
project.
But generally speaking, you know, CocoaPods is a dependency manager and those dependencies,
they are distributed in a similar way that you have the Swift package index.
We have something called the CocoaPods trunk and the CocoaPods trunk is sort of like an
authentication process that gives us the ability to say, hey, this person owns this exact name.
Because CocoaPods was like before the era of let's just rely entirely on GitHub for
all our dependency managers.
I think it still has support for subversion and things like that inside it.
Really, right?
Yeah.
And it's got like, we made it so that there was a single namespace basically.
So you know, there would be the pod a la stack view, so auto stack view.
And that wouldn't be like, you have to go find this repo with that one.
It would be straight up like you have to go to a central index.
It will tell you when you from that index where you can go and find the Git repo.
And so that central piece of technology is sort of both the biggest, the bit that makes
a lot of the system easy to use, but at the same time, it's the bit of the system that
has the highest attack surface for people that want to sort of do security research
and do like black hat hacking.
Because there's a huge amount of work going on in that space at the moment to try and
find out what are the holes in the sort of dependency tree for people.
Because if you can get some code, sneakily shipped into an iOS app that's used by millions
of people, you could get that there's a lot of value in that in terms of like selling
that exploit to people.
Yes.
And this has happened in many ways over the years.
Not not has it ever happened through CocoaPods?
I know it's happened through compromised versions of Xcode.
Yeah, compromised versions of Xcode is what killed Xcode plugins back in the day.
Yeah, I would say no one has ever done it through CocoaPods, especially not at scale,
right?
You can't build up a CocoaPod pretending to be another one.
So like Alamo Fire is pretty famous.
And so you could make Alamo Fire where the I is an L and you can persuade people that
like that is the real one.
But that's not like a scale attack.
But the most we've ever had has been like security researchers after finding an effective
bug going in and making like post install scripts on existing pods to be like, so they
can count how many people are vulnerable to the exploit they just found, which is which
was very worrying the two times that this happened and is now impossible to happen.
But right, those are the only things that have really ever happened with CocoaPods at
scale.
And so would you say that that is was the primary driver to making the transition into
maintenance mode that as the project became less, I'm putting words in your mouth here,
as the project became less used, and therefore less maintained and less updated, that there
were less eyes on it?
And is that what drove the decision?
Yeah, in part, like I'm a bit tired of dealing with the security researchers.
I got one yesterday, for example, there was like a real I'd say it's a real it's a real
possible vulnerability.
And there's lots of people that are very financially incentivized to find these holes.
Yes.
And so, you know, we have to come out, I have to go through the full security like process.
And that usually takes a day or two of my of my time.
And then we do a fix as well.
And then if it's something that I would consider like, very bad, then I would do a write up
and do all the work.
And we had a few of those in the last two years.
And they just have not feeling great about all of it.
And then one of the other engineers that contributes a lot was like, maybe an answer is not to
shut down, but to go read only.
Right.
Which I thought was like a really elegant solution to the problem of like, we don't
want to necessarily even have the access to be able to say, hey, you are his, you have
access to upload the Facebook SDK, which I'm sure is used massively.
And so if we can get to a point where they are self hosting, because they have their
own incentives to go to Swift Package Manager over the time, then that's probably the right
pattern for us.
And it's a very thankless task to be the person who has to deal with those security problems
and maintenance issues.
And I know that I have been incredibly grateful over the years for all of the work that the
entire team has put in.
And actually, we got a couple of thank yous off, we posted yesterday on social media for
questions and stuff.
And several people said, thank you for all of your work, not just yours, but the whole
team's work over the years.
But actually, I think it is fair to call you out specifically, because you have taken that
responsibility for those security issues going forward.
And I think everybody who's been involved, you know, this project has been a wonderful,
positive influence on the iOS and macOS development community over the years.
And I certainly would love to say, you know, thank you publicly to all of you for that
work.
You know, it's amazing.
Thank you.
It's interesting, because you come from an iOS/macOS background.
And so, and obviously are deeply involved in the Swift Package Manager community.
But like, Cocoapods is getting more downloads now than it ever has by far.
It's like significantly bigger than it previously was.
That was going to be a question I was going to ask later.
But that is fascinating.
Can you quantify that at all?
Yeah, I mean, I did once.
I use a website called Ruby Toolbox to generally get a general sense of where everything is
going in terms of dependency-wise.
So there we go.
It's loading up.
But yeah, and it's still getting, you know, back when we all thought that Cocoapods was
effectively dead, which I guess would have been maybe 2020, it sort of doubled in traffic
since then, for example.
And I put that towards a very simple one, which is that like Flutter and React Native
are very, very big ecosystems.
Yeah.
Well, that's interesting.
You mentioned React Native, because one of the questions we had on social media was from
John Stube.
And his question was, what's the impact on React Native with this news?
Will React Native going to finally switch over to SPM?
And I know you probably can't answer that question, but do you have any opinion on that?
Yeah, I can read the pull requests.
They know to DM me because I helped build the Cocoapods integration that is in React
Native today.
Right, right.
So generally, yes, people are working on it.
And we gave a two year, like, here's our deprecation route.
But at heart, the interesting thing about something like React Native and Flutter are
that you don't necessarily use Cocoapods as your main dependency manager.
You would use like, I don't know what they use in Flutter, but, you know, NPM is the
big one in the React Native world.
And so people aren't actually using the Cocoapods trunk to get these dependencies.
These dependencies are coming in through their node modules.
So like an NPM dependency they've got that includes the Cocoapods pod spec.
And so it's sort of like they're actually vending their own dependencies in a different
dependency manager.
And it may well be that like, when we turn it to be read-only, that it actually doesn't
affect them at all because they're not using Cocoapods to vend their dependencies.
Do you get what I mean?
Let's elaborate on that a little bit.
I am a React Native project user and I have a dependency that's called React Native Navigation,
right?
It's like something that wraps a UI navigation controller and gives you like some infrastructure
for doing that in JavaScript.
Okay.
If I include that dependency in my NPM project, right, which is a separate dependency manager,
it's going to put a file in a folder that's called React Native Navigation.
And the Cocoapods integration for React Native will look inside the NPM folder first.
So you will not go into like a pod file.
In fact, I don't know if by default it even ships with a pod file.
It's sort of one that auto-generate is generated for you.
Interesting.
And so you're not actually asking for the original things from the Cocoapods registry.
You're just using the ones that have come in from your existing dependencies.
That's really interesting.
So eventually the impact on React Native may not be what people are expecting.
I would expect so.
I'm sure there's edge cases because there always will be.
Of course, there's always edge cases.
Yeah.
Yep.
What does Cocoapods actually do in that case for React Native?
Is it sort of just to bootstrap and very rarely update it in case something at the top level
changes or what's the point of all this then?
Well, React Native, the team aren't that interested in building out all of the Xcode level integration
stuff.
So they want to be operating in JavaScript ecosystem and the same with the Flutter.
So when you want a new library, then because it's all Ruby and very dynamic, then it can
just look up the folder file system to see if there's any pod specs and then say, "Hey,
that's one that should be defined in the pod file."
Right.
So it's really a scaffolding tool rather than a dependency manager and that they just
sort of piggybacking onto the setup procedure and the discovery paths within the project
rather than managing actual dependencies.
Is that about right?
To some extent.
I think that's close enough to be accurate, but it's also that sometimes those dependencies
have dependencies, you know?
And now suddenly you're having CocoaPods do the native dependencies and in the way that
they might have Gradle do the native dependencies for Android too.
Right.
It's complicated, but these projects are really complicated at heart because they're trying
to do something strange.
Yeah.
Well, I think that's a good chance to talk about another kind of huge question with this
is are there cases that you're aware of where people, and I'm guessing this is going to
be large companies, are unable to move away from CocoaPods?
I'm sure you've heard stories over the years.
Are those stories still coming in or are you expecting a kind of a quiet transition?
So far on every blog post I have wrote, if you have problems with these timelines and
things like that, then you're welcome to contact us.
And I've not had a single contact.
So I'm assuming right now everybody, I mean, two years is such a long time.
You read a blog post and you're like, "Oh, we've got forever."
Sure.
We're at one year now.
And then suddenly it's tomorrow, right?
Yeah.
So there's a chance that next year, sometime around November, like our plan is that sometime
in November next year, trying to avoid that American holiday, Thanksgiving, we're going
to do like a short term brownout, so make it for a week.
You'll probably get a few emails that week.
And then that gives you a month afterwards of finding out that you can't upload to CocoaPods
that maybe you're going to have to make sure that that's okay in the next month.
Yeah, I mean, I think one of the things that I've really admired about the process of this
is how much notice you've given people that this is happening and how open you are to
hearing about the problems that may be caused.
And I'm happy to hear that you have not been swamped with emails and requests so far.
And I think, I mean, it's been a long time.
I know there are always edge cases, but it's been a long time, right?
Yeah.
So when I wrote that blog post about like us starting to do the support and maintenance
plans, so that's like 2024, SPM had been around for nine years.
Although not usable in iOS projects for nine years.
Absolutely.
I think in my head, it took three or four years to start being maybe more, just not
being super useful.
But, you know, for CocoaPods, from CocoaPods' perspective, the day that came out was like
the end of the value of working on CocoaPods, generally speaking.
Sure.
And I think actually that was quite a harmful thing to the community that happened, that
SPM came out and that definitely made a line in the sand of like, okay, Apple are doing
dependency management.
This is Swift dependency management.
This is going to be the standard and blah, blah, blah.
And then it wasn't actually usable in iOS and macOS projects for years afterwards.
And I think that I won't try to speak for the Swift team, but I would imagine they have
some regrets around how that happened.
Yeah.
It's one of those tricky problems, right?
Because they had to release a build for Linux as Swift, otherwise they were just like releasing
another Apple language and the rest of the world was not going to take much attention.
And so they needed something.
Yes.
But like framing it as the package manager may indeed have really shot them in the foot
for a little bit.
A little bit being it was quite a while.
Yeah.
Yeah.
I mean, these decisions are never simple.
There's always more to it than is on the surface.
But yes, it was a slightly messy time for how is dependency management going to look
on for Swift around that time.
And I can see that as somebody who, well, the whole team has probably felt the same
way, is, well, why are we putting all of our time and effort into this project when it's
going to be deprecated at some point?
I used to frame my work on CocoaPods as being like, it's like a tentpole project for the
community.
Like any work you do raises the tent and makes everything a little bit bigger for everybody
to be able to do cool stuff on.
And then slowly it just started to not be as valuable.
And also like CocoaPods is built in a different technology stack than the majority of the
work you do on your iOS work.
And I think what we found is the people that started working on CocoaPods stopped building
iOS apps quite quickly because of the skills that they got doing this ended up being really
interesting.
And off they went into the Ruby world.
Yes, exactly.
Yeah.
Yeah.
I can, I can certainly see that.
Yeah.
This would all have been different if there was a Ruby SDK to build iOS apps, I suppose.
Which I think there was, wasn't there a MacOS thing?
There was, yeah, there was.
Yeah.
RubyMotion.
That's what it was called.
Yeah.
Yeah.
There was a Python one as well, right?
Oh, there was an official one.
Ruby Cocoa was built into the Mac.
That was, that was one of the originals.
That was my first job.
My first programming job.
How was it?
Was it really?
Tell us about your first programming job then.
I went and moved out to Brazil and did a sort of, worked on a blogging client that was like,
you know, it supported Tumblr, it supported WordPress.
And the guy that did it was like a Ruby fanaticist and would refuse to do anything else.
So he was like, we are going to figure out how to make this work.
And it was good, but it was not good enough to be fully production worthy.
Which is why RubyMotion ended up coming out of, like the guy that wrote that in Apple,
eventually Laurent Sansonetti, he moved out of Apple and turned it into a startup.
That was RubyMotion, the one that everybody had heard of.
And that was RubyMotion, of course it was.
Yes.
I remember that Laurent used to work for Apple, but I'd forgotten that he'd come away and
tried to do that as a startup.
Yeah.
Is it still going?
I presume it's not.
It's not.
It's not NVIDIA now, but Alloy is like the original creator of CocoaPods.
I'm just the guy that came like a few months down the line and said, this is a good idea.
He worked on RubyMotion.
So he ended up like, ended up back in this world of like runtime engine stuff before
eventually coming to work with me at Artsy.
Right.
Okay.
Right.
There you go.
Small world.
It is.
And certainly it was a very close knit community of the CocoaPods people, wasn't it?
We don't like, you know, you get to a point and people invite you to conferences and then
you go to the conference and you meet all the other people that are working on it because
there's always something interesting in that space.
So we had a couple more questions off the social media posts, which we should probably
get to.
One from Kali Coding said, there are other tools, for example, Fastlane that rely on
the Xcode project gem from CocoaPods, but this gem has not kept up to date with the
latest Xcode project file changes.
Specifically, it doesn't support buildable folders.
Is this gem also being put into maintenance mode and will that also carry over to Fastlane?
Now, I appreciate you're not the maintainer of Fastlane.
We should maybe get Josh on to answer that question.
But I wondered if you had any thoughts on that.
I think I honestly never considered it until this just came up.
But like, it's not mine to give away, but it's also like, yeah, I don't see a reason
why we couldn't just decouple it from the CocoaPods infrastructure and make it available
for people.
It in itself has value.
And of course that gem can still be maintained under, or is that gem also going to be made
archived?
Is that going to be, is there a plan to archive that gem?
The only plan officially is to make trunk read only.
But the reality I think of the situation is Xcode project is used in more than just CocoaPods.
And so I think it is more valid to move it to be able to be supported by a team that
would actually support it.
Well, Josh, if you're listening, drop us an email and we'll, I mean, I'm sure you and
Josh have talked many, many times over the years, right?
Yeah, yeah, yeah.
Josh is part of why I'm recommending my Swift package later on down the line.
Teases for later.
Don't spoil it.
Another question here from Alexander Steiner.
Is there anything you would have done differently in hindsight?
That's a great question.
This is interesting.
Like, because there's tons of things that I think that is fun to do on a community of
the size that we have for CocoaPods.
Like I used to spend a lot of time building really interesting statistics and try and
like generate all this.
We have like interesting analytics that were like unique within dependency managers because
we weren't just relying on whether it was, you know, seen or dependent on what its dependencies
were.
I've been really interested in like, I think there's something really cool about having
a small set of dependencies and having authors be able to say like, I trust this person and
being able to make web of trust around dependencies.
So it'd be like, I trust Dave Verwer.
Dave Verwer has said that he has read the software Llama Fire.
Yeah, yeah, exactly.
I get to choose to make those mistakes.
And that's kind of fun.
I'd love to see like a web of trust system built on top of CocoaPods' dependencies.
And I would have loved to have the technology I have today to be able to like redo a lot
of the analytics pipelines and things like that.
Back then it was like unbearably expensive to be able to generate analytics for people
on their pods.
But today I have a self-hosted system that uses Clickhouse that is honestly, you know,
the same quality as the one that I had for CocoaPods for a while that cost a thousand
dollars a month.
And so some of that stuff I would have loved to do.
But you know, for me, I'm super proud of the design work I did on CocoaPods.
That's like some of my favorite stuff.
And just like committing to something for such a long time.
It's like, it's hard.
It's been a decade or two, but it's been fun.
Well certainly many aspects of CocoaPods were inspiration for what we built with the Swift
Package Index, especially my favorite little bit of CocoaPods that shut down a long time
before CocoaPods itself is going to transition to maintenance mode, but was CocoaDocs, which
was the documentation hosting for, I think you used, what's the tool called?
Beans with a J. Jazzy, Jazzy.
I wanted to say Jazzy, but it's Jazzy.
Oh, what was the original one?
Well, Jazzy didn't support Objective-C projects.
So I first built it with an Objective-C version of that.
Oh, there you go.
But yeah, I agree.
No one else was attacking those types of problems.
You need a centralized system to do that.
Yeah.
And yeah, so what we've built with Package Index having documentation hosting and what
we consider very easy to enable documentation hosting, you just put a little configuration
file in your project and we'll take care of everything else.
That kind of problem is only possible when you've built the underlying infrastructure.
In CocoaPods case, it was CocoaPods itself and in Swift Package Index, it was the index.
And actually it's more than that.
It's the index plus the build system because with DocC, you can't build the documentation
until you've built the package.
And so we were able to kind of tack that on with less work than it would have been if
we hadn't had that build system.
So CocoaPods has been hugely influential in what we've built with Package Index.
So again, thank you for that.
Yeah, it's cool to see people trying new things from the same ideas.
Yeah, yeah, absolutely.
In terms of other open source projects, are there any precedents for a project going read-only
like this or kind of transitioning into a maintenance mode like this that you can talk
about?
Not to my knowledge.
We spent some time trying to research this to see if there is good examples of people
trying to move off dependency managers.
And honestly, I couldn't find much.
And that has made it kind of interesting.
There's like discords where people that run dependency managers hang out.
And there's also, we talked a little bit, I think with the Linux Foundation about what
they've ever done in this space.
But realistically, it's relatively unprecedented to turn a dependency manager read-only.
And so it's funny to just be just doing it and just seeing where it goes step by step.
But that's kind of why we gave it such a long process because if it takes two years, that's
fine.
Then someone might tell us where the problem is on route.
But for now, it just seems to be that we're sort of operating in a new space.
It's kind of surprising.
There's so many projects out there.
Do they just shut down?
Well, I think a lot of them do actually.
I think a lot of open source projects, when the maintainers move on, they actually don't
even shut down.
They just get abandoned.
Yeah.
Yeah.
You're giving a lot of grace period there.
I was wondering, is there anything you can think of or you might have thought of that
might block people from moving off of CocoaPods to SwiftPM?
Are there any features that are missing and that are hard to sort of replace?
The hard part, and again, I don't know all of the modern features of Swift Package Manager,
but it definitely used to be a case where adopting Swift Package Manager for a library
like OpenCV was just kind of not really feasible because it required changing that file structure
to fit and to be usable in a way where Xcode was a priority of the build system.
And so you do, I think, have quite a few of these crazy C libraries that people use that
may or may not be possible to migrate over.
I'm not entirely sure.
We were very build flexible.
Right.
So I don't have an answer for those.
At the same time, if you were vending it, you may have the technical experience to be
able to put it in your Xcode project, like natively.
Maybe you're not updating so often.
Right.
That's my guess, but no one has said anything.
Right.
Right.
And what happens after the maintenance period?
Is that the end?
Is that the end of it?
I think we've been on such like a, again, because there was no releases this year.
I think we're definitely at a point where people are not fully operating the machine.
So I don't know.
By removing the authentication and moving to be read-only, we effectively allow the
key server to sort of, it doesn't need to turn off because it only costs a 10 or a month
to operate.
But I think trying to figure out, do we do updates to the CLI client to be like, you
have touched a pod that came from KUKA.PODS's trunk.
This will never get an update.
Are you sure you want to do this?
Yeah.
Is probably something we're not going to do.
I think that would be a good idea.
Yeah.
Yeah.
I think that would be a good idea.
Just so that those people see it every time they update.
Yeah, exactly.
And it might not be that often, but some people might be using a dependency that was built
10 years ago and has never updated since.
And it was probably just fine.
I think that's the only situation that is going to be a problem.
And it's not really going to be a problem because it is just the passage of time is
that there are a lot of iOS and macOS projects that were built at a point in time and haven't
been touched since.
And resurrecting those projects will become even harder.
But honestly, resurrecting those projects is already an enormous task because the APIs
have changed so much.
The tooling has changed so much.
The Swift has changed so much.
You know, it's more than a few years old.
It's not going to compile.
Well, if it's Objective-C, I mean, it'll compile, but maybe people are replacing that stuff
anyway.
And those won't see any changes probably either.
So that'll just age out, I suppose.
Yeah.
Yeah.
That's our theory that like, you know, people that are using building Swift projects at
this point will probably have moved to Swift Package Manager.
People that don't control their projects like React Native or Flutter are at a point where
eventually there'll be a point release in their Flutter or React Native that switches
fully over to Swift Package Manager.
But most of the time their dependencies are not coming through CocoaPods.
And anybody with an old build still works perfectly fine because the same pods are going
to be there.
There just won't be updates to new ones.
That's right.
Yeah.
The tooling still runs.
The pods still exist.
The GitHub repository is still there.
Yeah, absolutely.
Yeah.
It's good.
I hope and predict a smooth transition.
Well, I've gained enough internet credit over these years to take a few flames if we need
to.
Yes, you have.
Well, I hope you don't need to.
And I hope nobody does that because it is not deserved.
Well, that's been very interesting.
And thank you so much for coming on the podcast to talk about that.
But before we finish, let's do some package picks, shall we?
Shall I start?
Sven, why don't you kick us off?
All right, I can do that.
My pick this week or this time is Swift Configuration, a package by Apple that I believe was just
announced this week or last week with the 1.0 release.
So it's very fresh.
And this package is about app configuration in terms of configuration files, environment
variables, command line arguments.
So there's lots of ways you can get configuration into your app.
It supports hierarchy.
So you can have overrides, like for instance, typically command line arguments would override
file-based configuration, that sort of thing.
Yeah, 1.0 came out.
It supports these things I mentioned.
Also, it redacts.
You can declare a configuration value as secret.
So it'll be redacted from logs automatically, which is very nice.
I also want to mention another package while I mention this one.
And that is called Swift Configs by Danil Voidilov.
And that is slightly older.
So he published that four months ago.
Danil is two months old.
So he was with Sherlock within two months of starting his package.
I actually have to say I like the API in Danil's package a bit better than Apple's.
There are trade-offs here because Apple's package has a couple more features like the
overrides.
But, you know, pick the one that you prefer.
If you don't need the overrides, Danil's package might be the way to go with.
And both packages will surely do the job if you need to configure your app.
So there you go.
That's Swift Configuration by Apple and Swift Configs by Danil Voidilov.
Interesting.
Sherlock's after two months is certainly a prize of sorts.
Congratulations on winning that competition.
Otto, do you want to give us your pick?
So I have Danger in Swift is a Swift package manager package.
So I guess to some extent that is one of them.
But I only use one Swift package in Pusmo's iOS app, and that is RevenueCat.
I've been really happy with that.
So I just vendor the entire thing, put it inside the source code, and they make my life
quite a lot easier considering how much work I had to do to do the web version of RevenueCat.
Well, that was going to be my next question.
Do you use their web?
Because they have a web SDK as well, right?
They do.
Yeah, you can hook it into like Stripe and stuff like that.
But I had already built all that stuff by hand.
You'd already built that, right.
Like giving them extra revenue from going back and undoing all that work, and this wasn't
worth it for me.
Oh, if it's already done, absolutely.
Yeah.
Yeah.
And so, yeah, just one Swift package, that's some kind of record.
Although I presume many, many JavaScript dependencies as well, right?
Oh, you don't want to know.
You do not want to know.
Does JavaScript encourage lots of dependency?
I had no idea.
Imagine.
Well, thank you for the pick.
And certainly, it's a popular pick.
I'm not sure if it's ever been recommended on here before, Sven.
Do you recollect?
Possibly, but it's been a while, if it has been.
So yeah.
Yeah, yeah, yeah.
It's a good one.
My first package this week is called Monocle by Dennis Muller.
And it is a Swift symbol lookup CLI powered by SourceKit LSP tuned for coding agents.
And so it's a command line tool where you can, for example, ask Monocle, this tool,
to inspect a specific file at a specific line, even a specific column in that line.
And it will describe what it's seeing at that position.
You can have it output in human readable output or in JSON.
And what you can do is you can tell if you're using something like Cloud Code or any of
the agents, you can, in your agents.markdown file, you can give instructions to the agent
on how to use Monocle.
So for example, they actually give you a little snippet here that you can say, treat the Monocle
CLI as your default tool for Swift symbol information.
If you need definition file signature parameters or document comments for any Swift symbol,
run this tool.
And on it goes, you know, list checked out Swift dependencies, resolve any symbol at
a specific location.
And so it gives the agent the knowledge of how to properly inspect Swift symbols inside
your project.
And I thought it was a really interesting little tool.
It's also got a server mode where you can keep the LSP server running constantly so
that calls to the Monocle tool are really quick because it's already booted up that
whole infrastructure of LSP.
And I thought it was a very, very interesting tool and a fantastic readme file.
Looks really easy to get started with.
So yeah, it looked great.
Well I think, are there any other package picks?
Not for me, no.
Well, I just have one, one lightweight one at the end then, which is a package called
Swift for Swifts.
It's by Rob Whittaker and it actually goes along with a website and the website is swiftforswifts.org.
And it is a project to help save the humble Swift bird, not the language, the bird.
It is a project which is, the package can add a link to the website and a little badge
into your about screen or wherever you want in your application.
And what they're doing is they're trying to save the Swift.
Yeah, in the UK, numbers of Swifts have plummeted by 66% in the past 30 years and the species
is globally threatened.
So it would be a terrible shame if the birds with which our favorite language is named
after were to become endangered.
And so it's great to see this project, great to see Rob take this initiative and get this
up and running.
And even if you don't integrate the package into your application, check out the website
and get involved with what they're doing there.
Save the Swifts.
Swift for Swifts.org.
And we'll include links to that in the show notes and also various links to the Cocoa
Pods announcements if you need the kind of official timeline.
Just so that we actually do mention the date, what's the date of the maintenance switchover?
December of next year.
That's the final turn off.
So a year.
And then there was a kind of a test in November, right?
Yeah, that's my plan.
Yeah, wonderful.
All right.
Well, thank you so much for your time, Orta, for coming on and talking all about this.
And thank you so much as well.
Not just to you, but to the whole team and whoever contributed to Cocoa Pods over the
years.
It was an incredible tool that revolutionized iOS development.
It really did.
Yeah, I agree.
It was fun.
I'm glad it's had its time.
Thank you, Orta.
All right.
And we'll be back in a few weeks.
So we'll speak to you then.
All right.
See you next time.
Thank you for having me.
All right.
Take care.
Bye bye.
Bye bye.