Target Deduplication and App Extensions

[tobihagemann]

I'm experiencing issues with the recent version of CocoaPods (0.38.2) and I think it has to do with the new feature "Target Deduplication". I like the concept, but I'm not sure if it's completely applicable to App Extensions. Or maybe I just haven't seen how it's intended to be used yet.

Scenario: I have two targets, one is the main application, the other one is an app extension. Let's say I would want to use the pod SVProgressHUD on both targets. On the main application I'd like to use it "normally" and on the app extension I'd have to add the preprocessor macro SV_APP_EXTENSIONS, so that it's safe to use in an app extension.

Prior to CocoaPods 0.38, I've used this post_install hook to set the preprocessor macro:

post_install do |installer|
    installer.project.targets.each do |target|
        if target.name == "Pods-MyExtension-SVProgressHUD"
            target.build_configurations.each do |config|
                config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)']
                config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] << 'SV_APP_EXTENSIONS'
            end
        end
    end
end

This worked well, because I had separate pod targets for the main application and the app extension.

With CocoaPods 0.38 I can't do this anymore, because I only have one pods target for both targets. And worse: All pods targets now have the "Require Only App-Extension-Safe API" set to YES, so I have to(!) add the preprocessor macro in order to get it working at all, even though I wouldn't want it on the main application.

Have I missed something? Thanks in advance!

[neonichu]

See discussion in #3794 — when integrating with frameworks, there's simply no other solution, each framework can only exist once in an app bundle; when integrating with static libraries, the correct course of action is to use the opt-out, then you get the old behaviour.