This App Is Your AppFebruary 9th, 2011
One of the challenges existing Mac developers face with the Mac App Store (MAS) is whatever copy protection you have been using up until now has to be thrown out in favor of a protection scheme based on Apple’s App Store “receipts,” a tiny cryptographically signed file they place inside purchased applications that let your app confirm the authenticity of an application upon launching (and at any other time).
This leads to a conundrum if you continue to sell software directly, or offer preview beta releases for direct download. How can you offer access to these releases for customers who purchased through the MAS and thus do not have the “Registration Code” that direct-purchase customers receive? Apple provides no means of determining the identities of, or contact information for, authorized MAS customers. But even though I don’t know who these customers are, I want to treat them as first-class customers in every regard.
For me, I decided that the compromise is to provide, for those MAS customers who want it, full access to the direct-download versions of my software. Today, any customer who buys a MAS edition of my applications will find that, after running that edition at least once, they are automatically authorized to run direct-download versions of the app from that time forward.
A Recipe for Mass Authorization
How did I achieve this bit of wizardry? And more importantly, how can you, or other developers whose apps you love, achieve the same thing? There are three major code-level changes that I needed to make. I’ll discuss those changes, and some of the potentially non-obvious considerations to keep in mind while making them.
The MAS edition must stash its receipt somewhere obvious for the direct-download edition to find it. Because both editions of my app share a common Application Support folder, I chose to store them here. Inside the Application Support folder, I create a subfolder called “App Store Receipts” that contains the pertinent receipt files for this app.
Why a folder? Because a customer may sync or copy their App Support folder across various Macs, I chose to store each receipt keyed by the computer’s GUID, which is derived from its wired ethernet MAC address. Developers who have implemented app store authentication will be familiar with this value.
The direct-download version must, in the event it is not already authorized by a standard registration code, look for secondary validation in the form of a receipt in the aforementioned location. If it finds a receipt, the same type of validation is performed on the receipt as would be performed in the MAS edition.
You will want to apply some lenience when interpreting the validity of the receipt. For example, you probably want a receipt authorizing version “3.0” to also be considered valid for “3.0.1” or “3.0.1b1”. Similarly, if you use separate bundle IDs for your MAS and direct-download editions, you will want to consider the MAS bundle ID as valid for the direct-download version.
If you used a different bundle ID for your MAS and direct-download editions, then for the sake of the users sanity and yours, you probably want to implement some kind of transparent migration of preferences from one edition to the other. You don’t want customers to have to go in and reset all their preferences when they switch, and it can be annoying as a developer as well.
I had some preference migration code around from when I transitioned MarsEdit and Black Ink from their previous companies’ bundle IDs to mine. I reused that transition code, with a bit of careful but appropriate logic: if the other bundle ID was modified more recently than mine, then import it and replace my defaults. The same logic is applied in each edition so that whatever version you run, you’ll feel as though you’ve picked up all the latest preferences from the last time you used the app.
With these changes in place, I have the flexibility to offer direct-download versions of my software to any MAS customer who asks for it, or for customers who I request the assistance of in testing a pre-release bug fix. In most cases, I can just ask the customer to run the app. In the worst-case scenario, when a receipt has not yet been “stashed,” I have only to ask the customer to run the MAS edition once before trying the newer release.
Pitfalls and Downsides
This solution isn’t perfect. In particular, it brings MAS customers into the fold for direct-download software, but does nothing to soothe the existing and new direct-purchase customers who wish for access to the benefits of the MAS: sharing reviews, mass-updating purchased software, etc.
Worse, it leads to a potentially confusing situation where a customer may be running version 3.0 of an application that they direct-downloaded before Apple had approved it. When Apple does approve it and it goes live on the MAS, they are notified inside the App Store about the available update, but when it does update, it will update the previously installed MAS version, and not the direct-downloaded one. To benefit from the Red Sweater compromise, customers need to embrace the mental model that MAS and direct-download versions of the application are fundamentally different, and need to be managed and stored separately from one another.
I believe that the people this compromise serves are in general a more technically astute type of customer who will be able to embrace this difference, or will understand it with little explanation on my part. The less technical customers are not liable to be on the lookout for beta releases or “day of” releases of new software, and will happily wait until the MAS notifies them of a standard, Apple reviewed update.
February 9th, 2011 at 3:11 pm
Why do the apps need to be kept separate? If I get 3.0 from the MAS and then direct-download 3.01, I can replace the app store version with the new version (it’ll ask for admin privileges, of course). The prefs should sync, the receipt should already be stashed, and everything should be fine. When 3.01 hits the MAS it should note that I already have it and not bother me with the download, but if it does it’ll replace one copy of 3.01 with another with stricter permissions; no harm done. When a newer version than I have hits the MAS I should get it in the download list. Right?
February 9th, 2011 at 3:23 pm
Seth, I agree from the user’s perspective this would be ideal. However, some realities of the App Store make this difficult or impossible:
1. Apple will not update an application unless it contains a code signature, signed by Apple, that could only have been generated by Apple when the customer downloaded a MAS app.
2. Some developers, by choice or by force (myself included), are using different bundle IDs for the MAS version and direct-download versions. This means that preferences will not automatically be shared, and worse, that Apple has no means of identifying that the existing app the user downloaded from me is approximately the same as an MAS edition that they sell.
I have some bug reports in to Apple that suggest some ways that this could be made more streamlined. We’ll see how Apple evolves the system in the long term.
February 9th, 2011 at 4:14 pm
This seems a sensible solution for your MAS customers.
Just make sure you don’t forget about customers who actually prefer not doing business through the AppStoreMonster…
February 12th, 2011 at 4:05 pm
I’d like to reinforce Chucky’s point — until Apple resolves the issues you’re trying to solve for your customers (kudos deserved), I won’t be (and haven’t been) doing business with the MAS — I’ve never even logged into it. Hopefully, the Apps I use on a daily basis (including two of yours) will continue to offer direct download and either use the Sparkle framework to let me know about updates or have their updates announced by email or in sites that appear in my many NetNewsWire feeds.
February 20th, 2011 at 12:52 pm
I’m somewhat technically astute, but like the convenience of the App Store. It’s not perfect, but it will get better. I appreciate this solution, as it makes sense, now that I know what’s going on. Thanks for the explanation.