cocoapods-binary: prebuilt frameworks so a big podfile stops costing you build time

A CocoaPods plugin that compiles once and reuses

cocoapods-binary is a CocoaPods plugin to integrate pods in the form of prebuilt frameworks rather than source code, by adding just one flag in the Podfile, and the README's claim is that it speeds up compiling dramatically. The problem it names is one that every large iOS project recognises. When a Podfile lists dozens or hundreds of pods, the same third party source is compiled again and again, for no reason, and too much library source in the project slows down the compile and the response of the IDE, including code completion, and then reduces work efficiency. The plugin's answer is to replace the source code in the pod target with prebuilt frameworks. It is worth noting where this sits in the ecosystem. The README links to the CocoaPods guide on pre-compiling dependencies and says in a note that this plugin is a community work and not official. The value proposition is therefore not a new idea but a working implementation of an idea the CocoaPods project has documented, aimed at a specific pain point.

Why not just use Carthage

The README anticipates the obvious comparison and gives three reasons for using CocoaPods with this plugin rather than Carthage, which also integrates libraries as frameworks. The first is that a pod is a good, simple form to organize files and manage dependencies, including private or local pods. The second is a fast switch between source code and binary, or a mix of the two, so you can have some dependencies prebuilt and others still compiled from source in the same project, which is the flexibility a plugin gives you that a global framework approach does not. The third is that some libraries simply do not support Carthage. That last point decides the matter for any team whose dependencies include a library that does not support Carthage, since there is no binary option for it outside CocoaPods. The plugin's own contribution is to make the binary path available inside the dependency manager you are already using, with the same podfile, the same version resolution and the same private pod handling.

What the plugin actually does during pod install

The mechanism is described in the README under a heading that invites you to skip it and try the plugin first. It compiles the source code of pods during the pod install process and makes CocoaPods use them, and which pods get compiled is controlled by the flag in the Podfile. The detailed version goes like this. The plugin performs a separate, complete `pod install` in the standard pre-install hook, filtering the pods by the flag from the Podfile. It then builds frameworks from that generated project using `xcodebuild`, stores the frameworks in `Pods/_Prebuild`, and saves the `manifest.lock` file for the next pod install. In the following normal install process, it hooks the integration functions to modify the pod specification so that the frameworks are used. The interesting part for an operator is the pre-build step, because it is a full build of the dependency graph, run once, and the result is cached in the Pods directory. If your Pods folder is excluded from git, that cache has to live somewhere, and the README addresses exactly this with an option.

Adding it to a Podfile

Installation is a gem, and the usage is a few lines in the Podfile.

$ gem install cocoapods-binary

plugin 'cocoapods-binary'

use_frameworks!
# all_binary!

target "HP" do
    pod "ExpectoPatronum", :binary => true
end

There are two ways to select pods. You add `:binary => true` as an option of one specific pod, or you add `all_binary!` before all targets, which makes all pods binaries. The escape hatch for the second mode is the same option set to false, so a pod can be marked `:binary => false` to disable binary for it when `all_binary!` is in force. Two more switches are worth knowing. If your Pods folder is excluded from git, you may add `keep_source_code_for_prebuilt_frameworks!` in the head of the Podfile to speed up pod install, as it will not download all the sources every time the prebuilt pods change. And if bitcode is needed, `enable_bitcode_for_prebuilt_frameworks!` goes before all targets in the Podfile.

The constraints the README states plainly

There are three constraints, and one of them is a hard requirement rather than a preference. The plugin requires `use_frameworks!`, and the README addresses the worry that follows from it directly, noting that if you are concerned about boot time and other problems introduced by dynamic frameworks, a static framework is a good choice, and pointing to another plugin by the same author, cocoapods-static-swift-framework, which makes all pods static frameworks. So the choice is between dynamic frameworks with a faster build and static frameworks with a slower build, and the plugin does not hide that trade. The second constraint is the known issue list, where the entry that remains is that watchOS is not supported. The third is a bug that has been fixed: dSYM files were missing for dynamic frameworks using the plugin, with the workaround of not using it for a release build and wrapping the plugin line in an environment condition, and the README marks that as fixed in 0.4.2. That entry is worth reading anyway, because it describes the failure mode precisely, which is a missing symbol file rather than a broken build.

An aging plugin in a fast moving toolchain

The maintenance picture is the part to weigh carefully. The tagged releases run 0.4.2 in March 2019, 0.4.3 in April 2019 and 0.4.4 on 2019-04-27, with titles as terse as bug fixes and a bug fix. The last push to the branch was on 2026-06-23, so the repository is not abandoned, but the README's own guidance still points at a 2019 era of CocoaPods, and the plugin hooks into CocoaPods internals, namely the pre-install hook and the integration functions, which is exactly the kind of surface that moves. The repository layout is a classic Ruby gem, with a `cocoapods-binary.gemspec`, a `Rakefile`, a `Gemfile`, a `.travis.yml` for continuous integration, and the usual `lib/`, `spec/`, `test/` directories, plus a `demo/` directory with a complete Podfile, a Podfile.lock, an Xcode project and a workspace, which is the fastest way to see the plugin working in a small project. The practical conclusion for an adopter is that this plugin should be evaluated against your exact Xcode and CocoaPods versions, and that the demo project is the cheapest possible way to find out whether it still runs.

Editorial conclusion

Adopt cocoapods-binary if your iOS project has many pods, your build times and your editor's responsiveness are suffering, and you are willing to add use_frameworks! to your Podfile. Do not adopt it if you need watchOS support, which the README lists as unsupported, or if you cannot accept dynamic framework semantics, where the alternative is the author's own static framework plugin. Before you roll it out, check the Xcode and CocoaPods versions your build machine runs against the ones this plugin was written for, since the newest release is from 2019 and a build-time plugin that has not been updated is a real risk in a toolchain that moves quickly. The licence is MIT, the last release is 0.4.4 from 2019-04-27, and the last push was on 2026-06-23.

Frequently asked questions

Official sources

1. Issues
2. leavez/cocoapods-binary on GitHub
3. License: MIT
4. README
5. Releases