Ошибка двоичного файла app store connect

I’m trying to upload an application to the iPhone App Store, but I get this error message from iTunes Connect:

The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate.

Note: The details of original question have been removed, as this page has turned into a repository for all information about possible causes of that particular error message.

For general information on submitting iPhone applications to the App Store, see Steps to upload an iPhone application to the AppStore.

It’s been my experience that Xcode occasionally gets confused about which signing certificate to use. I got into the habit of quitting and restarting Xcode after any change to the code signing settings (and doing a clean build) to work around this problem.

answered Sep 30, 2008 at 22:20

I just wanted to mention that I too had the problem with zip from the command
line as well. The problem lies in the way it handles symlinks by default. Using:

zip -y -r myapp.zip myapp.app

Solved that problem.

I had the same issue and solved it this way:

The property certificates were installed on my development machine and mobileprovision.embedded was included in the distribution archive. After an hour or so of Googling and digging I found the source the error. Inside Xcode I had copied the Release configuration and created a new Distribution configuration and then changed the signing identity to my distribution certificate. However, even though it was updated in the GUI the project file was not updated correctly.

If you come across the same error, look in your [ProjectName].xcodeproj directory for the project.pbxproj file and open it in your favorite editor. Look for the Distribution section. My broken one looked like this:

C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Developer: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Developer: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
};
name = Distribution;
};

You can see the signing identity and provisioning profile are incorrect in the second section. Edit it to match the first section, rebuild, and you should be good to go. The final one looked like this:

C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Distribution: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “F00D3778-32B2-4550-9FCE-1A4090344400″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
};
name = Distribution;
};

guids changed to protect the innocent

Same problem, different solution.

In my case, I was compressing the file using zip -r myapp.zip myapp.app
Turns out, the zip command screwed the bundle. Compressing it from the finder made it work.

I had the same issue and after trying several things — I removed the .plist entitlements from the Code Signing Entitlements (just left it blank) and it built fine and uploaded FINALLY.

Good luck all

Another data point: for a while, my app went through. Now I’ve added support for in-app purchases, and suddenly it fails with an «Invalid binary/invalid signature» problem. Upon careful looking, I found out that the value of application-identifier in the entitlements plist file was off.

This, most likely, had to do with the fact that I’ve replaced the provisioning profile from a wildcarded one to a app-specific one (required for in-app purchases). The wrong app ID qualified under the old profile. It did not match the app ID in the info.plist, but apparently iTunes forgave that.

So, to recap:

info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.*

is OK, while

info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.foo

causes «Invalid binary».

I had the same problem aswell, when building I noticed the provisioning wasn’t added in the build.

The fix for me was to set the build to the iphone device as where I normally use the simulator, but then it won’t include the provisioning profile…

This might be a noob mistake. Normally you can’t build to device, but when you do it for distribution you can.

Well, after repeating the steps several times, I was finally successful in uploading my app.

I don’t know exactly what fixed it, but prior to the successful attempt, I closed Xcode and Firefox and restarted them. I guess one of those apps had some bad juju.

Here’s an issue I ran into: I added the binary to Subversion before uploading. Comparessing/zipping the binary then included the hidden .svn directories, which messed up the code signing.

I tried various things after reading various posts including those above. What finally worked for me was starting completely over! I deleted every certificate and provisioning profile associated with my app.

I recreated a new development certificate and a new distribution certificate. I downloaded the intermediate certificate again. Then I recreated both the development profile and the distribution profile.

After installing the three certificates (I noticed the distribution had both private and public keys this time) and the two provisioning profiles (my distribution profile didn’t get flagged as not having a valid certificate!), everything worked.

Once I made the decision to revoke everything and just start over, it only took about 5 minutes to create the new stuff and re-install.

I had a similar issue but in Monotouch. I found that my Release profile was set to use developer certs. It should look like this:
enter image description here

It seems this issue has many causes. Here’s the solution to mine:

This applies to anyone who belongs to multiple development teams (e.g. your own apps, and your companies).

If you building the build with one set of credentials and re-signing it with a different one (e.g. for adhoc/appstore distribution), you must ensure that the build was originally built & signed with credentials belonging to the same iOS development team that the distribution credentials you are re-signing with belong to.

So don’t build with «Indy Dev Inc» credentials then try to deploy with «Company Inc» credentials. Make sure you setup both «Company Inc» dev, and distribution credentials, and use them.

I posted more info about this on my blog: http://omegadelta.net/2011/06/09/fiendish-ios-code-signing-invalid-binary-issue/

I had the same problem. I was ready to throw in the towel on this problem but I figured it out when I went to check in my code using Murky. I always skim the diffs on the files that changed before I check in. When doing so this time I noticed that the project.pbxproj file had changed….and in the Distribution section the entry for “PROVISIONING_PROFILE[sdk=iphoneos*]” was blank.

