Difference between podspec dependency and Podfile pod declaration

Question

I have a project for a cocoapod (let's call it "Main") which has a dependency with another cocoapod (let's call this one "Util").

I can add the Util in Main's Podfile via "pod 'Util'" and specify it as a dependency in the podspec via "s.dependency 'Util'"

As long as at least one of these are written, my test project for the pod runs fine (altho without the dependency in the podspec, running the "pod lib lint" command returns errors)

Specifying the pod in the Podfile allows me a lot more granularity as to how precise I want the version to be, even allowing me to use :head as a target. However, the dependency seems much more limited, requiring tags.

I would like to know the difference between these two approaches and if there are good practices to use when one pod depends on another (especially since I'd want to use Main as a pod for other projects eventually)

Leucopoiesis

I've recently run into this same question. Did you ever figure out the difference between editing the podspec and editing the Podfile? Most documentation I see online says you should edit your Podfile, but then I wonder what the point of the podspec is? – Shapeless

Answer 1

You could say Podfile is your project configuration, and Podspec is your library configuration.

Podfile:

• Present in the root directory, as file called Podfile
• All applications which want to use Cocoapods (e.g. add dependencies via pod 'library_name') need to have a Podfile. This is where that information goes.

Podspec (Specification of Pod library):

• Present in the root directory, as file called Library_name.podspec, which is formatted with Ruby DSL syntax
• This file is required to upload your library to Cocoapods.org (or use it via pod 'library_name'). When you pod trunk push, you are pushing the JSON version of this file, e.g. LibName.podpsec.json, for example, here.
• Libraries/ packages can also specify a Podfile on top of the Podspec, for specific code which the developers don't want to accessible when downstream users use the library.
• It has version limitations because to give the decision of selecting versions to the application which uses the library (the Podfile)

Differences:

In your case, you just have code which you're not sharing with anyone. Therefore, it doesn't need to be a library, you can just have everything in your Podfile as a separate target, and you don't even need a Podspec. If you want to share the library with others via Cocoapods, then you need the Podspec file. But, if you want to re-use main across different projects, then the configuration you want to share with those projects should be in the .podspec file, and you can reference the local directory containing the podspec in your other repos.

More information about Podspec in the documentation.

A specification describes a version of Pod library. It includes details about where the source should be fetched from, what files to use, the build settings to apply, and other general metadata such as its name, version, and description.

A note for future readers

I would suggest you release your package/ library through Swift Package Manager instead of Cocoapods or Carthage. All the benefits of Cocoapods can be achieved with SPM. Users can easily migrate to using Swift Packages in their Xcode project because it is built-in, so there is no need to support other package managers.

Classis

SPM doesn't support mixed language source file in the same target i.e. Mixing Swift and Objective C files in the same target, except that most of the things can be achieved with swift package. – Ablate

Answer 2

If I understand you correctly, you need both.

You put Util in the Podfile of Main so it can use it and compile.

You put Util in the .podspec of Main so that anybody installing Main will automatically get Util along with Main.

Also this article might prove useful for you, as it shows how to have optional dependencies via subspec.

You can make multiple version of your pod that include different dependencies. For example from the article, the following .podspec:

...
spec.default_subspec = 'Lite'

spec.subspec 'Lite' do |lite|
    # subspec for users who don't want the third party PayPal 
    # & Stripe bloat
end

spec.subspec 'PayPal' do |paypal|
    paypal.xcconfig =  
        { 'OTHER_CFLAGS' => '$(inherited) -DKITE_OFFER_PAYPAL' }
    paypal.dependency   'PayPal-iOS-SDK', '~> 2.4.2'
end

spec.subspec 'ApplePay' do |apple|
    apple.xcconfig =   
        { 'OTHER_CFLAGS' => '$(inherited) -DKITE_OFFER_APPLE_PAY' }
    apple.dependency      'Stripe', '2.2.0'
    apple.dependency      'Stripe/ApplePay'
end

allows for the following 3 pods:

pod "Kite-Print-SDK", "~> 1.0"
pod "Kite-Print-SDK/PayPal", "~> 1.0"
pod "Kite-Print-SDK/ApplePay", "~> 1.0"

Turaco