Cocoapods: Unable to find proper solution for code signing errors with use_frameworks! and unique provisioning profiles

[DimaVartanian]

I'm using cocoapods with use_frameworks! (due to a few Swift pods).

My project consists of 1 target, with 4 configurations, 3 with one developer team: Adhoc, Production, Debug, and 1 with another enterprise team: Enterprise. The single enterprise configuration allows us to distribute internally easily. Since one project builds to multiple teams, the "Team" setting is set to None.

Project code signing settings are "Don't Code Sign" for Identity and "Automatic" for Provisioning Profile.

Target code signing settings are "Don't Code Sign" for Identity and then a single unique provisioning profile for each configuration. (e.g. Adhoc > Adhoc, Debug > Debug, Enterprise > Enterprise, AppStore > AppStore)

In general, we don't use wildcard provisioning profiles.

When building for a device in xcode, I am getting code signing errors for each pod. I saw multiple solutions in other threads but they mostly seemed to involve Jenkins/Command line builds and wildcard profiles.

I am able to fix the issue by manually setting an appropriate wildcard provisioning profile on the Pods project. It seems like the solution at the bottom of https://github.com/CocoaPods/CocoaPods/issues/3198 could be adapted to do this for me instead but I'm not quite sure how. Changing the actual code signing identity (as was done in that solution), doesn't do anything for me.

Another fix that seems to work is disabling the code signing on the frameworks altogether:

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"
    end
  end
end

This certainly seems like the easiest fix but I'm not sure what the consequences of this could be. Will my app be rejected?

Anyone have any thoughts on this? It seems like this should be an extremely common use case (and required for pretty much every single app) so it seems like the solution should be really simple here and I am overlooking it.

[neonichu]

This is more of a usage question so probably StackOverflow would be a better place to put it.

I _think_ when you archive/submit your app it will be resigned anyway and the build settings don't apply so much, but you'll have to verify that yourself.

[viktorbenei]

The issue @neonichu (which I think should be tracked as a CocoaPods issue) is that (as @DimaVartanian mentioned) CocoaPods just doesn't work if you use the use_frameworks! feature unless you have a Wildcard Provisioning Profile.

On a developer's Mac this might be expected (to have wildcard prov. profile available) but on a build machine / CI server this will always cause issues, and will require a manual fix (like the one @DimaVartanian included).

