I know this kind of goes against the whole purpose of Cocoapods, but sometimes you work at a stealthy startup who can't exactly go giving away all their tech secrets when they provide a framework to customers.
If you're in this boat, then fear not, there's a really easy way to provide access to your precompiled framework that doesn't involve email or a shared dropbox folder. This does assume your company uses some cloud based repo manager like Github or Bitbucket.
1. Make a Pod Repo
First, you’ll need to add a new git repo that has the precompiled .framework and a podspec. The podspec has a few required properties you’ll need to define, but it’s really just all the basic ones that are easy to fill in. Name, version, summary and description are some of the usuals that you'll have to fill in just to get things working.
The key property to set is vendored_frameworks. Pass in the name of your precompiled framework and the podspec will know that when a customer does a pod install, this framework should be included in the Pods target’s list of bundled frameworks.
2. Make a Spec Repo
A spec repo is just a repository that has a set of folders, each representing a separate cocoapod. Inside each folder, there’s another set of folders, each representing a discrete version of that framework. Usually these are tied to a tag that’s been assigned to a particular commit. Then inside that version folder, there’s a copy of the podspec at that point in time.
3. Release a New Version
The interesting thing is that you don’t manage a Spec repo directly by creating new folders for each version.
Instead, you first add your spec repo to your set of repos on the command line with:
| pod repo add <REPO_NAME> <SOURCE_URL> |
Then, you use the pod command to create a new release for you
| pod repo push <REPO_NAME> <SPEC_NAME>.podspec |
As long as your podspec was set up correctly and passes the linter, a new folder for this version of the pod will be pushed up to the Spec repo and will be accessible to anyone doing a pod install in the future.
Now, your pod won't automatically be visible to a client's Podfile. To fix that, they'll need to add your Specs repo as a source from which Pods can be retrieved by adding this line to the top of their Podfile.
| source '<URL_TO_REPOSITORY>' |
4. Done
And that’s it!
I will say this solution absolutely doesn’t scale super well. Github doesn't seem to allow you to add organizations as read-only collaborators. You probably don't want to manage tons of clients (aka all their employees) as collaborators on GitHub, but if you only have a couple then this is a really easy way to get up and running quickly while sharing your closed source frameworks!
I'm pretty sure the nice thing is, once you get this far you can take the next step and have them use an Artifactory instance as the middle-man. This means you'll only need to add some generic Artifactory user as a collaborator. Then their instance can pull down versions of your frameworks and distribute them to the whole team.
And you thought I was leading down a dark path there for a second