Release Notes

Cornerstone’s release to the Mac App Store yesterday marked the end of a 6-month process.

We made a couple of mistakes along the way, so we thought that we’d document some of them in the hope that it might be useful to others intending to submit their apps to the Mac App Store.

The Sitdown

Apple approached us back at the beginning of November to discuss getting Cornerstone into the Mac App Store at launch. They even took the time to meet us in Zurich to help us get started and to answer any technical questions.

We immediately set about registering with the Mac Developer Program and modifying the app to meet Apple’s requirements.

The fruit of these labors has been visible for some time and some users probably noticed that the software update-related preferences were moved to their own preference pane in 2.0.3.

This was in preparation for our first submission to the Mac App Store back in mid-November.

A Little Less Sparkle

Unfortunately Cornerstone was rejected at the beginning of January. Apple’s review guidelines state that an app may not use any installation technology other than the Mac App Store and Cornerstone inadvertently violated that rule.

Cornerstone has historically used Sparkle to check for updates and although we completely removed the Sparkle framework along with all related UI, the app’s .plist file contained a vestigial configuration entry for Cornerstone’s appcast feed.

Lesson learned:

Make absolutely sure that all traces of Sparkle or alternative installation or updating technologies are removed before submitting an app for review.

Obvious in hindsight, but nonetheless easily overlooked.

Info.plist Permissions

Our solution for the Sparkle .plist entries involved using the defaults command-line tool to remove the SUFeedURL entry during the Cornerstone build.

An unfortunate side effect of using the defaults tool is that the Info.plist file is converted from XML to binary format in the process. Luckily we spotted this during testing and implemented a fix: the modified Info.plist file is now converted back to XML using the plutil -convert xml1 command.

What we didn’t expect is that the plutil tool changes the permissions of the output file to be:

-rw-------

Erm, oops! With an Info.plist file like that Cornerstone can only be launched by the person that installed the app. This isn’t a problem for most users but it is for apps installed from the Mac App Store.

Thankfully, Apple’s review procedure caught this issue and Cornerstone was rejected a second time.

Lesson learned:

Test app installation with the installer tool provided by Apple. Be sure to run the tool as an admin user other than yourself.

We should have been doing this but hadn’t done our homework: Apple’s Submitting to the Mac App Store documentation clearly mandates that developers perform this test in advance of submission.

Window Resizing

We were rejected a third time in March. The reason? Resizing the main application window to a very small size resulted in unrecoverable layout issues.

We promptly fixed this in 2.2 by defining a minimum size for the main window. We also improved the collapsing behavior of the inspector to better deal with small window sizes.

Lesson learned:

Test the behavior of your app’s UI when the window is resized to it’s minimum size. If you haven’t defined a minimum size for your app’s window then you should probably consider doing so.

Some might claim that Apple is being overly pedantic, but we disagree. An app’s UI should be predictable at all sizes and fixing this improved the quality of Cornerstone.

In Summary

It’s been a long and winding road. And we’ve only described a couple of the roadblocks we encountered along the way.

There were many other things that we had to do to get Cornerstone into the Mac App Store:

• Create a build without PPC code
• Remove the licensing and Sparkle UIs
• Remove their accompanying frameworks
• Add Mac App Store receipt verification and authentication
• Adapt the app’s configuration to meet Mac App Store requirements

The list goes on and on.

But it was worth it. We strive to make excellent Mac software and part of the challenge is providing a user experience consistent with Mac conventions and idioms.

Before January 6th 2011 that meant shipping your app as a .zip file or disk image. Now it means being on the Mac App Store.

Thanks

Finally, we’d like to take this opportunity to thank the guys at Apple that supported us on numerous occasions over the last six months.

We won’t mention any names, but if you’re reading this: Thanks. Your help was very greatly appreciated!