If CocoaPods would set the correct code signing parameters (either to don't sign or to the same settings the user uses in the Xcode project settings) when it generates the related pod Xcode projects, it would eliminate a lot of confusion (why is it working on one machine and does not on another one - where no Wildcard Prov. Profile is available) and would not need a manual fix for every project you want to build on a build / CI server (a simple xcodebuild archive or xcodebuild analyze requires proper code signing by default).

[DimaVartanian]

Thanks for commenting. Even if you do use wildcard provisioning, when it comes time to archive your app for release you'll need to use a regular profile and that will cause your build to fail, which will then send you down this rabbit hole I've been on.

This does seem to me like it is not a specific usage problem but rather an issue that almost everyone will experience that should probably be handled from within cocoapods because i don't see a scenario with someone using use_frameworks! where they don't encounter this at some point. The fix I posted above has been working nicely for me with no code signing issues popping up since.

[viktorbenei]

I agree with @DimaVartanian - we get this issue/question about daily at bitrise.io , the solution posted by @DimaVartanian seems to be a reliable fix, but it's never easy to explain why every single projects' Podfile have to be modified for CI.

[AliSoftware]

Have the same issue here. Did anyone tried @DimaVartanian 's workaround (disabling code signing on frameworks) and then tried to submit to the AppStore and get it passed?

[AliSoftware]

Note that @DimaVartanian 's workaround doesn't even work for me, and I know why (and I don't get how it can work for you). The CocoaPods's framework.sh script responsible for resigning every framework is executed by the app target, not by each pod target, so in that context, when the script checks for those three build settings / env var $CODE_SIGNING_REQUIRED etc it uses the one set in the context of running that script, which is when building the app itself.

The post_install hook modifies the setting in the pod targets, but the pods-xxx-frameworks.sh script doesn't care what's set here, instead this script re-signs the frameworks with the same identity as the one used by the app target so if I need to sign my app with a provisioning profile for an com.mycompany.foo AppID, it will resign the frameworks with the same provisioning profile then the installation on device will fail because that PP won't match org.cocoapods.somepod

I can't see a way to workaround this even with a post_install hook modifying the Pods target build settings, as this is hardcoded in that frameworks.sh script which doesn't care about those Pods settings anyway and resign using the app settings instead.

[AliSoftware]

Ok after a whole day on this I figured that using the new -exportOptionsPlist flag of xcodebuild (instead of using the legacy method of generating the enterprise OTA that worked in Xcode 6) the problem disappeared.

[viktorbenei]

I believe you might have a different problem @AliSoftware as for us the issue happens even if we use -exportOptionsPlist and only @DimaVartanian 's fix worked. Or can it be an option included in -exportOptionsPlist which solves this issue?

[DimaVartanian]

@viktorbenei Good to hear the fix worked for you. Were you able to submit to the app store that way? I still have not submitted an app this way but have been successfully distributing adhoc and enterprise builds with it.

[viktorbenei]

Submitting to iTunes Connect / TestFlight works, but we didn't publish any apps to the AppStore.

[scottrhoyt]

+1 For this being a Cocoapods issue and not an edge case with workarounds. I can speak to many days burnt by myself and devs I know trying to deal with this. CI/CD is the most common use case (as it is for me), but it's also not uncommon for devs to do command line builds with explicit signing resources and provisioning profiles when doing client work. Seeing how this keeps popping up for people (e.g. #3800 #3369), we'd love to see an official solution baked into Cocoapod's evolving support for Swift frameworks.

[DimaVartanian]

I'd like to add that I was able to validate and submit my app to the app store successfully using the fix I posted above.

[JMStudiosJoe]

Hello I have been having this issue for a few days now.
My configuration is 0.39.0 with Xcode 7.2 iOS 9 with iPad. I am trying to run my project with an enterprise license and provisioning profile. I have gone through my keychain several times deleting keys recreating them and re doing all the appIDs, certificates and provisioning profiles within member center. I am out of ideas, please help, thank you in advance.

I have tried to post_install hook with no luck, here is the screenshot of the error I am getting

Screen shot of Pods->build settings -> User defined which I am assuming happens from the post_install script.

I have followed the other threads with no luck. I have also searched my entire workspace for the Distribution.PulseMD identifier but cannot seem to find it. I have deleted derived data over and over with no luck.

[jpmcglone]

Any updates on this? I seem to be having this issue..

[gtchance]

+1 - I'm having this issue as well.

[jcampbell05]

+1 - Just had this bug, we need a good solution for this!

[noscio]

Here too!

[jcampbell05]

Bite the bullet and just made sure my profiles were up to date via match codesigning.guide - not a fix but it is good practice. :)

[segiddins]

Instead of +1s, a PR improving things would be appreciated ;)

[jcampbell05]

Do we know what causes the exact issue ?

[iblacksun]

My project can build success, run on iOS devices and submit to App Store.
When upload to App Store, frameworks Provisiong Profile is 'None'

My pod file:

target 'Aspirin' do
    aspirin_pods
    kit_pods

    post_install do |installer|
        installer.pods_project.targets.each do |target|
            target.build_configurations.each do |config|
                config.build_settings['ENABLE_BITCODE'] = 'NO'
            end
        end
    end

end

After approve by Apple, i got some crash log said Aspirin: Dyld Message: Library not loaded: @rpath/SwiftyJSON.framework/SwiftyJSON

The not loaded frameworks are randomly, after communication with ADTS, they said:

https://developer.apple.com/library/ios/qa/qa1814/_index.html#//apple_ref/doc/uid/DTS40014030

I can fix my project's code singing as above link documented, but how can i setting it for CocoaPods framework?

[mgrebenets]

