Im able to submit my app through Xcode 6.3.2 perfectly fine. Validation and analyzing pass perfectly. Once it successfully submits to the app store though I get an email from Apple:
"Dear developer,
We have discovered one or more issues with your recent delivery for "App". To process your delivery, the following issues must be corrected:
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
Once these issues have been corrected, you can then redeliver the corrected binary."
I have tried redownloading the distribution cert, regenerating the distribution provisioning profile, added "--deep" to the code signing "Other Code Signing Flags." I even checked the bundle name etc, everthing is alpha numeric. I was able to submit fine on May 22nd, now on June 3rd everything breaks.
Doesnt make any sense, any help would be appreciated!
UPDATE & SOLUTION:
While I don't have a good explanation of why this suddenly has happened within the last week, I finally found a solution this morning.
I started with a new project and submitted to the app store with nothing but the identifier and correct version and build numbers, which processed fine. After that I started piecing in any assets that wasnt my own code until I got the "Invalid Binary" email. I narrowed it down to the Hockey App SDK (embedded framework) which was causing the issue and not even being used anymore so I removed it from the project (problem solved). The disturbing part is that nothing fails on my end during validation or submission and according to github this directory and content hasn't changed in a year, which leads me to believe something changed server side at Apple.
I did see a lot of posts via google saying that frameworks needed signed etc and when using Xcode 6 and iOS 8 it seems to be the standard which is why I assumed it might be something along these lines.
Im not sure how helpful this is as I was building for iOS and this article is in reference to Mac, but HockeyApp explains in order to distribute to the app store you need to sign the framework with your own identity here:
http://support.hockeyapp.net/kb/client-integration-ios-mac-os-x/hockeyapp-for-mac-os-x
If anyone has anymore technical notes on this or why this suddenly changed Id love to understand this better.
I've checked a variety of places and there seem to be several things that are now being rejected by iTunes Connect. The solution is typically to remove the offending resource from the Target -> Build Phases -> Copy Bundle Resources (as #azizus mentions). Unfortunately Apple doesn't tell you what file causes this issue with your builds so you have to go hunt for yourself. Here are some items that I've found that will do it:
Shell scripts (Look for .sh files, though they could have a different
extension)
Also, look out for files that are listed as executable, when they
shouldn't be. Those might be a good place to look for shell scripts
that you might have missed.
Frameworks (Framework bundles, even .a or .o files - you
don't need them as they will get compiled into the executable binary)
DocSets (I don't know why, but I found that the HockeyApp SDK
includes a DocSet bundle which was the cause in my experience)
Sometimes this might also happen due to some weird entitlements
issue. The entitlements you have may not match up with the App in the
provisioning portal.
Look out for invalid characters in your app name or file names (like
wildcard characters)
This is a pretty broad list, something I did to help in the search is build an archive and then show the contents of the .app in the archive using finder, sorting by file type. The strange thing is that these files actually exist in the _CodeSignature/CodeResources file.
My own theory on why this is happening is that Apple made some changes (or is making some changes) because of Extensions and WatchKit apps. Essentially, you are including a couple of binaries in the packaged IPA (phone app, extension, watch app). They probably want to make sure you're not including something else that could potentially be executed. Unfortunately, the error message is too vague (really it's incorrect) for most.
This took me 3 days to debug.
In the end it was due to an external framework I created (lets call it X) that I was importing via carthage. X had its own dependencies that it was importing via carthage as well. In order to link these frameworks it had a path in the build settings called Framework Search Paths set to the location of the frameworks. For some reason it was this flag in this framework that was causing the problem specified in the questions. I eventually imported X's dependencies with Git submodules so that I didn't have to set the Framework Search Paths flag. I the exported the framework and manually added it to my project I was submitting to the AppStore. Then it worked.
I can reproduce this when I 'create folder references' for my resources folder as opposed to 'create groups' when adding in.
I contacted HockeyApp and they suggested not to add the SDK to app bundle. So I navigated to Target -> Build Phases -> Copy Bundle Resources and removed HockeySDKResources.bundle from there. iTunes Connect accepted my binary.
In my case it was a info.plist duplicated that was not used. (it wasn't easy find out the problem). I removed almost all the files of my project until remove this one and.. it worked
Clearing the value for Code Sign Resource Rules Path in each target resolved the issue.
I've got an issue with how PhoneGap:Build is currently building iOS applications: splash screens are duplicated, greatly increasing the compiled file size of my applications.
Previously they had an issue wherein they were copying the wrong icon into the Android XHDPI icon folder for Android builds, and I was able to write a script that automated fixing this bug post-build since they seemed to show no interest in fixing the bug (almost a year now since the original bug report & while it seems it might be fixed presently, they haven't commented lately).
I know that I can rename an IPA to a ZIP, unzip it, and browse its contents. I could automate the following steps easily:
Rename
Unzip
Find & remove originals for splash screen images via config.xml file
Re-zip (& rename?)
...But I'm not sure where I'd have to go from there. I've found a few threads that discuss using Xcode to run different utilities, perform signing, etc; but they all seem to assume you've got an xcode project locally, which I don't. (I use PhoneGap & PhoneGap:Build specifically to avoid those headaches.)
I'll have access to all of the same key files that are uploaded to PhoneGap:Build for the original signing process, and I know all of the necessary passwords. I have Xcode installed (just not a local xcode project)...
Is it possible to re-assemble a "fixed" zip into a signed IPA for dev/release distribution using command line utilities & without creating a local Xcode project? If so, how?
Yes, this is possible.
You can export an IPA, unzip it, delete the duplicate file (assuming your code doesn't reference it), then re-sign the app and zip the IPA back up.
You'll find examples on how to use the commandline tool "codesign" to resign a .app directory on stackoverflow!
Im getting this awful and weird error when having selected an ad hoc distribution certificiate in Xcode in the Distribute for Ad Hoc section. Anyone know how to fix this error? :-)
Thanks!
I just fixed the same error in my project. I'll explain the fix, and I'd love to know if it helps.
I had just added the YAJL library to my iOS project. The problem was that I had followed the Mac OS X instructions, rather than the iOS. The Mac OS X instructions include the creation of a Copy Files Build Phase, that copies the YAJL.framework/ folder to the .app bundle.
This is a huge mistake.
Now, what does a framework folder look like inside? It looks like this:
See those symbolic links? (The files with the curvy arrows) They are the culprits. Delete all of those out of the .app folder, and I was able to save the .ipa file with no trouble at all. Actually, you don't need the .framework/ folder in the app bundle at all. That should be compiled into the binary.
So, check your .app file. Are there any weird folders that don't need to be there? Are there any symbolic links hanging around?
I had the same issue, but in the Mac world. It turns out that removing the symbolic links is only tricking the archive tool, and it doesn't really produce a valid result. This error usually happens if one of your embedded frameworks has a bad Info.plist file.
But yes, in an iOS app you can't have embedded frameworks so you should be linking against a static library.
After installing Xcode 4.3 I can't validate and distribute application using Organizer.
While building, signing and validating in Xcode is OK, the validation in Organizer fails with the message in the title of this question.
First, Xcode 4.3 can download provisioning profiles automatically (there's an option in Organizer), but it downloads only development profiles and ignores distribution profiles as if there are none. OK, I downloaded and installed it manually and it appears in Organizer. Then I set proper Code Signing Identity both for project and for target and use Distribution profile that matches Distribution certificate in my keychain. Then I do Archive (build-sign-verify) and no errors, in the log I see green checkmarks for CodeSign and for Verify steps. Looks good and the archive appears in Organizer.
And that's where all goes wrong, I just select Validate, choose the new version I just prepared in iTunes Connect, choose correct code signing identity, same as was used for Archiving (actually, there are no other choices in my case), it asks for iTunes login/password as usual, and then says
Codesign operation failed
Check that the identity you selected is valid
Ahhh!!! Why!? It had no problems while archiving it, then same code signing doesn't work when trying to submit to AppStore. Well, not even submit, but validate before actually sending it. So this issue is local to my machine. The very same signing and validation that is successful during build, fails in Organizer...
I tried everything, re-installed Xcode, removed/revoked and re-issued all certificates, removed duplicated private and public keys from keychain, put all certificates in one "login" keychain, issued new profiles, installed Application Loader 2.5.1, and so on... still no luck.
Could it be that I have some left-over from previous Xcode installs? Or that I have to update some tools to make Organizer work properly?
Meanwhile, if anyone knows another way to upload binary to AppStore, please share. I couldn't figure out how to do that using Application Loader, when it asks me to choose a bundle to upload, all I have is xcode archive created by Xcode in Archive step. How do I get my hands on iap or whatever file the Application Loader wants from me?
I've discovered that Xcode 4.3.1 has a serious issue validating apps with resources within a directory tree within an application bundle.
Apps can pass validation within the Xcode "Build for Archive" process - it only fails when the validation is run via Organizer.
After spending hours trying to trace down the usual code signing entitlement issues, I eventually noticed the following line in the system console when the export fails:
3/10/12 2:32:48.450 PM [0x0-0x261261].com.apple.dt.Xcode: /Users/chris/Library/Developer/Xcode/Archives/2012-03-10/Coverage 3-10-12 2.32 PM.xcarchive/Products/Applications/Coverage.app/Tiles/T-Mobile-roam/4: Is a directory
I spent a day trying to isolate this bug, and I've finally nailed it.
The code signer in XCode 4.3.1 when validating for the App Store or saving for AdHoc distribution chokes whenever there is a subdirectory in your bundle that has the same name as its parent directory.
For example:
test/test/file.x -- FAIL
test/test2/file.x -- WORKS
This seems to be new in Xcode 4.3.1, and hopefully will be fixed soon.
Notes: This thread seems related: https://devforums.apple.com/message/630800
I was the original poster on the Apple Dev Forums...
https://devforums.apple.com/message/621193
I've also attempted to bring this to the attention of the AddThis developers:
https://www.addthis.com/forum/viewtopic.php?f=19&t=38292
As mentioned in the other posts, the only way I've found to prevent the code signing failure is to remove the ATResources.bundle file from the project.
Of course, this bundle contains many of the necessary images for AddThis, among other things, but the error no longer occurs.
I'm hoping this helps someone else discover the correct way to solve this issue.
The problem is AddThis or explicitly the ATResources.bundle in the AddThis folder.
So you have two options:
The first one is using an older version of Xcode to Archive.
The second one is relocate all the images inside the
ATResources.bundle into a folder, and copy the content of the
Localizable.strings into your own Localizable.strings
Then open the FBDialog.m file and search for "close.png", remove that
line of code and replace it with:
UIImage* closeImage = [UIImage imageNamed:#"close.png"];
Now you're ready to Archive.
Finally consider to file a bug report in https://bugreport.apple.com/
In my case, it was a damaged custom framework.
I have so many subdirectories on my bundle that have the same name as their parents, so I was not able to validate and submit. The only solution I found is to download xcode 4.2.1 from Apple developer center and install it side by side with xcode 4.3.2. Then I used it to validate and submit.
I'm developing on Sencha 2. The key here is to launch the System Console from Apps/Utilities and look at the error log when distributing. That's the easiest way to see the offending directory. In Sencha2 its in the /sdk/src/device/device. Good stuff: Still happening in xcode 4.3.2
Just confirming that the problem was indeed nested folders with the same name in my app.
In my particular case this was the issue:
problem: images/packs/1/1/img.png
solution: images/packs/pack_1/1/img.png
Smooth sailing after that. This happened in Xcode 4.3.3
found the solution, it really works for me. hope this will help you guys.
if the issue is because of Addthis, try following
noted that the inside ATResources.bundle you have a folder named ATResources.
ATResources contains exactly the copy items (ADDTHIS.db,en.lproj,images) which is present in ATResources.bundle. so we can simply delete the ATResources folder from ATResources.bundle.
for deleting,, select the files from ATResources.bundle and right click , show in finder -> and remove ATResources folder.
the major issue is because subdirectory in your bundle that has the same name as its parent directory.
:)
I had same problem in my project (in xcode 4.3.2) and as per all answers I checked for any .png file starting with ._* and also checked folder and its subfolder are different name.
Also checked code signing identity as per requirement, but did not succeed to solve this problem.
After whole days effort finally I got reason for "Packaging operation failed" error in my project.
In my case, I have classed About_us.h and About_us.m and by mistake I import header file like #import "About Us.h" (white space in middle). So when I loaded app on Device it will successfully loaded but when I try to create ipa using archive its give me error and return me Estimated App Store Size just 143 kb.
Finally while I change header like #import "About_Us.h" and try to make ipa I got real size in proper MB.
Hope this will help someone.
I experienced this issue on Xcode 5.0.2 (5A3005) with 2 completely separate folders that happened to be named the same thing.
Most other cases in this thread focus on the parent/sibling relationship, but I think it's any two folders with the same name will cause this failure.
I had same problem as you do, and radven response inspired me:
did you see that ATResources directory contains nothing more than just copy of its parent?
ADDTHIS.db
en.lproj/*
images/*
ATResources/ADDTHIS.db
ATResources/en.lproj/*
ATResources/images/*
As a quick-and-dirty fix I removed the redundant subdirectory. Application builds and seems to work fine, and Xcode is able to sign.
Let me know if I missed any consequence of this fix?
Gee, I spent like an hour on this problem.
I just removed AddThis from my project. Do it and it would work.
restarting xcode made the buttons work for me. they were greyed out before, in case anyone here is having the same problem
Techi50 alluded to this but to be clear - under Xcode 4.3.5 there is a serious bug where code signing will fail if you have subdirectories with the same name as the parent directory. In the Sencha Touch 2 SDK tree, for example, there is
/sdk/src/device/device
argh... hours of trying to code sign with no luck... rename to:
/sdk/src/device/device_epic_fail
(since I don't need those libraries anyway)
and I can code sign.
And one big bug hunt is over. Apple... fix please...
Updating the AddThis SDK from 0.1.7 to 0.1.9 fixed this problem for me (using XCode 4.3.1).
I've determined another cause of this error, which occurred for me in Xcode 4.6.2 (4H1003). I had a subproject building an executable. This executable is a helper tool which is copied into my app's bundle when it builds.
The app has a min deployment target of OS X 10.7 and builds for 64-bit Intel as a result.
The helper tool, however, was set to a deployment target of 10.6, and was building for 32-bit/64-bit Intel.
Changing the helper tool to also build for 10.7 and 64-bit Intel only fixed the error. I can reliably recreate the error by changing the helper tool back to 32-bit/64-bit Intel; this is not a 'erm, zap your PRAM' fix.
As #radven and #tomek-cejner mentioned sometimes some extra directories could cause problems. Maybe if named improperly? for me the offenders were different.
Gruntfile.js, karma-e2e.conf.js, karma.conf.js, and the entire node_modules directory.
see: How to build IPA for distribution with TestFlight with XCode 5?