While working on a recent iOS App (an app called APEX – for medical research, if you’re interested), I ran across an infuriating problem – we could submit our app to the App Store and the application bundle even verified correctly before submission. However, shortly after the app was uploaded, we received an email stating ‘Invalid Binary – Invalid Signature’. This article collects together the things we tried to fix the problem, including the solution that eventually fixed the problem, to hopefully help you save a few hours of hair pulling if you’ve run into the same issue.
“The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate.”
It appears that this stage of Apple’s check of your uploaded binary actually catches a whole bunch of errors, some of which fall outside of those which Apple suggest you try to fix in the email you receive. It’s likely all of these errors do actually relate to the provided error – something went wrong with the code sign issue and the bundle isn’t signed properly, but it seems there are a lot of things that can cause that.
Here are the things – I hope one of these helps you!
1. Ensure files are on an OSX Journaled Partition: Our project and source files were in a FAT32 TrueCrypt container. All of our previous testing and compiling (even TestFlight builds) were done from this partition. However, this was ultimately what caused us our problems – after moving the files directly onto my developer machine’s drive, our binary finally successfully went through the upload procedure and went to ‘Waiting for Review’.
2. Check and Double Check your Signing Settings: You really do need to ensure that your project is being signed with the correct provisioning profile / certificate. This must be your company’s app-store distribution certificate instead of your development certificate. If you have tried this a few times already, it’s worth clearing out the provisioning profiles from your ~/Library/MobileDevice/Provisioning Profile/, clearing up your provisioning profiles using the online portal and then downloading them again using Xcode. You might also want to delete any unused certificates in Keychain too, just to make sure. If you do this, make sure you restart Xcode after you delete the provisioning profile. You’ll also want to make sure you to a ‘Build -> Clean’ before doing ‘Build -> Archive’ for your app, just in case. You should also make sure that you have set your provisioning profile on the TARGET you are building and not just at the PROJECT level as TARGET settings override project settings.
3. iOS Device Deployment Target: Make sure you have the deployment target set to ‘iOS Device’ and NOT an iOS Simulator. Do this at the top left of the Xcode UI. If you have set this to iOS Device, you should also ensure that you do not have a real iOS device plugged in. Unplug all iOS devices from USB just to be sure.
4. Check your Info.plist: Some users have reported that empty entries or duplicate entries in Info.plist, especially with regards to Icon file paths, can also lead to this error. Perhaps something tidies up the plist file at some point and it messes up the bundle signature.
5. Entitlements.plist: I’ve not used the new Xcode entitlements editor built-in with Xcode, but if you have enabled iCloud for your app, or some of the other ‘extra features’ that you activate through the developer portal for your app, then there are reports that having invalid details in your Entitlements settings can also cause this error to appear. If you have iCloud enabled, perhaps try to disable it for a single upload to see if that fixes it.
6. Project Folder Symlinks: I’ve not run into this scenario myself, but I expect that there is the possibility that having symlinked files or folders in your Xcode project could be a possible candidate for this error appearing (much in the same way that a FAT32 filesystem caused our errors). If you are doing this, it might be worth just copying the files into your project folder to see if this resolves it.