We are having this issue right now and disabling code signing for frameworks in post install hook is not a full solution. Since frameworks are not signed, we can't install the enterprise distribution build via Hockey App.

AppStore is a different story, because for AppStore we use in-house scripts similar to sigh resign which changes all Info plists directly and patches up the bundle IDs.

But the IPA we get from xcode archvie + exportArchive can't be installed, because we deliberately disabled framework signing via the hook.

Ideally, we'd like to get properly signed IPA from Xcode directly, but we are resigning our builds with a wildcard profile, the wildcard is like this com.company.*, while CocoaPods generates org.cocoapods.* bundle IDs.

If only CococaPods would provide us with the way to specify custom prefix for frameworks, we'd have no issue, we'd just choose the prefix to match our wildcard profile.

[orta]

Did you look at making a a CocoaPods plugin that specifies a custom prefix?

[mgrebenets]

I'd think of that, can't promise any commitment though, since the original problem we've got is "solved" by additional sigh resign pass after the build.

This looks like a good starting point: https://blog.cocoapods.org/CocoaPods-0.28/, what is the good reference for the APIs mentioned there? Or probably an already existing plugin which is a good reference for new starters?

On the other note, could bundle IDs be changed as part of post install hook?
For example loop through all targets and all configs and patch up config.build_settings['PRODUCT_BUNDLE_IDENTIFIER'].
Or is it exactly what the hook would do?

[orta]

pod plugins create [name] will generate a stubbed plugin, you can find a lots of plugins here - I'm pretty certain Keys, Rome and probably Deploy use post-install hooks.

But yeah, I can't see why that wouldn't work, I mean, I don't know the underlying principals of your problem, but it's all just xml in the end.

[emkou]

quite tired of this Bug, nothing seems to be a good solution on my Travis CI server with cocoapods.
the post_install do |installer| works for now but it is not the optimal solution in this case.

[kurko]

@DimaVartanian's solution didn't work for me. My error is slightly different but I believe its cause is the same as this issue.

[mgrebenets]

@kurko

That fix doesn't address the root cause - bundle IDs for generated pods have org.cocoapods prefix.

The patch/workaround that works for me is to update bundle identifiers of all pods in post-install hook:

# CocoaPods framework bundle ID prefix
def cocoapods_prefix
  "org.cocoapods"
end

# Custom framework bundle ID prefix
def custom_prefix
  "com.mycompany.myapp"
end

# Patch bundle ID in a file
def patch_bundle_id(file)
  contents = File.read(file).gsub(cocoapods_prefix, custom_prefix)
  File.open(file, "w") { |file| file << contents }
end

# Post-install hook
post_install do |installer|
  puts "Update debug pod settings to speed up build time"
  Dir.glob(File.join("Pods", "**", "Pods*{debug,Private}.xcconfig")).each do |file|
    patch_bundle_id(file)
  end

  # Path CocoaPods targets build settings
  puts "Patch dynamic frameworks product bundle identifiers"
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      patch_bundle_id(config.base_configuration_reference.real_path)
      if config.build_settings["PRODUCT_BUNDLE_IDENTIFIER"]
        config.build_settings["PRODUCT_BUNDLE_IDENTIFIER"] = config.build_settings["PRODUCT_BUNDLE_IDENTIFIER"].sub(cocoapods_prefix, custom_prefix)
      end
    end
  end
end

It modifies PRODUCT_BUNDLE_IDENTIFIER in all generated xcconfig files and in generated Xcode project XML.

Make sure you put your main app prefix instead of "com.mycompany".

[psmolen]

I'm also seeing this issue, but we have an explicit bundle ID for push notifications. None of the solutions here work when building via CI

[kurko]

@mgrebenets that didn't work, but thanks for sharing. I figured that no .xcconfig file had PRODUCT_BUNDLE_IDENTIFIER, so I wasn't even sure why a Bundle ID was being set for the Pod. Fortunately, after a lot of back and forth, I was able to fix this. I posted the answer in https://stackoverflow.com/questions/36511359/xcode-trying-to-match-frameworks-bundle-id-when-uploading-ios-app-to-app-store/36803820#36803820 (which includes more details and screenshots).

