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.
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 :-D
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".
See this link for the solution:
http://greghaygood.com/2010/09/04/invalid-binary-message-from-itunesconnect
The short answer is that "Eventually I double-checked my info.plist and discovered something. I added CFBundleIconFiles per the new guidelines, but there was an empty entry in the array list. I removed that and re-submitted, and it was finally accepted!"
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:
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 me the solution was creating a distributing certification at:
Apple Developer Provisioning Portal.
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];
Related
I am working on an email client based on ReMail. Basically, I reused the ReMail project so that the MailCore etc dependencies would be all set up out of the box so I could build a new app on top of them. I'm trying to give the app to some beta testers via ad hoc, but when I try to create an IPA, I receive this error:
xxxx does not contain a single–bundle application or contains multiple products. Please select another archive, or adjust your scheme to create a single–bundle application.
I have set Skip Install to YES for all dependencies, and moved all files under Copy Header to the "project" section, but I am still unable to build a single APP file.
I don't know if this is significant, but when I open up the xcarchive file, within the products directory, I find a the APP file under Applications, and then a file structure mirroring the absolute path to the header files for MailCore.
Any ideas as to what might be going on? I'm very near the tearing-out-chunks-of-hair-in-frustration stage, and I don't think the unnaturally bald crazy person look would suit me.
Thanks!
Try removing the “Copy Headers” phase entirely. It's only supposed to be used for frameworks, not static libraries. The Xcode static library template that includes a “Copy Headers” phase is wrong.
Check out the “Working with Schemes and Projects in Xcode” video from WWDC 2012, starting at 45m10s.
Our applications set the "do not back-up" flag as per Apple's requirements. Or at least we thought so. A recent submission has been rejected because the reviewer found a file without the flag set. We tested, re-tested and tested again and see that all of our files are created with the "do not back-up" flag. Hmmm!
This is not our first application using the same code base. We've had many others pass through with no issues even some quite recently.
So could it be a sequencing problem? We are copying a database file out of the download bundle that is used as the application's starting content; this content is then updated as the user gets more data. The initial database file can be large - as big as 2MB - depending on the application. We open a new file in the Documents folder, copy the database contents to the new file, close it, and then set the "do not back-up" flag.
Instead should we create an empty file and then immediately set the "do not back-up" flag, prior to opening it to overwrite the empty file with the database contents from the bundle?
I've asked the Apple reviewers this question but have not received an answer yet. I could simply try the different sequence and see what happens in the re-review, but I'd prefer to know what I should be doing and do it, rather than guess what the problem is and shoot in the dark.
So does anyone know of a sure-fire "Apple approved" way to copy out a (database) file from the bundle into the Documents directory and set the "do not back-up" flag? Can anyone shed light on any similar rejections and what they did to please the reviewers?
Having earned the Tumbleweed badge (= its a boring question) here is some information to answer it....
The way to set the "do not back-up" flag has changed between 5.0.1 and 5.1. The release notes for iOS 5.1 SDK has the following entry under "Backup"
iOS 5.1 introduces a new API to mark files or directories that should not be backed up. For NSURL objects, add the NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from being backed up. For CFURLRef objects, use the corresponding kCFURLIsExcludedFromBackupKey attribute.
Apps running on iOS 5.1 and later must use the newer attributes and not add the com.apple.MobileBackup extended attribute directly, as previously documented. The com.apple.MobileBackup extended attribute is deprecated and support for it may be removed in a future release.
Note that iCloud was introduced in iOS 5.01, and this change was introduced in 5.1, which means that the app must adapt to the iOS specific version running on the device. One of our developers found the following Gist for code that handles pre- and post- iOS 5.1 devices.
Any Xcode project I create from scratch always contain either a sym link to the com.apple.AddressBook.plist file or to com.apple.PeoplePicker.plist in the folder:
Application Support/iPhone
Simulator/(SDK
Version)/Applications/(GUID)/Library/Preferences
Anyone know why this is and how do I go about the app never creating this?
It seems to get created after I run the app in the simulator and always comes back no matter what I do.
What purpose does this link serve?
The point of the symlink to com.apple.PeoplePicker.plist is to provide default sorting behavior for the PeoplePicker; when picking recipients for email message.
Reference: http://developer.apple.com/library/ios/#documentation/ContactData/Conceptual/AddressBookProgrammingGuideforiPhone/Chapters/QuickStart.html
Can’t install application
The application at /Users/myname/Documents/SDK/iPhoneApplications/x/build/Debug-iphoneos/x.app does not specify a CFBundleExecutable
I don't know what this means or how to fix it. Can anyone help?
It only occurs when trying to build to a device - it is an iPhone 3G running 4.1 and I am using the latest SDK which allows me to build on iOS 4.1
I also faced the same problem and the solution that worked in my case was to add CFBundleExecutable in info.plist.
Here are the steps to do it
Click on the + icon in your info.plist and add CFBundleExecutable as String type.
2.then in its value just add
$(EXECUTABLE_NAME)
and then rebuild your app.
This worked for me and hope it works for you as well. All the best.
This value is specified in your Info.plist file. I would check your target for the debug configuration and make sure you have the correct plist file specified.
Double-click on your target and search for the Packaging section or for Info.plist.
If the plist is correct, check the content of your Info.plist to make sure you have either a value for either key CFBundleExecutable or key Executable file (they are the same value, but can be displayed with raw or friendly labels).
I faced this issue yesterday and I spent more than 6 hours to find the solution, just follow the instruction below.
1- Go to your "TARGETS".
2- Then go to "Build Settings".
3- After that go to "Basic" then "Combined".
4- Then under the Packaging, you will find the "Info.plist File", check here if your file correct or not, if it's not equal to "Your project Name/Info.plist" you must change it to "Your Project Name/Info.plist".
in my case, i have changed "Mach-O Type" to "Static Library", this may lead to the same question. just change it to Executable , worked for me
After you setup CFBundleExecutable to $(EXECUTABLE_NAME), you have to set EXECUTABLE_NAME's value in xcode. Select your target in TARGETS then go in the Build Settings tab and then search for Product Name.
Check that all your schemes product names are specified corretly to avoid any error (shouldn't contain any of the followin caracter \ [ ] { } ( ) + *).
The headers for libbz2.dylib on the iPhone are missing, or contained in a less than obvious location. I've looked for bzlib.h, bz2lib.h, bz2.h, etc., grepped for patterns, and found nothing - are they included with the SDK, or do I need to just pull the header from the main libbz2 distro and use that instead?
Since the library is clearly available on the device, the header really should be in the SDK, but it appears that it isn't. I'd use the one that's packaged for the Simulator, since this is most likely to be the same as the one on the device:
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.2.1.sdk/usr/include/bzlib.h
Then open a Radar case to ask that the distribution be fixed.
From the site below get the bzlib-0.5.0.0.tar.gz file and copy the files (.h and .c) inside the cbits directory to your Xcode project.
http://hackage.haskell.org/package/bzlib
So far it seems to work, I've managed to read the contents of a .bz2 file with the functions BZ2_bzReadOpen and then BZ2_bzRead.