Cocoapods: Version 1.6.1 tries to code sign frameworks

Created on 3 Apr 2019  ·  24Comments  ·  Source: CocoaPods/CocoaPods

Report

What did you do?

please note that this command is from our CI. However the same results happen
[command]/usr/bin/xcodebuild -sdk iphoneos -configuration release -workspace /Users/vsts/agent/2.148.2/work/1/s/MyApp/MyApp.xcworkspace -scheme MyApp build CODE_SIGN_STYLE=Manual CODE_SIGN_IDENTITY=iPhone Distribution: MyCompanyDistrobutionProfile PROVISIONING_PROFILE=848ebce8-dcd1-4746-a2ac-e702ffdc4c3e PROVISIONING_PROFILE_SPECIFIER=match InHouse com.MyCompany.MyApp | /usr/local/lib/ruby/gems/2.6.1/bin/xcpretty -r junit --no-color

What did you expect to happen?

App to successfully archive.

What happened instead?

While archiving the following errors occur. Issue occurs with both CocoaPods 1.6.0 and 1.6.1. Issue does not happen when running CocoaPods 1.5.3.

`
[command]/usr/bin/xcodebuild -version
Xcode 10.1
Build version 10B61
[command]/usr/bin/xcodebuild -sdk iphoneos -configuration release -workspace /Users/vsts/agent/2.148.2/work/1/s/MyApp/MyApp.xcworkspace -scheme MyApp build CODE_SIGN_STYLE=Manual CODE_SIGN_IDENTITY=iPhone Distribution: MyCompanyDistrobutionProfile PROVISIONING_PROFILE=848ebce8-dcd1-4746-a2ac-e702ffdc4c3e PROVISIONING_PROFILE_SPECIFIER=match InHouse com.MyCompany.MyApp | /usr/local/lib/ruby/gems/2.6.1/bin/xcpretty -r junit --no-color

❌ error: Appirater does not support provisioning profiles. Appirater does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'Appirater')

❌ error: BugfenderSDK does not support provisioning profiles. BugfenderSDK does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'BugfenderSDK')

❌ error: GoogleUtilities does not support provisioning profiles. GoogleUtilities does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'GoogleUtilities')

❌ error: FirebaseCore does not support provisioning profiles. FirebaseCore does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'FirebaseCore')

❌ error: nanopb does not support provisioning profiles. nanopb does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'nanopb')

❌ error: FirebaseInstanceID does not support provisioning profiles. FirebaseInstanceID does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'FirebaseInstanceID')

❌ error: JDFTooltips does not support provisioning profiles. JDFTooltips does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'JDFTooltips')

❌ error: TGPControls does not support provisioning profiles. TGPControls does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'TGPControls')

❌ error: libPhoneNumber-iOS does not support provisioning profiles. libPhoneNumber-iOS does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'libPhoneNumber-iOS')

❌ error: UISS does not support provisioning profiles. UISS does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'UISS')

❌ error: Pods-MyApp does not support provisioning profiles. Pods-MyApp does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'Pods-MyApp')

* BUILD FAILED *`

CocoaPods Environment

/usr/local/lib/ruby/gems/2.6.1/bin/pod install

help wanted awaiting input
Source
picture LondonAtlas

Most helpful comment

Ok, after many tentatives and inspections I've found the root issue (or, what, at least to me, it was).

TL,DR
Replace use_frameworks! with use_modular_headers!

For those who want a bit more context:

For some reasons, the latest updates of Cocoapods been having issues with Podfiles using

use_frameworks!

Technically, for a mixed project like the one in my company (having an Obj-C / Swift mixed codebase) which has gotten updates like:

  • Swift 5
  • Xcode 10.2.1
  • CocoaPods 1.7.2

