Cocoapods: [Catalyst] Podspec Resource Bundle requires a development team

Created on 7 Jun 2019  路  14Comments  路  Source: CocoaPods/CocoaPods

Podspec resource bundles now require a development team / signing identity. I think this only affects static libraries with resource bundles and not when the resources are bundled within a framework.

I will take a look at the Pods project diff to see what keys need to be added and update this issue. Maybe this will require an update to the Xcodeproj gem?

Default after pod install

Screen Shot 2019-06-05 at 10 51 00 PM

Screen Shot 2019-06-05 at 10 52 50 PM

Manually modified Pods project resolves the issue

Screen Shot 2019-06-05 at 10 53 04 PM

_Originally posted by @chrisballinger in https://github.com/CocoaPods/CocoaPods/issues/8877#issuecomment-499359485_

Workaround

Workaround available by Podfile hack here: https://github.com/CocoaPods/CocoaPods/issues/8891#issuecomment-546636698

confirmed

Most helpful comment

This is probably a better way to fix it, without specifying the team id.

post_install do |installer|
    installer.pods_project.targets.each do |target|
        # Fix bundle targets' 'Signing Certificate' to 'Sign to Run Locally'
        if target.respond_to?(:product_type) and target.product_type == "com.apple.product-type.bundle"
            target.build_configurations.each do |config|
                config.build_settings['CODE_SIGN_IDENTITY[sdk=macosx*]'] = '-'
            end
        end
    end
end

All 14 comments

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.

Still not resolved as macOS 10.15 is already released.

Here is a Podfile hack workaround:

def fix_config(config)
  # https://github.com/CocoaPods/CocoaPods/issues/8891
  if config.build_settings['DEVELOPMENT_TEAM'].nil?
    config.build_settings['DEVELOPMENT_TEAM'] = '<YOUR TEAM ID HERE>'
  end
end

post_install do |installer|
  installer.generated_projects.each do |project|
    project.build_configurations.each do |config|
        fix_config(config)
    end
    project.targets.each do |target|
      target.build_configurations.each do |config|
        fix_config(config)
      end
    end
  end
end

This workaround might not actually work after all. Although it builds and runs locally after the fix, the binary is not accepted by App Store Connect, and is rejected with code ITMS-90284 "Invalid Code Signing".

ITMS-90284: Invalid Code Signing - The executable 'Example.app/Contents/Resources/ExamplePodBundle.bundle' must be signed with the certificate that is contained in the provisioning profile.

Someone else posted about this issue here: https://stackoverflow.com/questions/58547010/ios-catalyst-cocoapod-framework-error-signing-requires-a-development-team

I submitted a radar FB7425571 because I really don't know how to fix this. It seems that resource bundle targets aren't compatible with Mac Catalyst App Store builds at all. It works just fine when running locally exported via Developer ID.

So far it seems the only workaround is to remove all resource bundle targets, which might be a big issue especially because they are "strongly recommended" in the podspec docs: https://guides.cocoapods.org/syntax/podspec.html#resource_bundles

Another workaround is to create exported archives of the resource bundles and then include that version instead.

@chrisballinger you can try set 'Signing Certificate' to 'Sign to Run Locally'. like this

This is probably a better way to fix it, without specifying the team id.

post_install do |installer|
    installer.pods_project.targets.each do |target|
        # Fix bundle targets' 'Signing Certificate' to 'Sign to Run Locally'
        if target.respond_to?(:product_type) and target.product_type == "com.apple.product-type.bundle"
            target.build_configurations.each do |config|
                config.build_settings['CODE_SIGN_IDENTITY[sdk=macosx*]'] = '-'
            end
        end
    end
end

Relatedly, adding the option CODE_SIGN_IDENTITY='-' is a workaround for xcodebuild invocations.

Adding CODE_SIGN_IDENTITY[sdk=macosx*]='-' would be a relatively straightforward change on the CocoaPods side - if this is the _correct_ way to do it than we can move forward with that

Automatically signing to run locally is the right fix for local development. I'm not sure about deployment.

Won't Xcode re-sign when exporting archives?

Just to confirm settings for deployment through the appstore:

Setting a team manually, and setting signing certificate 'development' results in the archive being signed by XCode and uploading to the store, but being rejected during processing with:

ITMS-90284: Invalid Code Signing - The executable 'Off.app/Contents/Frameworks/Material.framework/Versions/A/Resources/com.cosmicmind.material.fonts.bundle' must be signed with the certificate that is contained in the provisioning profile

Setting a team manually, and setting signing certificate 'sign to run locally' uploads correctly and results in a build that I can select for release in appstore connect.

So it's sounding like the CODE_SIGN_IDENTITY[sdk=macosx*]='-' works for development but not uploading to the App Store.

This is a bit problematic since we'll now need to pull the development team ID from somewhere. We can add code to infer it from the project but we may need new DSL for specifying it within the target block in the Podfile

Was this page helpful?
0 / 5 - 0 ratings

Related issues

iosdev-republicofapps picture iosdev-republicofapps  路  3Comments

steffendsommer picture steffendsommer  路  3Comments

spencerkohan picture spencerkohan  路  3Comments

lzwjava picture lzwjava  路  3Comments

marzapower picture marzapower  路  3Comments