Thought I’d post about this little developer experience because it was incredibly frustrating and not at all obvious. Maybe this will save someone else the headache that I’ve been through.
Background: When preparing an application for release on the Mac App Store, you code sign your application, then bundle it into an installer pkg which is also code signed (using either Xcode organizer or the productbuild command line tool). When the application is installed, it gets extracted from that .pkg file, the user runs it, and it checks for a Mac App Store receipt. If there’s no receipt, OS X checks to make sure that the application is signed correctly, then contacts the Mac App Store to get your receipt.
Problem: This would all work for me as advertised except that when the receipt check failed, OS X would complain that my application wasn’t code signed, and therefore wouldn’t contact the App Store to get the receipt. From a user’s perspective, the app would just fail to launch.
I’d followed all the instructions. I double- and triple-checked to make sure the application was signed before I built the .pkg file. I tried building the .pkg using both the Xcode organizer and productbuild – they both worked with no problems or error messages. Yet when the application came out of the .pkg file on the other end, it was always unsigned! I deleted all of my certificates, regenerated them, and redownloaded them from Apple’s developer site (several times). I checked every step along the way in my build process – they were all working. It was incredibly frustrating because the signed app went into the ‘black box’ of the .pkg file just fine, but came out on the other end without its code signature.
Solution: After tearing my hear out for a while, googling for answers, and checking the developer forums, I finally tracked down the solution. I had a single image file in my application’s resources that had its permissions set to 640 instead of 644, meaning that it was not readable by everyone. That threw the entire game off – apparently when the installer unpacked the .pkg file, it ran into this problem file and either stopped short of installing the code signature, or invalidated the signature. Either way, the application it installed was useless. Simply changing the permissions on that one tiff file fixed the problem I’d been fighting with for days.
Soooo…. If your app builds and runs fine UNTIL you package it, and then comes out unsigned on the other end, check the permissions on the resources in your application. And Apple, please emit some kind of warning when hapless developers feed productbuild a file with the wrong permissions that’s gonna screw up the whole process.
Tip: There’s a really cool developer utility called Cong, written by Stephane Sudre. It checks your application for all kinds of minor errors, from localization goofs in .strings files to incorrect Info.plist entries to missing files in your package. I’ve contacted Stephane and checking file permissions is now on his To-Do list for Cong. If you’re a developer, get a copy of Cong – a simple drag-and-drop could save you a lot of time and trouble!
Hi! Am I hoping for too much if hoping for Default Folder X to be on the App Store in the near future?
I’m afraid you’re not going to see Default Folder X in the Mac App Store. It doesn’t meet the App Store guidelines (because it installs a scripting addition) and therefore can’t get approval. For Lion, it’s also going to need your administrator password, which is another App Store no-no, and is why App Tamer can’t be put in the App Store either.
If Apple changes their requirements, this could change, of course. But for the present, Default Folder X and App Tamer will only be sold through our web site and resellers.