the need of use_frameworks! vanish.
use_frameworks! let use Pods as Frameworks instead of Static Libraries (which wasn't supported in previous versions of Xcode).
Removing that one and replacing with use_modular_headers! restored the full Fastlane's delivery flow.
The above did the trick of course but I've been using this issue to improve the Fastfile and review my signing options as weel.

Hope it will work for you guys! 🚀 💪

picture d4r1091 on 14 Jun 2019
🎉2 👎1

All 24 comments

AFAIK nothing has changed in 1.6.x vs 1.5.x with code signing.

dnkoutso picture dnkoutso on 3 Apr 2019

Furthermore this issue report is not sufficient to diagnose the problem. Please upload a sample app.

dnkoutso picture dnkoutso on 3 Apr 2019

I've solved this with a post_install on my Podfiles:
post_install do |installer| installer.pods_project.targets.each do |target| target.build_configurations.each do |config| config.build_settings['EXPANDED_CODE_SIGN_IDENTITY'] = "" config.build_settings['CODE_SIGNING_REQUIRED'] = "NO" config.build_settings['CODE_SIGNING_ALLOWED'] = "NO" config.build_settings['ENABLE_BITCODE'] = "YES" config.build_settings['CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES'] = "YES" config.build_settings['SWIFT_SUPPRESS_WARNINGS'] = 'YES' end end end

markltownsend picture markltownsend on 4 Apr 2019
👍1

I'm seeing a similar issue using 1.6.1 and Xcode 10.2: Xcode attempts and fails to sign our dependencies. Using the post_install hook @markltownsend posted seems to fix the issue.

[11:30:54]: ▸ Code Signing /Users/jenkins/Library/Developer/Xcode/DerivedData/App-eofbustpiclfuncbvwyfvwapvumo/Build/Intermediates.noindex/ArchiveIntermediates/App/InstallationBuildProductsLocation/Applications/App.app/Frameworks/OnePasswordExtension.framework with Identity iPhone Distribution: My Identity

jshier picture jshier on 8 Apr 2019

I have tried a number of build settings changes including the one that @markltownsend posted with no success. We're seeing the same issue as this one reported on Microsoft Azure Pipelines: https://github.com/Microsoft/azure-pipelines-tasks/issues/9984

Are there any ideas as to what _may_ have changed? I'm still trying to pare down to a sample project that exhibits the same behavior. It seems like this may only happen when switching from Automatic to Manual signing.

I noticed two changes in release notes leading up to 1.6.0 related to code signing so maybe these are a good starting point?

https://github.com/CocoaPods/CocoaPods/issues/7606
https://github.com/CocoaPods/CocoaPods/issues/7708

bjtitus picture bjtitus on 11 Apr 2019

@dnkoutso I've attached an example project that shows the issue from this ticket (reproduce by adding your own Distribution profile and running ./build.sh). I also included the fix above and another line in ./build.sh which shows how archiving is broken even with the above fix. I believe they are likely the same issue in different forms but I'm happy to open another issue if necessary.

Still trying to narrow down any project changes between 1.5.x and 1.6.x and I'll post back if I find anything.

CCTest.zip

bjtitus picture bjtitus on 11 Apr 2019

@bjtitus yes the issues you linked were the two biggest changes as far as I know, https://github.com/CocoaPods/CocoaPods/pull/7640 is probably the most relevant

amorde picture amorde on 14 Apr 2019

Hey guys!
any updated on this? Has someone solved the above somehow?
Thanks 🚀

d4r1091 picture d4r1091 on 26 Apr 2019

No updates at this point

Checking the issue again, I noticed that the author is using Fastlane Match - is it possible there's a conflict with how Fastlane is configuring the Pods project?

This doesn't appear to be an issue for the vast majority of projects, so something must be different in the projects that are experiencing this.

amorde picture amorde on 9 May 2019

I've been trying literally everything.
Personally, I've been experiencing this issue since I've started using use_frameworks! + updating to Cocoapods 1.6.1.

No idea - tried to revert to previous versions (i.e. 1.5.3 as well as the 1.7.0beta but still facing the same issue)

d4r1091 picture d4r1091 on 9 May 2019

@d4r1091 do you have provisioning profiles specified on the targets in the Pods project? the provisioning provide should be set to Automatic

amorde picture amorde on 9 May 2019

Hey @amorde 😄 ,
yeah, everything has been set to Automatic and I'm not playing with any post_install action or stuff.
What I'm doing though (with Fastlane), is:

 sigh(
        adhoc: export_method=='ad-hoc',
        force: is_really_empty?(provisioning_filename), # If we've specified the name, let's just download it without recreate it as we may have not the rights to do so.
        skip_certificate_verification: true,
        provisioning_name: provisioning_filename,
        filename: "#{provisioning_filename}#{provisioning_filename_extension}",
        output_path: ENV['PROVISIONING_PROFILES_PATH'],
        app_identifier: current_bundle_identifier
      )

and

gym(scheme: scheme_name,
        include_bitcode: false,
        export_method: export_method,
        export_options: {
          provisioningProfiles: {
            current_bundle_identifier => provisioning_filename
          }
        },
        configuration: build_configuration,
        codesigning_identity: ENV['CODESIGNING_IDENTITY'],
        output_name: "#{scheme_name}_#{build}.ipa",
        output_directory: "./output/packages",
        xcargs: xcargs)

I wonder whether this bit:

   export_options: {
          provisioningProfiles: {
            current_bundle_identifier => provisioning_filename
          }
        }

...is somehow overriding the pods one but I don't think so.

d4r1091 picture d4r1091 on 16 May 2019

No I don't think Fastlane's export_options would affect this, that affects how the app is signed when exported.

If you open Pods.xcodeproj and look at the individual frameworks, do they have a provisioning profile specified? If they do, does it still show when deleting Pods/ and re-installing?

The biggest change to code signing was #7640, which removed logic that forced code signing suppression because it broke other things such as Interface Builder's @IBDesignable. The workaround posted above can be used to add the previous behavior, but it shouldn't be necessary. A sample project would be super helpful for debugging this

amorde picture amorde on 17 May 2019

Same error using cocoapods-core 1.7.0 - at this point I don't know if is worth keeping this issue opened 🤷‍♂

d4r1091 picture d4r1091 on 24 May 2019

The same issue still occurs when I am trying to use cocoapods 1.7.0 version.

hamtiko picture hamtiko on 31 May 2019

Morning, I've tried deleting the Pods entirely and readd with the latest 1.7.1 .
I think is definitely something our end (maybe the way we use resigning the apps with Fastlane)

d4r1091 picture d4r1091 on 6 Jun 2019

Ok, after many tentatives and inspections I've found the root issue (or, what, at least to me, it was).

TL,DR
Replace use_frameworks! with use_modular_headers!

For those who want a bit more context:

For some reasons, the latest updates of Cocoapods been having issues with Podfiles using

use_frameworks!

Technically, for a mixed project like the one in my company (having an Obj-C / Swift mixed codebase) which has gotten updates like:

  • Swift 5
  • Xcode 10.2.1
  • CocoaPods 1.7.2

the need of use_frameworks! vanish.
use_frameworks! let use Pods as Frameworks instead of Static Libraries (which wasn't supported in previous versions of Xcode).
Removing that one and replacing with use_modular_headers! restored the full Fastlane's delivery flow.
The above did the trick of course but I've been using this issue to improve the Fastfile and review my signing options as weel.

Hope it will work for you guys! 🚀 💪

d4r1091 picture d4r1091 on 14 Jun 2019
🎉2 👎1

这样修改，是需要修改源代码。这对我来说不可行
In this way, the source code needs to be modified. It's not feasible for me.

xhuihui picture xhuihui on 19 Jun 2019

what changes do you need to apply @xhuihui ?

d4r1091 picture d4r1091 on 20 Jun 2019

I'm facing this issue too and tried all the above but haven't being able to export an archive.

herculesjr picture herculesjr on 24 Jul 2019

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

stale[bot] picture stale[bot] on 22 Oct 2019

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem :+1:

stale[bot] picture stale[bot] on 29 Oct 2019

I have the same issue when put use_frameworks! in Podfile.

Steps:

xcodebuild -project $(PROJECT) -scheme $(SCHEME) clean archive -archivePath $(XCARCHIVE) -configuration $(CONFIG) CODE_SIGNING_REQUIRED=YES PRODUCT_BUNDLE_IDENTIFIER=$(BUNDLE_ID) PROVISIONING_PROFILE_SPECIFIER=$(PROVISIONING) DEVELOPMENT_TEAM=$(TEAM_ID) CODE_SIGN_IDENTITY=$(IDENTITY)

As a result, it will has the error as follows:

❌ error: Alamofire does not support provisioning profiles. Alamofire does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'Alamofire')

And it can be fixed as follows:

config.build_settings['EXPANDED_CODE_SIGN_IDENTITY'] = "" config.build_settings['CODE_SIGNING_REQUIRED'] = "NO" config.build_settings['CODE_SIGNING_ALLOWED'] = "NO"

And then archive is succeed , but when i excute export command as follows:
xcodebuild -exportArchive -archivePath /Users/davidyang/Downloads/ipa/Release-iphoneos.xcarchive -exportPath /Users/davidyang/Downloads/export/ -exportOptionsPlist /Users/davidyang/Downloads/optional.plist

It will has the error as follows:

❌ error: Alamofire.framework does not support provisioning profiles, but provisioning profile 7d2369d6-bed0-4187-a27a-284f79be6d2a has been manually specified. Remove this item from the "provisioningProfiles" dictionary in your Export Options property list.

And I remove the provisioningProfiles key, it will has the error as follows:

❌error: exportArchive: "Runner.app" requires a provisioning profile with the Push Notifications feature.

It seems that the code sign problem goes in a loop. So can anyone help me? Thank you!
@markltownsend @LondonAtlas @bjtitus @jshier @dnkoutso @

DavidYang1121 picture DavidYang1121 on 30 Oct 2019
👍1

I have the same issue when put use_frameworks! in Podfile.

Steps:

xcodebuild -project $(PROJECT) -scheme $(SCHEME) clean archive -archivePath $(XCARCHIVE) -configuration $(CONFIG) CODE_SIGNING_REQUIRED=YES PRODUCT_BUNDLE_IDENTIFIER=$(BUNDLE_ID) PROVISIONING_PROFILE_SPECIFIER=$(PROVISIONING) DEVELOPMENT_TEAM=$(TEAM_ID) CODE_SIGN_IDENTITY=$(IDENTITY)

As a result, it will has the error as follows:

❌ error: Alamofire does not support provisioning profiles. Alamofire does not support provisioning profiles, but provisioning profile {My Profile} has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor. (in target 'Alamofire')

And it can be fixed as follows:

config.build_settings['EXPANDED_CODE_SIGN_IDENTITY'] = "" config.build_settings['CODE_SIGNING_REQUIRED'] = "NO" config.build_settings['CODE_SIGNING_ALLOWED'] = "NO"

And then archive is succeed , but when i excute export command as follows:
xcodebuild -exportArchive -archivePath /Users/davidyang/Downloads/ipa/Release-iphoneos.xcarchive -exportPath /Users/davidyang/Downloads/export/ -exportOptionsPlist /Users/davidyang/Downloads/optional.plist

It will has the error as follows:

❌ error: Alamofire.framework does not support provisioning profiles, but provisioning profile 7d2369d6-bed0-4187-a27a-284f79be6d2a has been manually specified. Remove this item from the "provisioningProfiles" dictionary in your Export Options property list.

And I remove the provisioningProfiles key, it will has the error as follows:

❌error: exportArchive: "Runner.app" requires a provisioning profile with the Push Notifications feature.

It seems that the code sign problem goes in a loop. So can anyone help me? Thank you!
@markltownsend @LondonAtlas @bjtitus @jshier @dnkoutso @

I'm facing the same problem. Were you able to resolve this? Thnx!

gmoraleda picture gmoraleda on 11 Mar 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

hmistry picture hmistry  ·  3Comments
luhui picture luhui  ·  3Comments
marzapower picture marzapower  ·  3Comments
soleares picture soleares  ·  3Comments
intelliot picture intelliot  ·  3Comments