Your iPhone application is finished. The testers are happy. The graphics designers are sure that everything is pixel perfect. Your microsite is done. Your marketing material is ready. Your metadata is in order. All you need to do is to submit your application to the App Store and start raking in the dough.

Your heart sinks, though, because when you submit your application you receive a terrible error message - "failed codesign verification". That's all. No further details. No explanation as to what went wrong. Has all of your stress come to naught?

Well fear not. Many have trodden this path before you and chances are you'll be able to fix it. When I ran into this trying to submit our Very First Product I spent several hours trying to figure out what was preventing Apple from accepting our application.

1) Have you signed your application correctly?

It sounds obvious, but you need to check and double check that you have the correct signature being applied to your application. There is adequate documentation on the developer program portal describing what you need to do there. Review this and make sure you have it right.

Many criticisms have been levelled at Apple concerning the hoops you need to jump through to have an application signed. Airsource has experience dealing with most of the common mobile development platforms and although there are elements that are a bit more involved on the iPhone it is not unusual.

2) How is your .app folder compressed?

This is what nailed us. Airsource have a fairly strict policy of only shipping products that come out of our automated build process. This ensures that we can repeat builds and that there is a minimal amount of new effort required when we ship second or third products for a platform. Our customers like it because we can be responsive to requests for changes and we don't regress on our packaging.

We've got a lot of experience now doing this for S60, BREW and BlackBerry but setting things up for iPhone builds required some additional scripting. The last stage of the build packages up all of our submission artifacts (screenshots, App Store icon and the binary) into a single archive which we can then use to drive the submission process.

In order to submit your binary to iTunes Connect, you need to compress it. Our automated build process did this:

zip -r OurApp.zip . -x *.svn*

And when this package was submitted to Apple, it was refused with the "failed codesign verification" error.

Much experimentation revealed that the Mac OS X "Compress" Finder command produced an acceptable result, whereas the above command did not. Why?

It turns out that in the app directory there is a softlink:

lrwxr-xr-x   1 Nick Clarey  staff      28 15 Jan 17:46 CodeResources -> _CodeSignature/CodeResources

and that the way this is archived is important. Softlinks appear to need to be compressed as softlinks, not as copies of the files that they point to. Changing our compression command as follows:

zip -y -r OurApp.zip . -x *.svn*

Produced a result that Apple was happy to accept. It turns out that how you treat softlinks is pretty important.

3) Make sure your version number is in an acceptable format

Received a note from Apple after what appeared to be a successful submission:

Thank you for your recent binary submission to the App Store. Unfortunately we discovered an issue with your binary that you will need to correct in order for your application to proceed to the review stage. The specific issue is outlined below:

Invalid or Non-Increasing CFBundleShortVersionString - The value specified in the bundle's Info.plist file for the key CFBundleShortVersionString must be a string consisting of at most three dot-separated components, where each component is composed only of the digits 0 through 9. For example, any of the following are syntactically valid values for CFBundleShortVersionString: "1.0", "4.2.1", "3.46", "1.112.0"; whereas the following are all syntactically invalid: "1.4.0.0.0.0.5", "GX5", "3.4.2b6", "2.6GM", "1.0 (Gold)", "-3.6". Additionally, each updated version of the same application must have a CFBundleShortVersionString that increases relative to that of the previous version that was actually made available for sale on the iTunes Store. For example, if a previously-available version had a CFBundleShortVersionString of "1.4", then any of the following would be acceptable as the next update: "1.4.1", "1.4.332", "1.5"; but all of the following (though syntactically valid) would be unacceptable: "1.4", "1.3", "1.3.9", "0.9". For more information about the CFBundleShortVersionString key and the Info.plist file, see Apple's Runtime Configuration Guidelines.

Sure enough, our automated builds were producing version numbers in the format major.minor (buildnum) which was not acceptable. Changing to major.minor.buildnum was all that was required to fix this.

Conclusion: be careful with your packaging.