Flag & Library Lab
Private CocoaPods Specs
A private specs repository and publishing flow for internal iOS libraries.
30-second summary
Problem
Internal iOS libraries needed a reliable way to be shared across projects.
Ownership
Supported the publishing path and documentation needed for internal library distribution.
Key decision
Documented and supported a private CocoaPods specs flow for creating, publishing, and consuming internal libraries.
Result
- Internal libraries shared like any other dependency
- A repeatable publish workflow, not tribal knowledge
- Reused code across projects instead of copying it
Highlights
Context
Internal iOS libraries are only useful if other projects can actually depend on them. Without a reliable distribution path, shared code tends to get copy-pasted between repositories, which quietly defeats the point of building it once.
This work set up a private CocoaPods specs flow so internal libraries have a first-class way to be published and consumed.
Approach
The aim was a repeatable, documented path rather than a one-off setup:
- A private specs repository as the registry for internal pods.
- A publishing workflow for creating and pushing new library versions through Bitbucket.
- Documentation so the process is something any engineer can follow, not tribal knowledge held by one person.
How it works
A library is versioned and its podspec published to the private specs repository. Consuming projects point at that specs repo and pull the library like any other CocoaPods dependency — so internal code is distributed through the same mechanism engineers already use for third-party pods.
Outcome
The result is easier internal library reuse, smoother collaboration across projects, and a clear, repeatable publishing process instead of ad-hoc sharing.
What I’d build next
Worthwhile follow-ups are automating the publish step in CI, validating podspecs before they land, and a simple index of available internal libraries so they’re discoverable.