Before uploading your Mac app to the App Store, it's pretty useful to run a couple of sanity checks on your installer pkg to make sure things are in order. The most common one is "/usr/libexec/productutil --package YourApp.pkg --check-signature", which will let you know if your app and installer have been signed correctly (hint: if you see a "false" anywhere in there, it isn't).
This is great for figuring out things early on before having to submit your app.
However if you've been submitting apps to the store since it opened, you'll have noticed that some things that used to get by are now being flagged and rejected right away. Things like having underscores in your CFBundleIdentifier, or maybe you have a file alias in a framework that points to nowhere in your bundle, or ppc code in an embedded framework. What exactly is causing these new issues to pop up when they were fine yesterday?
Before submitting your app, Application Loader will gather information about your app and then send that off to Apple. Some automated process will then quickly inspect it and decide wether or not to reject your app right away (or not). This is pretty handy (at least for Apple) since it can update its app requirements without having to push out new dev tools. However, sometimes the error messages you get back are a bit vague, or maybe don't have enough info for you to act on. For instance a couple of hours ago I got this auto-rejection:
"The application bundle may not contain tools or frameworks provided by Apple, or using bundle identifiers in the 'com.apple' namespace. (1091)"
Fair enough. But exactly which bundle are you referring to? A quick peek inside VoodooPad reveals that it has 33 different bundles (various frameworks, spotlight, automator actions, web export plugins, etc.). The error message wasn't nice enough to point out to me which bundle it was referring to, so I guess I'll just hunt it down myself.
Then I got curious and wondered what exactly App Loader was sending to Apple before uploading your app. A bit more snooping around revealed that it calls productutil with some extra arguments which I didn't know about (the man page for productutil is no help, and says "It is not meant to be invoked directly". Bah!). Here is the command (at least in VoodooPad's case) App Loader using to generated the info sent to Apple:
/usr/libexec/productutil --skip-attr-checks --package VoodooPad.pkg --expand /tmp/wherever --extract-metadata --check-signature
In VoodooPad's case, productutil produced a big plist (2k+ lines) which contained a ton of information about my app such as architectures, bundles and their Info.plists, and much more. It also helped me figure out which bundle had the com.apple prefix in its bundle id (it was a helper app within a framework (which was inside the main app)).
So the next time you get a vague error message back from Application Loader, it might be helpful to check the report generated by productutil before swearing in the general direction of Cupertino, CA.