Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Link with different Pods according to the build configuration #731

sguillope opened this Issue · 32 comments

Reference to original post on CocoaPods' Google Group:


I'm new at using CocoaPods so maybe I'm missing something here.

I have a project with 2 targets that I'll call MYTarget1 and MYTarget2. Both targets are linked to the same libraries, they are not different on that side. The project also has 3 different build configurations: Debug, AdHoc and Release.

I'm trying to set up my Podfile so that the HockeySDK framework is only linked with a target when building it using the AdHoc build configuration. I don't want to link with HockeySDK in Debug or Release.
I have the same problem with PonyDebugger which I only want to link when using Debug, again regardless of which target I'm building.

Here's how my Podfile currently looks like:

Here's how I currently link static libs or framework to specific build configurations:
I use the OTHER_LDFLAGS build setting instead of linking using the Link Binary With Libraries' build phase.
Screen Shot 2013-01-07 at 11 43 07 AM



Thanks for filling the issue.


@sguillope are you saying this is a solution or a problem? I don't see SocketRocket or PonyDebugger in your Podfile. I would also like to have per build configuration pods.


@garthex No it's a problem. There is currently no way to conditionally link with a pod based on a build configuration.
That's why neither PonyDebugger or HockeySDK are in the Podfile. I have to manage them separately.


Was just looking for this same feature, for very similar reasons.

I'd like to only include TestFlight during ad-hoc builds and not in debug or release builds. Creating a new Target isn't very helpful for this purpose, as I'd need to always keep that target up to date with any build setting changes on the debug/release target.


Just to chime in : I'm also looking for the same feature. Is there any workaround for now (like a post_install hook) ?


I am also looking for this so we can integrate MonkeyTalk into specific build configurations.

@fabiopelosin fabiopelosin referenced this issue

Isolate Pods in dedicated targets #841

1 of 3 tasks complete

Looking for this as well, same TestFlight reason.



We develop a developer tool called the Spark Inspector (kind of like PonyDebugger) and I'd really like this feature as well.


+1 Would love to see this feature, & hear what work-arounds are being used in the interim.


Hey folks, this feature is something we really want and it’s definitely going to be added. However, +1’ing will not make it go in any faster, only patches will. If someone wants to step up and take a stab at implementing it, let us know and we can help you out with any questions you might have.


Here is one idea (not tested!) for a workaround before the official solution is available:

  • Create a new (empty) target of type "Static Library" named "DebugTools" in your user project
  • Link it with your application, but only in Debug, by adding -lDebugTools to the OTHER_LDFLAGS Build Setting but only for the Debug configuration (don't forget to keep $(inherited) if not present already)

Then you should be able to configure the pods needed in debug by adding them in the DebugTool target only, via your Podfile, like:

pod 'AFNetworking' # For all build configurations, Debug and Release

target 'DebugTools', :exclusive => true do
  pod 'PonyDebugger' # Debugger only needed in debug
  pod 'OHHTTPStubs' # Stubs for Network Requests only in debug too

Don't have time to test it right now, but I guess it should work

@sguillope sguillope closed this
@sguillope sguillope reopened this

Looking forward to this great feature! CocoaPods is incomplete without this.


@AliSoftware Thanks for the workaround suggestion!


The workaround is nice but it won't work if one of the DebugTools pods shares some common dependencies with the pods from the main target.
You'll get duplicated symbols errors during linking phase in that case.


Finally, I found a 100% working solution, except it needs some manual processing after pod install. Anyway, I suppose, you know how automate it directly in a Podfile.

So, here we go:

xcodeproj 'Example'

pod 'NSXtensions'
pod 'RestKit'

target :debug do
  link_with 'Example'
  pod 'Reveal-iOS-SDK'
  pod 'PonyDebugger'

target :Tests, :exclusive => true do
  link_with 'Example'
  pod 'Kiwi'
  • Run pod install

Now, several one-time actions over project settings:

  • Navigate to the project configurations and make them look like this:


  • Manage schemes to remove all CocoaPods stuff and make your scheme shared:


  • Edit you scheme by adding new targets from CocoaPods and checking corresponding options just like it's showed on an image below (don't forget to uncheck "Parallelize Build"):


  • At the end, fix your target's build settings to link different configurations with different pods:




  • And finally, you need to remove any linked libraries and frameworks derived from CocoaPods in a corresponding build phase for all targets (app and tests). In my Example I simply deleted the very Frameworks folder in the project tree:


The last is the only step you need to repeat each time you run pod install, because it adds CocoaPods libraries to the linker build phase and leads to duplicate symbols errors.


@shoumikhin Thanks for the detailed report, with this we are very close to define what CocoaPods should do to support this feature. I had in mind a slightly different approach, instead of creating an aggregate lib per build configuration I was planning to just link through the xcconfig the single libraries of the Pods. Not sure of what would be the pros and the cons of each approach (maybe mine is a bit less noisy as we would not need to create additional targets.)

As a note to achieve this I would leverage the [*]-syntax of the xcconfigs (see this).


Any news on this? How can we help, what's the approach chosen so far and the remaining steps to implement in the CP code to make it happen?

