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/
I expected my app to build and work fine (aka install on any device since I'm using an enterprise certificate)
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.
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
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?
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?