[mgrebenets]

@kurko That makes perfect sense. We haven't yet resigned for App Store distribution, for Enterprise we used wildcard provisioning profile com.mycompnay.*, so it all worked.

To make the solution I suggested work for App Store as well, you only need to change com.mycompany to com.mycompany.myapp. This is still better than changing Pods project target manually. Every time you run pod update or pod install you lose all those changes.

[fsosa]

Just wanted to check in and see if there was any progress on this. This bug essentially makes it so that CI builds using Jenkins can't be pushed directly to HockeyApp, because code signing is required for the frameworks.

Any updates would be really appreciated! 😄

[seanhaufler]

I've tried all of the above solutions and none of them work for me when uploading to the App Store.

After I add the post_install hook to the Podfile, I successfully change the PRODUCT_BUNDLE_IDENTIFIER of each of the Pods to com.mycompany.myapp.<podname>. The archive succeeds, as expected. However, when validating the archived build, it fails with the same error as posted in the screenshot by @kurko above, except the message reads: No suitable application records were found. Verify your bundle identifier 'com.mycompany.myapp.Alamofire' is correct.

I believe my app store provisioning profile only covers the identifier com.mycompany.myapp, so even if the pod identifiers follow com.mycompany.myapp.<podname>, it still results in a validation error.

My app has in-app purchases, so a wildcard provisioning profile cannot be used.

Would appreciate any advice or suggestions. Is there anything I'm missing? Thanks to @kurko for your helpful advice thus far!

[polaski]

I totally appreciate the very existence of Cocoapods and I don't want to be that guy to complain about features, but I feel like this is really critical problem for Cocoapods, especially going forward where a lot of people may be using both swift and objective-c libraries for a single project.

Has anyone come up with a simple solution for this yet? (Including the appstore approval process)

[942v]

I have the exact same problem as @seanhaufler. I'm trying to distribute a project that uses use_frameworks!, I can't use a wildcard because I need to use Push notifications. I'm getting the same error when I try to submit the archived version to ITC.

The post_install scrip is not working for me and I'm out of ideas 😕

[mgrebenets]

I can now confirm that App Store release worked for us.
We've just released an update for the our yesterday. This was the first version using Swift dynamic frameworks (the use_frameworks! option in Podfile).
We used CocoaPods 1.0.0 and the post-install hook I described earlier. We replaced all "org.cocoapods" with "au.com.company.app".

We only had a hiccup with code signing, because our build scripts were specifying PROVISIONING_PROFILE for xcodebuild for initial build. This way we had embedded.mobileprovision file added for all .framework directories inside the app. This caused issues with iTC validation. The errors looked like this:

ERROR ITMS-90159: "Invalid provisioning profile. This app contains an embedded provisioning profile that is not associated with your account. Please use a provisioning profile associated with Team ID TEAM-ID."

ERROR ITMS-90578: "Invalid Provisioning Profile. The UPP provisioning profile included in the bundle au.com.company.app [TheApp] is disallowed."

ERROR ITMS-90179: "Invalid Code Signing. The executable 'Payload/TheApp.app/Frameworks/AFNetworking.framework/AFNetworking' must be signed with the certificate that is contained in the provisioning profile."

After addressing this problem though, we successfully uploaded the app and then released it to store.

[mgrebenets]

After re-reading the original issue in this thread, I tend to believe that using explicit provisioning profile _may_ be the issue.

The original text says

Target code signing settings are "Don't Code Sign" for Identity and then a single unique provisioning profile for each configuration. (e.g. Adhoc > Adhoc, Debug > Debug, Enterprise > Enterprise, AppStore > AppStore)

The part I highlighted in bold may be the root cause. Setting profile like this is same as specifying explicit PROVISIONING_PROFILE option to xcodebuild. The issue here is that xcodebuild will use this provisioning profile for _all_ nested apps, extensions as well as dynamic framework bundles. An easy way to verify it is to look inside MyApp.ipa/Payload/MyApp.app/Frameworks/SomeFramework.framework directory and see if embedded.mobileprovision is sitting there.

