Recorded – watch the full episode on YouTube.
What is your experience of using Swift Package Manager, and how does it compare to CocoaPods and Carthage?
Ellen Shapiro: I really enjoy using SPM to make little utilities. One thing that I've done through Apollo is that we had a lot of stuff that was being done in a Bash script. I am really bad at Bash, just really horrendously bad at Bash, and the documentation is not ideal. And so it's something where I sort of realized I want to take these other things that I'm working with, and I want to be able to just access them using the language that I already know works on anything that will be used to build iOS tools. And I just want to be able to write “swift run blah” and be done with it.
So I've set up a bunch of stuff where people can actually set up their code generation using a Swift library. I had that break in a super fun way when Xcode 11.4 came out because it used to be that if you called
xcrun from any build script run phrase, it would use the macOS version of Swift to do everything. Now you actually have to specify macOS. So you have to do “xcrun sdk macOS swift run” in order to ensure that it actually uses the macOS SDK, rather.
Paul Hudson: I should say here actually Ankit Aggarwal is on the chat, who works in SPM a lot at Apple. So this is your chance to fire radars in person. Tell him exactly all your problems. I'm sure he'll get around to fixing them straight away!
Ellen Shapiro: Hi Ankit! I've got an open PR on Apollo right now. That's got that stuff in it, but it was one of those things where I'm not sure whether this is actually a bug or whether this fixes a bug, because generally when you run a build script Run Phase from Xcode it does assume that you're using everything in the environment that whatever your project is using. And the fact that if you just called xcrun, it would just kick off with macOS. That was different from how anything else would work. But yeah, it's changed. I don't know if that was supposed to change, but it changed.
“I think this is kind of part of why the iOS ecosystem has a lot of not invented here syndrome because adding additional dependencies comes with such a high price.”
I think I've really been excited about working with SPM. I have fought endlessly with CocoaPods and Carthage my entire career. CocoaPods, when it first came out, it was an absolute dream in terms of integrating anything. Yeah, there was a bunch of stuff that was really, really annoying in terms of how it would mess with your Xcode project file. But at that point, I didn't care because I could actually use dependencies in a way that made sense. I have long been on the record as not being a super fan of Carthage. I might've tweeted a T-shirt that said, “Carthago delenda est”, which is Latin for “Carthage must be destroyed”, which I'm like, “yay references to first century wars.” But it's one of those things where I think Carthage solves the problem wildly differently than CocoaPods does.
And I think there are definitely ways and situations in which it works better. In my personal experience, I have had a large number of problems with things. Just like I changed nothing and it all broke. And that for a package manager is not ideal. And so when you sort of have the choice between, okay, we have the CocoaPods ecosystem that's reasonably stable, but does a lot of stuff to mess around with your project. And then you have the Carthage ecosystem, which doesn't do anything to your project, but also can be kind of fragile. Having player three in the room is nice because it does encourage new things. It also is very helpful that it's backed by Apple. I think that's been a reason that a lot of people have been a little bit reluctant to sort of jump onto either Carthage or CocoaPods.
At a certain point, I think this is kind of part of why the iOS ecosystem has a lot of not invented here syndrome because adding additional dependencies comes with such a high price. And I think there's a lot of people who would argue that that's a good thing because you don't want to wind up with the infamous NPM “left pad” thing where somebody threw a fit, deleted a project and then broke half the internet. You certainly don't want to end up with that. But I think conversely, you also don't want to end up with a situation where everyone is reinventing the same wheel all the time. And I feel like that's something that we wind up doing a lot in the iOS community in a way that's super counterproductive.
Paul Hudson: Yeah. So what CocoaPods gave us, from nothing effectively, was a platform where we could share code very, very easily and keep it updated with security updates and feature updates and similar. Because before that, there wasn't a lot going on, right? We were just copying in Objective-C. At the time, copy in the headers and so forth. So CocoaPods was a big improvement there. And of course it did give us a standard. It wasn't a standard that many people liked in some respects because you have to download that very large master repo. And as you said, it modified your project to have a workspace and similar, so it caused a few teething problems, but it became a standard which you could at least work with. Whereas now SPM, because it is backed by Apple, is a fresh standard and a simpler standard I think.
Ellen Shapiro: Yeah. And I think one thing that I'll say is for CocoaPods is it's a lot less complicated than it used to be. They've definitely done a lot of work to make it simpler, make it more stable and make it do less to mess around directly with your Xcode project or your Xcode workspace. And so that's something where, honestly, if people ask me what to use, I'm like, “alright, do you have any of these things that are currently blockers on SPM?" Some resources or there's one or two other things that are still outstanding. Swift Evolution things to implement. And it's like, if you don't have any of those, use Swift Package Manager, because it's a lot easier. If you do have those use, try to use CocoaPods.
And again, I really appreciate the work that went into Carthage. People really worked their butts off on it and it's something where I completely see what they were trying to do with it. I just have personally found that the trade offs in terms of sort of when it works, it works great. When it doesn't work, it fails in ways that are really difficult to troubleshoot. And that I think is the piece that I've had the most problems with.
Ellen Shapiro: Yeah. I mean, I'm definitely still supporting all three. I think it's made me even more “Carthago delenda est”, but definitely one of those things where I think until Swift Package Manager can handle some of the – I don't want to say edge cases – but sort of more common things that SDKs need to do that aren't sort of the basic, here's a bunch of code. I think once that's resolved, I think that is definitely going to be the better option, but it's not super clear when some of that stuff is going to land. And I think it's definitely something where yeah, it's a hard problem to solve. I mean, God bless Ankit and Boris and everybody else who were working on the Swift Package Manager, you guys are amazing because it’s difficult to write a package manager.
“I'm really looking forward to Swift Package Manager reaching full maturity. I'm just happy that it's baked into Xcode now, and that you can use it with iOS projects.”
Whereas I think my most recent complaint on Twitter about Carthage, I was saying about CocoaPods that I less frequently wanted to launch it into the sun. And then I said, if I never wanted to launch it into the sun, it wouldn't be a package manager. And I had a couple of people be like, "That's my new bio." And it's like, people who worked at CocoaPods, and SPM and Carthage. It's a really difficult problem to solve. And I admire anybody with the guts to try and solve it. And I think I'm really glad that Apple has put their resources behind trying to solve this for the Swift ecosystem.
Paul Hudson: It's so nice – go to the package thing in the menu and then add the URL, choose the version you want to work with them. And it's there. It's as simple as you can get, really.
Ellen Shapiro: Yeah. And I think this is where I go back to the thing that I was talking about earlier, it would be great if plugins were a thing again. Because for most libraries, that's all you have to do. For our library, there's a bunch of stuff that you have to do to set up code generation that is not straightforward and is something where I have done my darnedest to make that as straightforward as possible. But it's really something where I compare the experience to that of front end developers who were using NPM and Visual Studio Code, which allows plugins. The amount of things that you have to do to set up code generation and the ability to use a TypeScript code really easily in Visual Studio Code is approximately none. It's basically done for you by the plugin. And on iOS, I have tried to make it a shorter thing as possible, and I keep looking for further shortcuts, but ultimately if the IDE itself is inextensible, there's only so much I can do.
Paul Hudson: Yes. I have some good news here from Ankit Aggarwal saying that the SwiftPM team has been working on landing all the current adoption blockers. Like resources, like binary dependencies, and so on. It's already in Swift 5.3, which was announced yesterday.
Ellen Shapiro: Yes, that was yesterday. Well, it was yesterday, they roadmap was announced and I was looking at that this morning and they were like, so when is this going to freeze for Swift Package Manager? Oh, that's tomorrow. I'm very glad to hear that most of that is in Swift 5.3, I wasn't sure how much of that made it in there. So, yay. I'm really excited about this feature of Swift Package Manager, not just for use with iOS stuff, but I really enjoy using it for scripting. I really enjoy using it for small tools. Particularly if there's something that you're distributing with your SDK, you're able to write and test them in a way that is just not possible with bash. And it makes your life an awful lot easier. I really, really like it.
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SPONSORED Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for iOS devs who want to become complete Senior iOS Developers.
Link copied to your pasteboard.