> ## Content Index
> Fetch the complete content index at: https://somekindofcode.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Moving away from CocoaPods
- URL: https://somekindofcode.com/moving-away-from-cocoapods/
- Published: 2016-06-27T12:34:24.000Z
- Updated: 2019-03-01T17:22:30.000Z
- Author: Christopher Beloch
- Tags: cocoapods, carthage, #Import 2026-07-17 02:07

When you develop native in Apples environment, you stumble over [CocoaPods](https://cocoapods.org/?ref=somekindofcode.com) to implement 3rd party libraries in your apps. It adds dependencies that can be installed separately and don't have to be stored in your respositories.

I used it for a few years now, but it gets worse every week so I'm leaving and switching to [Carthage](https://github.com/Carthage/Carthage?ref=somekindofcode.com).

## So what is the problem with CocoaPods?

### It's centralized

All Libraries are submitted to a [central git repository](https://github.com/CocoaPods/Specs?ref=somekindofcode.com) hosted on GitHub or you create your own specs repository and modify your `Podfile` in you project to use that one.

### Complicated Syntax

The syntax for adding your own private Pods to the dependencies is a little bit messy:

```
pod 'MySecretLib', :git => 'git@github.com:SomeKindOfCode/ThatSecretLib.git'

```

And can get worse when you specify a specific branch, commit or version:

```ruby
pod 'MySecretLib', :git => 'git@github.com:SomeKindOfCode/ThatSecretLib.git', :branch => 'develop'  
pod 'MyOtherLib', :git => 'git@github.com:SomeKindOfCode/MyOtherLib.git', :tag => '1.3.5'

```

Using a version operator like `~> 1.0` is not possible here.

### Patchwork without (much) control

This is one of the main issues for me.

When you run `pod install`, CocoaPods will generate a `Pods.xcodeproj` for you and if it doesn't exist, creates a Xcode workspace file for you. The last one isn't an issue, but the first is.

When you develop a framework for CocoaPods, you can throw everything into a folder, add a `.podspec` to your reposoitory and submit it. Everything else is controlled via a 3rd party. There is no requirement to create a custom Xcode project.

Due to these steps which change a few things with each CocoaPods Version I recently ran into a large amount of signing issues.  
It cost me a day of work to get my app fixed to be submitted to the App Store. The only fix was another project manipulation I had to add to my `Podfile`.

```ruby
post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings['EXPANDED_CODE_SIGN_IDENTITY'] = ""
            config.build_settings['CODE_SIGNING_REQUIRED'] = "NO"
            config.build_settings['CODE_SIGNING_ALLOWED'] = "NO"
        end
    end
end

```

This disabled the codesigning on the frameworks. I hate this step and this has to be done for each app you develop.  
I got sick of it. Every new version broke something different so I moved over to [Carthage](https://github.com/Carthage/Carthage?ref=somekindofcode.com) which gives you much more control, is decentralized and builds real frameworks!

This automatic generation is also the problem why you can't migrate all Pods to Carthage. Most will work, but every now and then I've stumbled over projects that were created in the most simple way. If you want to develop your own Framework, consider using something like [SwiftPlate by John Sundell](https://github.com/JohnSundell/SwiftPlate?ref=somekindofcode.com).

*Updated March 1st 2019*