As soon as Apple added extensions and nested apps (e.g. WatchKit apps), using explicit profile became an issue for us. From my personal experience, I ended up with the following rule: _Do not specify provisioning profile explicitly ever, leave it as Automatic. Instead, specify signing identity for all CI jobs._

There is kind of unspoken rule in iOS devs community: "never trust Xcode", but I find that this is the case where it's worth a try. I trust Xcode to pick correct provisioning profile for main app, each nested app and extension based on the combination of singing identity and bundle ID. What's more important, this way Xcode _will not_ embed this profile into framework bundles. To make sure it doesn't pick up some outdated or garbage profile, I keep my dev machine and CI servers clean and up-to-date using tools like fastlane (i.e. sigh and match).

We also double check all resigned IPAs for embedded profile and code signing entitlements before submitting to iTC. There's room for improvement and this validation step could be automated with a script.

If you are using fastlane sigh resign action, these 2 issues may be related:
https://github.com/fastlane/fastlane/issues/5669, https://github.com/fastlane/fastlane/issues/4397

[Abhishek9634]

Hello I'm getting this issue. I have created cocoapod of my framework project in objective -c. For the cross check i have installed in demo project and i'm facing this issue

[tgebarowski]

For all who struggle with the same problem (framework signing issues and app being rejected during validation).
Modifying Bundle ID of frameworks to prefix them with app's Bundle ID seems to work only when you are using wild card provisioning (*)
This will not work when you are using Push Services or In-App purchases in your app. Secondly modifying Bundle IDs in post_install step is probably not something you would like to do.

It seems that when you build your project directly in Xcode it works. The reason is that you have to manually pass -exportOptionsPlist parameter to xcodebuild. Inside the plist file, which path you are passing, you have to specify at least one key value mapping method => app-store

Exemplary content of plist, for AppStore/Testflight submission can look like follows. The same should work for adhoc builds, where "ad-hoc" value should be passed under method field.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>uploadSymbols</key>
    <string>NO</string>
    <key>compileBitcode</key>
    <false/>
    <key>uploadBitcode</key>
    <false/>
    <key>method</key>
    <string>app-store</string>
</dict>
</plist>

I hope that it helps.

Cheers,
Tomasz Gebarowski
twitter: @tgebarowski

[rringham]

Is there updated guidance around this? I'm also struggling with this, and as a result, I'm afraid I'm going to need to drop use of CocoaPods until there is a better, straightforward, official solution in place. In my situation, I need to deploy via Enterprise distribution, need to support CI/CD build & deploy, and I am not able to move to a wildcard app ID. This specific issue means CocoaPods does not look viable as a dependency management solution for our needs, unfortunately.

[ejebleed]

Any more solutions around?

Seeing the same issue here.
When building:
Code Sign error: Provisioning profile does not match bundle identifier: The provisioning profile specified in your build settings (“MyDistributionProfileName”) has an AppID of “com.myorg.myapp” which does not match your bundle identifier “org.cocoapods.PureLayout”.
Note! PureLayout is added to my pod as a dependency using s.dependency 'PureLayout', '3.0.2'
This is the whole podspec file of my Pod:

Pod::Spec.new do |s|
  s.name                = 'MyPod'
  s.version             = '1.2.34'
  s.license             =  { :type => "MIT", :file => "LICENSE" }
  s.homepage            = 'https-:-//bitbucket.org/XXXX123/my-pod'
  s.authors             = { "AuthorName" => "[email protected]" }
  s.summary             = 'This isa a cocoa pod that contains the MY framework.'
  s.source              = { :git => "https-:-//bitbucket.org/XXXX123/my-pod", :tag => "#{s.version}" }
  s.ios.deployment_target = '8.0'
  s.source_files        = 'MyPod/**/*.{swift,h}'
  s.resource = 'MyPod/*'
  s.pod_target_xcconfig = { 'ENABLE_BITCODE' => 'NO', 'ONLY_ACTIVE_ARCH' => 'NO'}
  s.dependency 'PureLayout', '3.0.2'