Quiting and restarting Xcode didn’t work for me. Instead, I went into both my project and target settings and changed the code signing to directly select my Distribution profile rather than relying on the auto-select feature. Doing this caused the project.pbxproj file to populate with the correct values even though the auto-select feature supposedly selected the exact same profile that I selected manually.

I need a beer…

After trying all of the other fixes listed here we logged a TSI with Apple. Having followed all the steps in Technical Note TN2250 our problem was caused because a sealed resource was missing or invalid. In our case it was ._.DS_Store.

The «..» is called an Apple Double file, and is the result of copying the Xcode Project folder, *unzipped*, onto and back from a file system that doesn’t properly support HFS+’s ‘resource forks’ (used for code signatures). These extra «..» files result and cause code signing verification failure.

To clean the problematic Apple Double files from your Xcode project folder, run the dot_clean command on your Xcode project’s folder, do a clean build, and then rearchive and reattempt your submission.

dot_clean /the/path/to/xcode/project

Note: You can just drag the project folder into the terminal to automatically populate the path

There is no message when you run the command but the project build might show a warning about the file when you next build. You can ignore this, the app will validate and submit successfully.

Resolved this by cleaning up the myProject.xcodeproj file (right click, open package), the package contained files from co-developer, after deleting these the problem was solved

For what it is worth, I want to add what it was that fixed this issue for me. I had a ? (question-mark) in my app title that was causing the error.

I received an invalid binary, if the app does not use remote push notification, but I left the code for registering push and the callback delegates for registering/receiving remote notification uncommented, even if the code does not get used.

This is recent. My last submission last week was fine. This week, it returns invalid binary. Luckily, there is an email that explains the error.

I was having a similar problem, but I don’t use entitlements.plist. However, after a dozen failed uploads, I checked my info.plist and discovered something. My CFBundleIconFiles array had an empty entry. I removed that and re-submitted, and it was finally accepted!

Seriously, how hard would it be for Apple to expose those kind of validation errors?

Edit: It’s not immediately apparant where the CFBundleIconFiles are because they use a different name. In the project info view, Ctl click and select «Show Raw Keys/Values» and then you will see the references to CFBundleWhatever. In this editor’s case, he was trying to use a non-existent icon=72-@2x.png file.

I tried all other proposed solutions, but nothing helped.

I ended up creating a new Xcode project and copy all my code and resources into it. That did the trick, and my app got placed into the review queue.

I can also recommend Apples technical notes on code signing for debugging/verification.

My two cents:

Download the latest version of the Application Loader. I’ve just updated and now get a different error message.

I just went through this hassle (again) but this time I found that my distribution profile had a status of «Invalid». If you think everything else is right, double-check the status in the portal and renew/re-download anything that isn’t in the Active state.

I received an Invalid Binary after an app upload, with no e-mail followup as to why it failed. I tried doing a couple things at once, and I’m not sure which of the following actually fixed it:

Restarted Macbook Pro
Moved the source code for my project from an NTFS drive to an HFS+ drive and recompiled.

I had a problem with this and the 4.3 GM SDK. One of our apps would not make it past upload received. It turned out to be a provisioning profile issue. I regenerated the app store profile and it worked fine.

My solution involved creating a new App ID. I’m not sure exactly why that fixed it, but I suspect it may have been mismatched Bundle Identifiers — creating the new App ID forced me to make sure my app and iTunes were expecting the same thing.

Another solution:

For me simply setting the ‘Release’ certificates under ‘code signing’ fixed it. They were initially set to ‘Don’t code sign’.

For me the problem was solved by resaving a PNG image with the non-interlaced option. In previous versions interlaced png were allowed, but know this images can cause the invalid binary.

My apple message:
Corrupt Icon File — The icon file iconGQ@2x.png appears to be corrupt. Your icon must not be an interlaced PNG file.

You can see if the PNG is interlaced using the command «file» in the terminal:
Eva-Madrazos-MacBook-Pro-2:GQ 7 integracion ads Eva$ file *.png
Default.png: PNG image data, 320 x 480, 8-bit/color RGB, non-interlaced

Good luck,
Eva

I want to point out the possibility to email Apple and ask them to check their logs. I did just that, after having tried loads of things first. It was necessary to remind them after almost four weeks, but finally they replied and pointed to the exact spot of the issue.

The problem in my case was that I had previously tried other app icons, and a reference to the old image still remained in ‘CFBundleIcons’. I used the drag and drop functionality to set the icon, but I didn’t notice that the old content wasn’t completely cleared before the new reference was added.

To see the faulty reference it was necessary to expand the arrows to view each and every sub element in the plist file. One tips is to right-click in the file and select the option for viewing the raw content. In that way you will not need to expand anything.

uuid is not allowed.
I fixed it by remove all [[UIDevice currentDevice] uniqueIdentifier];

Источник