I've seen other issues like #1294 that talks about some syntax like xcodeproj 'SampleProject', 'App Store' => :release, 'Debug' => :debug, 'Release' => :release, so it seems some work has began on this project configurations thingy, but not sure about the strategy on how you plan to implement this and how we can help w/o messing around with the existing code?



@AliSoftware The steps are the following

Definition of a clean DSL syntax to use in the Podfile

I would propose not to overload the options of the pods which already support too many parameters. Instead I would introduce a syntax which leverage the already present inheritance mechanism. We need to be careful about what we pick because this is a sticky choice.

target 'MyApp' do
  pod 'AFNetworking'
  configuration 'AdHoc' do
    pod 'HockeySDK'
Definition of the approach to use in the project

It is necessary to identify precisely the approach that we will use, I think that using conditionals in the xcconfigs is the way to go. A test project in that regard would help.

Path in CP

The cocoapods-core gem needs to be updated to support the new DSL in the Pod::Podfile::TargetDefinition class and it should store the relative information. Then the classes which store the information about the targets in the cocoapods gem need to be updated to take into account this information. Finally the Pod::Installer::TargetInstaller class should take into account this, likely in the XCConfig generator.


Sort of related, is that it is currently not possible to link, N pods against all targets, and then M separate pods with L sets of targets, without creating M*N targets in the Pods project. For example...

# Link these with all targets
pod 'AFNetworking', '~> 1.3'
pod 'Appirater', '~> 1.0'
pod 'TTTAttributedLabel', '~> 1.7'
pod 'Facebook-iOS-SDK', '3.7.1'
pod 'TMCache', '~> 1.2.0'
pod 'SMPageControl', '~> 1.0'
pod 'DTCoreText', '~> 1.6'

link_with ['Staged'] # This is a 'fake' target which we need to exist to have something to link against.

# Link this with some targets
target :Crittercism do
    pod 'CrittercismSDK', '4.0.7'
    link_with ['Popular App', 'Another Popular App']    

# Link this with some targets
target :HockeySDK do
pod 'HockeySDK', '3.0'
    link_with ['White Label', 'Another White Label', 'Yet Another White Label']

This creates Pods-Crittercism-AFNetworking, Pods-Crittercism-Appirater etc etc, and Pods-HockeySDK-AFNetwork, Pods-HockeySDK-Appirater etc, which if you add more pods to the default set, and increase the number of specialised targets (to work around configurations say), then you get lots of targets.

This is a problem, because it then takes a long time to run pod update.


@shoumikhin I followed your steps which worked perfectly. You mentioned automating the manual step of removing the linked libs after pod install. I'm not ruby savvy so I'm not sure how to make that happen. I'm guessing you're doing something with the post_install hook. Could you post an example?

This is my workaround to not have to delete the libs in build phases after pod install:

Since we're now linking to Pods, Pods-debug, etc. individually per configuration we don't need to link_with the main target. I created an empty static library Example-Pods and link_with that target in the podfile. Since I'm not actually using the Example-Pods target I don't have to remove the frameworks linked against it that CocoaPods installs.

xcodeproj 'Example'
link_with 'Example-Pods'

pod 'NSXtensions'
pod 'RestKit'

target :debug do
  link_with 'Example-Pods'
  pod 'Reveal-iOS-SDK'
  pod 'PonyDebugger'

It's not exactly an elegant solution, but it works and prevents the duplicate symbols failure after pod install.


Pay attention that with Xcode 5 every time I run pod install it changes the configuration settings, so I have to set again each configuration to use the correct configuration file like this:
screen shot 2013-11-26 at 16 17 01
and remove the linked libraries as explained above.
(I discovered this because my app linked against Reveal's framework, which used private APIs (Apple reported me the use of UICreateCGImageFromIOSurface)).


@shoumikhin Hi, i tried following the procedure you specified but ran into some issue. i managed to get all the pods installed and with different targets.

but when i try to build the project. I get following error.

/bin/sh: /Users/apple/Documents/Extra work/Tuk Tuk/i\U0010OS/Code/Tuk_tuk/Build/Intermediates/ No such file or directory

After some reading ,i managed to make it go away by deleting the following two scripts From the build phase

Copy Pods resources


Check Pods Manifest.lock

i am still new to cocoapods, i was wondering if removing these scripts will cause problems, if so can you possible help me resolve the error or suggest a work around.


Any news on getting this implemented?


@danthorpe seems your issue linking "N pods against all targets, and then M separate pods with L sets of targets" may be related to #1729 and the way CP create the targets, duplicating the targets of the N common pods in all app targets as explained in my images/schemas?

@CocoaPodsBot CocoaPodsBot was unassigned by sguillope

This appears to be a work-in-progress in #1791.

@CocoaPodsBot CocoaPodsBot was unassigned by sguillope

Issue has been confirmed by @lazerwalker

@CocoaPodsBot CocoaPodsBot was unassigned by sguillope



I would love to have this as well.


Thanks to @nevyn and @FabioPelosin, I believe this is now in master!

@segiddins segiddins closed this

It will be released in the next release, as will documentation.


Big thanks to everyone who has worked on this. I'm very excited to use this feature. @orta Do you have any estimate on when the next release may be?

@segiddins segiddins locked and limited conversation to collaborators
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Something went wrong with that request. Please try again.