end

1) Dropping use of CocoaPods is not an option.
2) Using the @DimaVartanian fix leads to similar errors like encountered by @mgrebenets
ERROR ITMS-90035 _Invalid Signature. Code object is not signed at all. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose "Clean All" in Xcode, delete the "build" directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html"_
ERROR ITMS-90171 _Invalid Bundle Structure - The binary file 'XApp.app/Frameworks/X.framework/XView.o' is not permitted. Your app can’t contain standalone executables or libraries, other than the CFBundleExecutable of supported bundles. Refer to the Bundle Programming Guide at https://developer.apple.com/go/?id=bundle-structure for information on the iOS app bundle structure._

3) My project uses also PushNotifications so can't use any wildcard provision profiles.
4) Here's my gym line for building a build
gym --clean --scheme ${XCODE_PROJECT_TARGET_NAME} --configuration Release --include_bitcode false --archive_path ${BUILDS_DIR}${PACKAGE_NAME}.xcarchive --output_directory $BUILDS_DIR --output_name "${PACKAGE_NAME}.ipa" --xcargs PROVISIONING_PROFILE=$APP_PROVISION_UUID
this line works wo any errors when @DimaVartanian fix is applied, but as I said before, it leads to ERROR ITMS-90035 and ERROR ITMS-90171 during upload process.

Here's my pilot line for uploading a build:
pilot upload --skip_submission --username ${APPLE_ID_USERNAME} --team_id ${APPLE_ITUNES_CONNECT_TEAM_ID} --verbose --ipa ${BUILDS_DIR}${PACKAGE_NAME}.ipa --skip_waiting_for_build_processing true
5) I can confirm that same issue exists when build/archive/upload using xcode.

6) As suggested by @tgebarowski - Adding this --export_options "ExportOptions.plist" to gym commandline, did not make any difference. Also failed by trying via xcargs --xcargs "PROVISIONING_PROFILE=$APP_PROVISION_UUID exportOptionsPlist=$EXPORT_OPTIONS_PLIST"Contents of the file is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
   <key>teamID</key>
   <string>TEAMID123</string>
   <key>uploadSymbols</key>
   <string>NO</string>
   <key>compileBitcode</key>
   <false/>
   <key>uploadBitcode</key>
   <false/>
   <key>method</key>
   <string>app-store</string>
</dict>
</plist>

Btw! These keys in ExportOptions.plist file looks like making sense only for uploading process not for building process, so it sounds like it makes sense why it had no effect.

I'll keep researching on this, but any help is appreciated.

This issue should be labeled as Critical or to whatever makes CocoaPods team to fix it ASAP.

To say in short - what fails is the end of following sequence:

• 
  
  1. Create base project in Objectvie-C or take any old maintained Objective-C project
  
  
• 
  
  1. Create and implement a framework _(Cocoa Touch Framework)_ project in Swift
  
  
• 
  
  1. Create podspec for that framework and upload it to repository
  
  
• 
  
  1. Include that framework into base project using CocoaPods
  
  
• 
  
  1. Build and run app on simulator and on wired device is OK _(everything works as expected)_
  
  
• 
  
  1. Build and/or Upload to iTunesConnect is NOT OK, it FAILS!
  
  

What else is to say here? CocoaPods Team, please fix this issue. CocoaPods are simply not working here and it is a real show-stopper. Has been around for almost a year already and not even labeled. Please fix your product or at least help us to find some reliable workaround.

[ejebleed]

I've created an issue on current topic also on StackOverflow, please support!
http://stackoverflow.com/questions/39160654/signing-errors-with-use-frameworks-and-unique-provisioning-profiles
Just to let this issue more out of shadows.

[ejebleed]

OK I've found the solutions for my case.
Added it as an answer here:
http://stackoverflow.com/questions/39160654/signing-errors-with-use-frameworks-and-unique-provisioning-profiles/39182887#39182887

In short the @DimaVartanian 's workaround + a little fix on resource inclusion made the way through the pain.

