Smart Ways To Use The Mac App Store
(Expect updates to this article. I wanted it out fast and I so crave a copy editor.)
UPDATE:  SourceTree  Between a rock and a hard place – our decision to abandon the Mac App Store
The Mac App Store has been out for 4 days now and I’ve come to some conclusions I’m ready to stand firm on. They take the form of recommendations for IT folk, users and for developers. Any of them will change if and when Apple evolves the Mac App Store. How Apple could make things a lot better will be the subject of another article.
Before you read this, let me be clear. I don’t think the Mac App Store is an entirely bad thing. I’m not wishing Apple hadn’t done it. I am wishing it was different. I do hope it generates opportunities for developers, small and large, to reach new customers with great products built with passion and I think it will. The Mac App Store is, if managed carefully, good for the Mac. The problem is, it’s not likely to be managed carefully by enough people.
What follows is seen through the eyes of somebody who’s earned a large portion of his living for more than fifteen years supporting Macs and managing them in installations from less than a dozen all the way up to environments with more than a thousand Macs. Many battle scars have taught me painful lessons. It’s those lessons that shape this article.
Administrators and I.T. folk :
The App Store being accessible on your user’s machines is a recipe for complete and utter disaster. Wanna know how? Yes, many of these concerns also apply to web purchases but the ease, spontaneity and abstracted costs that will make it successful for Apple make it harder for you to manage.
• Accounting and budgeting. If your users are buying applications for their individual machines, you have no easy way to keep track of your company’s spending on software licenses. It can get suddenly very, very bad. See Configuration Management below.
• Compliance. If your users are buying and installing software on their individual machines, they have chosen to agree to license terms. Each one of them has entered into a legal contractual relationship with a software publisher on behalf of your company. Surely only a subset of employees are empowered to execute contracts.
• Configuration Management. The App Store is yet another mechanism for applications to be easily and invisibly updated in wonderfully user friendly ways. Developers love this. It means when they fix a bug they can have fewer copies of their product in the wild with the bug. Less support cost, fewer problems. Or so they think. In fact, it often makes them lazy or at least seem like it.  It means updates and new versions ship without sufficient testing and, if you watch, you’ll see products machine-gun patched as frequently as every few days. Arguably, if this gets your users bug fixes faster, it’s good for you. The problems come when you’ve tested a version, decided you can live with the bugs and a new version rolls out with shiny new new bugs you can’t live with. You may have a policy of quarterly updates to your build/deployment image, when every app in your tool-chain could get updated by any user you support, you’ve lost control of your planning.
• Budget forecasting and management. Another potentially more dire scenario is when a developer changes a file format. One user can decide to install an update or, worse yet, buy a new version and touch and update old files. Suddenly, you have to buy this new version for everyone. Got a thousand users? You’re in trouble. Serious trouble.
• Security. Theoretically this is less an issue with App Store apps that have limitations as to what they can do on the host Mac but, a change to an App can still break other Apps and customized workflows. Updates, particularly from Apple, that update a system service, like QuickTime can utterly shatter a complex workflow. If you’ve invested in automation like AplpleScript driven workflows, an update to a self contained app can grind work to a halt and create an emergency you, as the I.T. manager, are now on the hook to fix. Yesterday.
• Backup Management. You deploy a new tool, you investigate where those data files are stored. What file extensions they have. What dependencies they may include. You modify your scripts and selectors. You plan for storage space for online, near-line and offline backups. Suddenly some new tool makes its way onto your user’s machines. Suddenly you’ll be asked to recover files you may not even have known they needed backed up.
• Mac App Store apps can check for authorization against whether the Mac their run on has logged into the Mac App Store with the purchasers Apple ID or, apparently, ask the user to log in to Apple authorize. (see below). Are you going to demand that your users give you their Apple ID’s? Ex users? Perhaps create a company ID and share it with your users? Got an auditing plan?
Remove the Mac App Store from Macs you deploy. You should have disabled Software Update (SWUpdate) from Apple and implemented your own procedures and policies. Even Apple knows this is a good idea and provides tools for running your own SWUpdate server on your LAN. See: Apple’s Snow Leopard Server Product Info and Mac OS Hints : Create a transparent local software update server (note comments re: local DNS as opposed to public DNS and the workaround of defining the hose by IP rather than hostname)
Users/Customers:
If you are in any way making professional or even just ‘critical to you’ use of your Mac(s), the following suggestions may save your bacon. If you run a small shop, or a one person shop, take a break, I want to introduce your to your I.T. Director. Go, have a look in the mirror. Isn’t that a lovely face? Oy, such a punim and so smart too! Isn’t that a face you just want to be nice to and not make miserable?
You are your own I.T. Director. Heck, you’re your own CIO and CTO and CFO. Damn, you owe yourself a raise with all those extra responsibilities, best do it now or you’ll quit!
You need to worry about, on a much smaller scale of course, all the things covered in the section for I.T. professionals above. You may be a designer working on a freelance project. You can’t suddenly start giving files to a client they can’t open, or open with complete fidelity, on their older version of a tool you both started your project working with. You can’t afford to have some brand new bug you didn’t expect grind your work to a halt. So, aside from a set of policies of your own about how to run your one-person I.T. operation, here’s the basic advice for you:
1) Do not buy tools you use to run your business from The Mac App Store.
• If a tool you use now goes “exclusive” to the App Store, contact the publisher and complain.
• If a tool you want to use is App Store exclusive, look for another tool.
2) If tools you use are cheaper on the App Store than they are as a download, contact the developer and complain.
3) If a tool you use doesn’t make it possible for you to download a zipped or, better yet, .dmg packaged updates from the developer’s web site, complain.
Why? Because you should be able to decide for yourself when you install something new. You should be able to do it at your convenience when you may be offline making like Henry David Thoreau with a MacBook. You should be able to test a new version, perhaps try it on another machine or test environment on your only machine. (This is a great way to do that: (SuperDuper Testing White Paper [pdf]).
Now, for games? Inexpensive little doodads you want to experiment or just play with? Have at it! Of course have at it in a safe testing environment not on your production Mac and not in the middle of a deadline crunch.
Finally, if you’re a software developer, how should you use the App Store to your advantage.
Maintain a deep, deep linkable, accessible and standards-compliant website for your products. As complete a site as you can manage to truly maintain on your budget. Ideally, this includes: (and stay tuned to the end for why things that may seem unrelated to the App Store, do actually relate directly)
• Navigable links to your manual, license agreement and an FAQ you update based on the support questions you get.
• A ticket management system so users get an immediate response to support emails until a human has a chance to respond. The responder should give the user a ticket number and a timeframe to expect a response. The email should include links to your online manual and FAQ and, you should be actively managing this. If you’ve recently made a change that has users asking the same questions? Link to the answers or include them. And, finally, obviously, use your ticket system to identify ways to improve your product.
The following two suggestions can only, of course, apply to instances of your app you sell direct. Both, as I understand it, violate Apple’s guidelines for apps they allow to be sold via the store.
• Keep ‘in app’ update mechanisms in your products. Maybe you fork the default state of the update mechanism depending on the channel you sold through (default on for direct sales, default off from the App Store) or maybe you ask the user on first launch. You’ll balance the pros and cons for your product and what you know of your customers.
• Keep your in-app serialization. No, not your online-activation, your serialization. For products you sell direct, key the serial number to the name and/or email address of your customer. It’s copy protection to do this. If a a serial number leaks, you have some degree of recourse. Surely not bulletproof but recourse nonetheless. More to the point, the customer thinks you have recourse and that should encourage better compliance. This is much better than activation because, pure and simple, the legit customer suffers no pain. You also get ways you can kill off pirate copies. See your serials leaked to the usual places? Shut them off in an update. Want to know if there’s a lot more copies of one license than there should be out there? Watch your update server traffic. Yes, you need to tell your users their serial number is sent when checking for updates. Most won’t care. For products you sell through the App Store? Just hope nobody cracks Apple’s DRM. How’s that hope thing working out for ya?
(Important note here, according to this: Mac App Store licensing and copy protection, explained there’s no DRM but that’s clearly not the case and here’s proof: Ted Landau’s “Understanding Mac App Store Restrictions” I’m actually a little disappointed in Macworld because it was pretty clear they had to know there was DRM in there.  To me anyway, this quote is telling: “The way that identity check works is, the app itself (not the Mac App Store App) sees if it’s got authorization to run.”
More about that is here at Macworld’s licensing FAQ
“Are there family pack licensing options in the App Store?
No, apps are purchased for and owned by a user linked to a single Apple ID. But if you log in with that ID on all the Macs in your household, you can download and install your apps on each one.”)
One protection mechanism for thousands of Apps? That can’t be a juicy target, much.
• Keep your updates available from your web site available as .dmgs. Ideally the whole app, not just a patcher. It’s less testing work for you, and it’s less testing work for your I.T. manager customers even your customers who never see their I.T. person unless they look in a mirror. If you’re concerned about copy protection for web-downloaded uodates? Require a serial number and the owner’s email to sign in for a download. Annoying, better not to add this burden but still in the realm of civilized.
• Maintain and moderate user forums at your site. Be gracious, transparent, gently funny and active on your boards. Build a relationship with your customers.
Don’t go exclusive to the Mac App Store. Seriously. Do not go exclusive to the Mac App Store. Why?
• Go up and read all the stuff for users and I.T. folk.
• If you sell direct, you get to keep all the money after your commerce costs. Sometimes worse than Apple’s current cut, sometimes better. Your own choices about how you manage sales and with whom (or whether) you partner for fulfillment defines your costs. (One developer’s comments on the cut apple takes)
• If you go exclusive, and Apple changes the rules in a way that doesn’t work for you, you’ll be scrambling for other ways to keep your business afloat.
• Apple is an intermediary between you and your customers. Your future growth may very well demand you have ways to engage with them directly. Only by maintaining your own face to them can you have a chance of doing that.
• Keep the hopes you have about exposure for your products via the App Store in perspective. The descriptive data in the Mac App Store is not exposed to Google or Bing or Yahoo or any other web search engine. If the Mac App Store becomes as much an uncurated mess as the iOS App Store, you’ll be responsible for generating your own buzz. Your real estate for information a customer may want to self support or make purchase decisions isn’t exposed to search and won’t show up in search results when they are looking to solve a problem your tool is perfect for that they may not have thought they’d be able to do with software. A full deep website will help you be visible on, and off, the Mac App Store.
Does this mean developers shouldn’t sell in the Mac App Store? Of course not! It can, I hope, be a great promotional vehicle for wonderful tools made by small shops who really care about and understand their markets. Just remember though, Apple puts a very prominent link to your site right in the App Store window for your product. Use this to your advantage.
One final thought, if you push your prices down to get traction in the Mac App Store you’ll work your fingers to nubs trying to get back. The nature of that kind of marketplace causes a race for the bottom. Don’t be a sucker. Price on your value. Price on what it costs you to give outstanding service to your customers and be patient enough to let those who race to the bottom ruin their reputations.
