August 11, 2009 – T-machine.org

I’ll be writing this up in more detail soon, but here’s a bad error message from Apple’s App Store process (summer 2009) that I found zero hits for on a google search, so I thought I’d quickly throw up this page now that I’ve found out what the cause is. Hopefully it will help anyone else who hits the same problem.

If you’re using the new Apple Uploader to send your binary to the App Store (don’t! I’ve discovered it has at least one critical bug where it claims to upload the binary but it actually hasn’t!), you might hit this error before the upload starts:

“Application failed codesign verification. Please see the console log for additional details”

Assuming you know enough about OS X to know how/where to view the Console, at the end of the log you may see something like this pair of entries:

ApplicationLoader[18609] *** Codesign error (please ignore invalid option comments): got requirements(0x805a00, 525)
Executable=/var/folders/0o/0oFmipSKGvqwVZcVZJPOgU+++TI/-Tmp-/starcatcher.app.zip/starcatcher.app/Star Catcher
Identifier=no
Format=bundle with Mach-O thin (armv6)
CodeDirectory v=20001 size=1587 flags=0x0(none) hashes=72+5 location=embedded
Signature size=4274
Authority=iPhone Distribution: Adam Martin
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=10 Aug 2009 16:55:51
Info.plist entries=18
Sealed Resources rules=3 files=24
Internal requirements count=0 size=12

Executable=/var/folders/0o/0oFmipSKGvqwVZcVZJPOgU+++TI/-Tmp-/starcatcher.app.zip/starcatcher.app/Star Catcher
got entitlements(0x805e00, 299)
codesign_wrapper-0.7.3: using Apple CA for profile evaluation
AssertMacros: binary, file: /data/conrad/security/codesign_wrapper/codesign.c, line: 205
AssertMacros: code_signatures, file: /data/conrad/security/codesign_wrapper/codesign_wrapper.c, line: 903

ApplicationLoader[18609] *** Error: /Users/adam/Desktop/starcatcher.app.zip: validation failures: (
“Application failed codesign verification. Please see the console log for additional details”
)

What’s the error message?

Ah, well, despite the second entry claiming that the console log will have an error … the error itself is missing (like so much of Apple’s documentation ;)). With a bit of imagination and “creative interpretation”, I spotted that:

Line 1:

ApplicationLoader[18609] *** Codesign error (please ignore invalid option comments): got requirements(0x805a00, 525)

Line 16:

got entitlements(0x805e00, 299)

and inferred that there was a problem with a checksum, whereby it was expecting something that looked like X, but found something that looked like Y.

(NB: Apple’s appallingly bad lack-of-error-message may mean something completely different, but this guess lead to me trying something that ended up fixing the problem)

Looking carefully at my App, looking for signed things not being what were expected, I realised that my app was importing a static library that had been signed by someone else (partly because the new version of Xcode defaults to signing everything, all the time – which it should do, but I hadn’t got used to that new “feature” yet). With bad code-signing implementations, that can often be a problem (although I naively expected Apple to have a sensible implementation of code-signing, and it had never occurred to me this would be a problem with Xcode. Oops).

Speaking to the person who built that library, I found that the build config they’d used had been set to sign using a Developer provisioning profile. I re-built it using my Distribution provisioning profile, re-added the static lib binary it to my project, re-built my app … and the App Store upload finally succeeded.

Anyway … followup post coming soon on how to make static libraries work on iPhone with iPhone OS 3.0 / Xcode 3.1.3 and above (hint: Apple broke some of the things that used to work, and so sometimes you have to do it differently since OS 3.0 came along)

I saw an article recently that described this attitude nicely: certain weak marketing executives believe that the purpose of a “conversation” is for them to have more ways of telling the customer what to do; they are seemingly incapable of understanding the idea that a “conversation” involves listening to the other person.

To them, email is a “one-way broadcast medium for us to tell the customer what to buy”, rather than “a two-way communication medium that allows us to listen and respond to our customers”.

Today, I received a great example. Here’s an email I received one month ago, from Apple:

“Thank you for renewing your iPhone Developer Program membership. New Expiration Date: 10 Aug 2010”

And here’s the email I received today, from Apple:

“your iPhone Developer Program has expired” (sent from address: “noreply-iphonedev@apple.com” )

A triple-whammy on appalling customer support there:

Erroneously (I hope) claiming that they are NOT providing a service they have committed to providing
Taking money from a bank account in return for a service that they then don’t provide (that bit’s illegal)
…and:
Sending all correspondence from an email address that they mark “noreply”; i.e. “if we (Apple) screwed up, we don’t want to hear from you. We don’t want to fix it. Go away”

I especially like the way they put this all together, so you get the implication that:

Apple would prefer me to sue them (Apple), or file a claim against them for fraud, than to let me send them a simple email and spare them the fallout of their stupid mistake.

Using a two-way media to deliberately ignore your customers? That’s Web 0.1.