CocoaPods Preparing a Release

In this lesson

Before it’s time to publish your CocoaPod, there are a few things you should do! Some of these steps include things like running a lint check on your podspec, versioning your source control, making sure your users have access to the source code, and registering with via Trunk.

Kyle Roberts
Swift Guru at Large

Kyle's Series


Tap on time to skip ahead


Hello world, Kyle here with and we’re going to talk about some things you need to do to prepare your third party resource for publishing through CocoaPods. So let’s say you have version 0.1 or version 1 of your resource ready to go and you want to post it to CocoaPods, either privately or publicly. But before you do that, there are a few things you need to have set up.


Of course you’re gonna need your base code. Here is actually a standard Xcode project, it’s not the code for a resource but there’s still definitely some Swift code within here. So you need your code for your resource or else you’re not gonna be posting anything. And you’re going to need a podspec filled out to fit your code and what you want your resource to be. And that includes stuff like name and the version of your resource as well as some URLs to your GitHub or wherever you’re storing the repo, and just some descriptions and stuff like that. So that’s the bare minimum of content that you need to release your CocoaPod or prepare for release. But there are a couple other steps of some things that you will want to do.


And in Terminal, it’s good to go ahead and navigate to the directory where you have your podspec stored. Normally, you only have one but just for the sake of documentation and references for these videos, I actually have two different podspecs here. But once you navigate to that directory, you want to run a command called pod spec lint and then pass in the name of the podspec that you would want to run this lint assessment over. So at the moment, neither of these example podspec that I have here are actually going to pass this lint check just due to a few things, mainly this not being an actual library, they’re just examples for reference.


But I’m going to run it anyway for our entertainment. So when you run pod spec lint, it’s going to run a series of tests and checks over your podspec file and make sure that everything is in working order for upload to I have a warning and an error currently. The error is about the source files path that I have here, I’m just putting the name SteamReader, you actually need to give it a path. When you do that, it’s actually going to build that code so if I were – I was having issues just pointing at the code and I was also having issues pointing at the workspace, but again, that’s just because this is an actual Xcode project and not my own custom library. But assuming you have a real third party resource set up then, you know, just set the source files correctly and you’re good to go.


And then it also says there’s a problem validating the URL. I’m not really sure what URL this talking about, I tweaked a few of them but really most of them are pointing to my GitHub so it’s probably just some small change I need to make there. But another important thing once you clear up some of these other errors, you’ll probably end up running this several times and fixing whatever it complains about. But no biggie. But one that is specifically pointed out on is that you want to somehow mark your releases in source control.


Now I do have a tag for the version 0.1 release of SteamReader, which is actually when I started recording videos for this app. Whenever you tag or create a new remote branch on a commit for the specific version that you’re going to release, you need to name it based on semantic versioning numbers, that sort of thing. So you can’t have any letters like I do, or at least can’t start with a V. Now if I were to mark this for release for a CocoaPods publish, I would rename this branch or tag to just 0.1.0 but that’s just one more check. And you do you want your podspec version number, which I have here so it is defined as 0.1.0 to match a tag or branch within your source control.


And one final thing you need to do whether you are intending to publish privately or for public consumption of your new library, you need to register with CocoaPods via something called Trunk. And to do that, it’s just sort of like an authentication thing so that it links certain libraries and devices to certain people so that not just anyone can publish new versions for CocoaPods. And the command you use to do this is pod trunk register and then you pass the email that you’ll be using for your CocoaPods Trunk account or authentication, and then a name for that account to go along with the email, and then pass in this – there’s actually two dashes here, let me resize this window so you can see that. Two dashes with the description attribute and just a short description of the device that you’re registering on.


So if I were to go over to my MacBook, I would have to make a new registry here. As soon as you press enter, it’s going to create a new registration for you through Trunk for CocoaPods. And it’s super easy, all it does is send you an email you open that email, you click the verification link, and then you’re good to go. 

Additional Info

Register to get access to additional resources and info.