That still is not yet an official solution. It's a workaround. Hopefully this will be fixed in XCode 8 as rumours claim.

[mgrebenets]

@ejebleed So part of the issue was incorrect podspec?

How did you fix the first part where it complained about missing code signing?
Our first try was to disable code signing too, but then it didn't work properly with our CI: we couldn't install resulting builds to physical devices neither from HockeyApp nor directly via Xcode organizer. We got error about it not being properly code signed.

So we had to tweak the bundle ID and now it works like a charm, though doesn't work for others.

[ejebleed]

Yes, unfortunately yes, the second part of the issue was caused by bad podspec instructions. Accidental inclusion of whole folder contents instead of specific required files.
I would even recommend to use s.resources instead of s.resource.
With s.resources you can specify an array of strings as a value.
Like this: s.resources = ['MyPod/Graphics.xcassets', 'MyPod/some_other_required_resource_file']
So you can explicitly see what is included and what is not.

For the first part where it complained about missing code signing I used that workaround in Podfile. That disabled codesign requirement for all pod targets and worked well for me.

@mgrebenets , I don't know why it did not work for you. Maybe you can try to trace with puts and see if that workaround finds any targets from your project structure.
Just set somehting like puts "Disabling Code Sign" just next to these _config_ lines:

config.build_settings['EXPANDED_CODE_SIGN_IDENTITY'] = ""
config.build_settings['CODE_SIGNING_REQUIRED'] = "NO"
config.build_settings['CODE_SIGNING_ALLOWED'] = "NO"
puts "Disabling Code Sign"

You should see that in your output somewhere if it does.
Another thing that may be possible, is to check your CI's permissions to access your project files. Maybe they are readonly or smth and thus not modified.
Third thing to check on CI is how your Pods are created. Some developers like to put pod projects into base repository, which is a bad idea. CI should definitely be able to access your project files if it has been created by CI itself(pod install inside CI).

Aside of all that, I'm betting on XCode 8, where this issue should be handled somehow. (that would be an official fix then). Perhaps someone could find some official confirmation on this.

[ejebleed]

Btw! A little additional feature would be still nice to have from Cocoapods Team.
Related to current issue, pod spec lint command could check the value of the s.resource directive and at least warn if the specified path contains some unusual resource files(like _*.swift_ files in my case).
That would let developer know if something is wrong already within early stages of development not when it is about to uploading the finished app to app-store.

[kmikael]

@mgrebenets's patch/workaround worked well for us after a few changes. We have 2 targets, and including betas and alphas some serious scripting was needed, but with the help of fastlane and many lines of Ruby, it worked and I was sen able to submit to iTunes Connect and download through TestFlight.

[alphastryk]

This still appears to be an issue, and none of the above workarounds appear to be working for me. Has anyone done more work around this?

[GoodMirek]

@alphastryk I install wildcard provisioning profile and perform "xcodebuild build archive" with that wildcard provisioning profile. Then, I delete the wildcard provisioning profile, install unique provisioning profile and perform "xcodebuild -exportArchive", which uses that unique provisioning profile. All is done automatically on CI build agent, using fastlane is a huge help.

[alphastryk]

@GoodMirek Thanks, I'll give that a try. This all still feels very hacky, and I wish there was a better answer.

[viktorbenei]

If you can archive the project on your Mac then you can try to run https://github.com/bitrise-tools/codesigndoc - it can collect all the signing files for you, the ones Xcode uses during an archive on your Mac.

[perryprog]

Uploading my first app. Not really sure exactly what I'm doing, (at all), and I am not using any CI — I'm doing it all from within Xcode 8.

I've tried mostly every solution in here. Is there some updated version I should be using, now that there are new versions of Coccoapods and Xcode. GH Project: http://github.com/germantownacademySOS/GASOS (you won't be able to run it — you need special hardware)

[stale[bot]]

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.

[perryprog]

RE @probot-stale[bot] (BTW, I didn't know this bot existed, it's a really good idea) I fixed this by regenerating my code signing certificate.

[stale[bot]]

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]]

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: