Can't upload application binary to the App Store

Question

We've finally gotten to the point of submitting our first iPhone app to the app store (or trying to), but I can't seem to get iTunes Connect to accept the upload.

I've attempted through both the web site ("The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate.") and the Application Loader ("Info.plist does not contain a CFBundleResourceSpecification").

After lots of reading (including questions like these), re-reading, and googling, I can say that:

• I'm sure that the bundle identifier matches the AppID.
• There is an Icon.png, it's a 57x57 px PNG file, and that's the exact name in the Info.plist.
• I'm doing a device, not simulator, build.
• The signing process succeeds: the build results show this, and running codesign -vvvv MyApp.app indicates no problems.
• There are no strange characters in the path to the ZIP file.
• I've deleted the build folder and re-built the binary quite a few times.

Now, it is true that in the built app, the Info.plist does not contain a CFBundleResourceSpecification key, but it's not at all clear to me where that value should come from, or what else I need to add to make this work. (The only reference I can find using Apple's search is some code signing release notes... but, as I mentioned above, the code signing step is succeeding, as far as I can tell.)

Has anyone run across any explanations for this problem that I haven't mentioned already?

EDIT: Here's the (slightly redacted) output from the code signing step of the build, FWIW:

Answer 1

Are you sure you're building with a distribution, as opposed to development, certificate and mobileprovision?

Answer 2

I assume you're uploading a .zip file.

I just checked an app I uploaded, and CFBundleResourceSpecification is only in the signed versions (i.e. the device builds).

Answer 3

Are you doing any of your building/copying/zipping from the command line? If so, you have to be very careful about symbolic links. The .app comes with a subdirectory as a symbolic link to another, and if you copy it or zip it without the right flags, it'll hard-copy the contents, which messes with the codesigning.

This happened to me - and the worst part is, the ad-hoc builds work fine without the symbolic link, so you don't notice the problem until the app store build.

Answer 4

The problem seems to have been that I was using json-framework in my app, and including it as an additional SDK per the instructions in the wiki. My guess is that XCode got confused by the presence of >1 SDK, and thus couldn't find the default ResourceRules.plist like it's supposed to.

I found two solutions (well, workarounds, anyway):

1. Use the "Code Signing Resource Rules Path" build setting (which is blank by default) to specify the path to the file XCode should use: $(SDKROOT)/ResourceRules.plist. This works, and seems reasonably harmless, but is frustrating in the sense that XCode should be able to figure this out on its own. (I found this solution in a very old issue filed on json-framework.)
2. Don't use the SDK approach. Instead, just include the files directly into the project, and update the #import statements with local paths. This is the approach I ended up taking, since we made a general decision to fold all of the external dependencies into the project itself (so that other developers have less configuration to do on their machines to get up and running).

I'm not sure whether this is a bug in XCode, or something wrong with json-framework but I've filed an issue on the latter just in case.

UPDATE, 30 June 2010: the issue I filed has been closed, and Mr. Brautaset plans to remove support for the SDK option in the next release (2.3) of the project. Also, the code now lives on GitHub, though the Google Code pages still exist for now.

Answer 5

This message can happen for another reason (as I've just discovered this morning): if your project has multiple Info.plists in it, the Application Uploader may discover the "wrong" Info.plist and get confused.

This was happening to me because an automated part of the build was creating an Info.plist in a bundle brought into the project.

Hat tip to here for the solution: http://infinite-sushi.com/2010/08/the-case-of-the-missing-cfbundleresourcespecification/