Cocoapods: Bundle identifier of pods is the same as the app (instead of org.cocoapods.PodName)

Created on 8 Mar 2016  路  7Comments  路  Source: CocoaPods/CocoaPods

Report

What did you do?

I upgraded from the latest stable version of CocoaPods to v. 1.0 beta 5
I've a script building my app which looks like this:

xcodebuild -scheme MyScheme \
  -workspace MyWorkSpace.xcworkspace \
  -configuration Release \
  PRODUCT_BUNDLE_IDENTIFIER="com.mycomp.myapp" \
  ...
  clean \
  archive -archivePath build/app

xcodebuild -exportArchive -exportOptionsPlist OptionsPlist.plist \
  -archivePath build/app.xcarchive \
  -exportPath build/

What did you expected to happen?

I expected my app to build and work fine (aka install on any device since I'm using an enterprise certificate)

What happened instead?

The compile and archive is successful, but the app doesn't install on devices.

From the device log I can see that the error is:
443: Found bundle at AlamofireImage.framework with the same identifier (com.mycomp.myapp) as bundle at Alamofire.framework

Also, I noticed that in the app file inside the xcarchive folder, in the Frameworks folder, every framework Info.plist file has as a bundle identifier the app identifier. Before it was something like org.cocoapods.PodName.

I think that passing PRODUCT_BUNDLE_IDENTIFIER to xcodebuild changes the bundle identifier of the frameworks as well.

Podfile

platform :ios, '8.0'
use_frameworks!

target 'MyApp' do
  pod 'Fabric'
  pod 'Crashlytics'
  pod 'Alamofire', '~> 3'
  pod 'AlamofireImage', '~> 2.0'

  target 'MyApp Tests' do
    inherit! :search_paths
    pod 'OHHTTPStubs'
  end
end

Most helpful comment

Facing the same issue after update to 1.0.0 on our CI server.
I've found a commit when it was changed. c21acb82e06b3ca66c15be06a776a9a107705b97

Workaround seems legit though, but feels strange because with 0.39 all was good without any workarounds (talking about 'Update to recommended settings' warning).

Maybe it can be adjusted to allow passing PRODUCT_BUNDLE_IDENTIFIER in xcodebuild?

All 7 comments

Yeah, that's how passing variables to xcodebuild works, unfortunately. It effects every product built. Your best bet might be to control things like that on your app via build configurations.

But it was working fine with all stable versions before 1.0. So there is no plan to fix this?

@samdmarshall have any ideas on this?

and by the way, in my case, I can't use build configurations because the bundle identifier can be set to anything via a web interface ;)

So if anyone else have this issue I temporarily fix it (still hoping CocoaPods to fix it) by:
1) In Info.plist change the Bundle Identifier from $(PRODUCT_BUNDLE_IDENTIFIER) to $(APP_BUNDLE_IDENTIFIER)
2) In Build Settings change the Product Bundle Identifier to $(APP_BUNDLE_IDENTIFIER)
3) Create a new User Defined Setting (this step is only needed to have a default value in order to be able to run the app from Xcode during development) which will be APP_BUNDLE_IDENTIFIER and the value will be your default bundle identifier.

馃憤馃徎 seems like a good workaround to me!

Facing the same issue after update to 1.0.0 on our CI server.
I've found a commit when it was changed. c21acb82e06b3ca66c15be06a776a9a107705b97

Workaround seems legit though, but feels strange because with 0.39 all was good without any workarounds (talking about 'Update to recommended settings' warning).

Maybe it can be adjusted to allow passing PRODUCT_BUNDLE_IDENTIFIER in xcodebuild?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

iosdev-republicofapps picture iosdev-republicofapps  路  3Comments

Curtis-Halbrook picture Curtis-Halbrook  路  3Comments

soleares picture soleares  路  3Comments

Mingmingmew picture Mingmingmew  路  3Comments

pronebird picture pronebird  路  3Comments