The day of Apple’s “Back to the Mac” event, I wrote that the Mac App Store announcement was the biggest news of the day. Many people misread that article, believing I was claiming the Mac App Store was the best announcement—that it was going to be, without exception, a great thing. But that article was mainly a discussion of the potential of a Mac App Store that worked much like the iOS App Store—by making it easier to find, buy, install, and update Mac software, the Mac App Store has the potential to affect the typical Mac user far more than iLife ’11, FaceTime for Mac, new MacBook Air models, and possibly even Mac OS X Lion.
But as I touched on in that article, whether the Mac App Store is good or bad on balance—for users or developers—and whether it turns out to be hugely successful or a relative failure will depend on quite a few factors. Perhaps the biggest concerns right now relate to the developer guidelines for submitting software, as well as restrictions the store places upon developers when it comes to many of the standard practices involved in developing and selling software. Here’s a look at what we know so far.
Curated? Or constrained?
Perhaps the biggest issue raised by the initial Mac App Store review guidelines, for both users and developers, is that many popular existing Mac programs—including many, many Mac Gems—would be flat-out barred from appearing in the store. Here are some of the things that are prohibited by the guidelines, along with examples of popular types of software that would violate these restrictions:
- Software that “change[s] the native user interface elements or behaviors of Mac OS X:” This single rule essentially bans thousands of current Mac programs and add-ons that let you tweak OS X to work the way you want it to work.
- Software that use private APIs (application programming interfaces): To be fair, Apple has always officially discouraged the use of private APIs. But it’s common for the company’s engineers to unofficially recommend their use, and a good number of popular Mac software titles do so.
- Beta, demo, trial, or test versions of software: Beta is understandable, but the ban on the other three types is significant (more on that in the next section).
- “Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them:” Could this one be more vague? If there are 200 image-conversion programs in the Mac App Store, does that mean that #201 will be rejected, even if it’s got the best features and interface? Let’s hope not.
- Programs that, after installation or on first use, “install code or resources in shared locations:” This rule is quite confusing, as Mac OS X provides a number of shared locations specifically designed for third-party applications to store code and resources. My only guess—hope?—here is that Apple’s definition of “shared location” is different from my reading of it.
- Software that downloads or installs “additional code or resources to add functionality or change their primary purpose:” Again, another vague one. Does this prohibit programs from using plug-ins? Or does, say, a plug-in for an image-editing program not “change the program’s primary purpose”? (Elsewhere in the guidelines, Apple seems to imply that plug-ins are allowed.) And what about, say, Firefox, which lets you download and install extensions that add functionality? (It’s a good thing Safari comes with all Macs, because it looks like Apple’s own browser wouldn’t be allowed in the Mac App Store based on this rule.)
- Programs that download other programs: This could mean no third-party download managers or enhancers. But does it also mean no FTP clients, Web browsers, or file-sharing utilities? After all, any of these can be—and frequently are—used to download other software.
- Apps that install kernel extensions: This excludes not only a number of popular networking utilities, but also third-party drivers for input devices.
- Software that uses its own license or copy protection: In other words, all software must use the App Store’s copy protection. In some ways this is a good thing for users, as the Mac Store’s rules appear to let you use a purchased program on any of your own computers. But it means developers who normally charge on a per-computer basis won’t be able to do so if they sell through the store.
- Software that has its own update mechanism—all updates must be distributed through the App Store: Fair enough, and as I noted in my earlier article, forcing all updates to go through the store’s official update mechanism should make it much easier to keep your software current. But let’s hope that, unlike the iOS App Store, the Mac App Store doesn’t require you to re-download each program in its entirety every time it’s updated.
- Programs that keep processes running after the program itself has quit, or that “are set to auto-launch or to have other code automatically run at startup or login,” but don’t explicitly request the user’s consent: In theory, this is a good rule, but many popular Mac programs use background processes, or automatically launch at startup or login, to provide their functionality. (I’ve got more than 20 user-level background processes running right now on my Mac, and I’ve got—no joke—37 login items.) Do these guidelines require, for example, each app to request consent each time it launches a background process? Again, let’s hope not—I don’t want my Mac behaving like early versions of Windows Vista, throwing up security warnings left and right.
- “Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta):” In other words, no apps that aren’t native, Intel-only Mac OS X apps. (Remember when Java was considered an official development environment for Mac OS X software?)
- Software that “request[s] escalation to root privileges or use setuid attributes:” This essentially bans backup software that requires root privileges in order to back up system-level files and folders.
- “Apps with metadata that mentions the name of any other computer platform:” What about VMWare Fusion, Parallels, and other virtualization packages that let you run other operating systems on your Mac? What about simpler cross-platform software that will obviously include “other computer platforms” in their metadata? Heck, what about games involving droids?
- Programs that don’t comply with Apple’s Human Interface Guidelines: OK, so this is actually a good rule for users. Sadly, it means that many of Apple’s own apps won’t be accepted in the store. (I kid.)
- Software that looks “similar to Apple Products or apps bundled on the Mac, including the Finder, iChat, iTunes, and Dashboard:” Another too-subjective rule that, if interpreted strictly, could include a number of popular file-transfer programs, Finder enhancements or replacements, chat clients, and media-management packages. And what about an e-mail client that provides more features than Mail but, like most modern e-mail clients, looks a lot like it?
- Software that lets you purchase or unlock features or add-ons outside the App Store: Again, it’s all App Store or no App Store, although Apple explicitly exempts “cases where the application hosts plug-ins or extensions.” On the other hand, the very next rule in Apple’s list says apps can’t include a “plug-in store.”
- Programs that are “content aggregators, or a collection of links:” Yet another vague rule. Does this prohibit RSS readers? What about link aggregators such as a Mac version of Flipboard for iPad?
- “Apps that rapidly drain a product’s battery or generate excessive heat:” Guess that means no Adobe Flash. (Though Apple didn’t wait for the Mac App Store launch to make that move.)
Of course, there are also the subjective bans on content similar to those for the iOS App Store: defamatory, offensive, and mean-spirited content; realistic images of violence; encouraging consumption of alcohol or illegal substances; “excessively objectionable or crude content”; pornography; and the like. And there are a number of other rules, technical in nature and not, that are vague enough so as to give Apple wide latitude to reject almost anything.
The big question I’m left with, after reading the Mac App Store’s guidelines for submission is, “What’s left?” I’m of course being a bit facetious here, but the fact remains that if I go through my Applications folder—and especially if I browse various folders inside /Library and ~/Library—there are a whole lotta programs, including many of my favorites, that would likely be rejected from the Mac App Store.
iOS App Store developer concerns, magnified
Beyond the question of app acceptance are issues about how selling through the Mac App Store will restrict the way developers can do business. As noted in our article on developer reaction to the Mac App Store announcement, there are a number of concerns we’ve heard about the iOS App Store that loom even larger in a store designed for selling Mac software:
No trial/demo versions.: This is a big criticism of the iOS App Store, but it’s bearable when you’re talking about software that sells for a few dollars or less (and many iOS developers deal with it by releasing free “lite” versions of their apps). When it comes to Mac software, the typical price is likely to be $10, $30, or more. As developer Jonathan Rentzsch noted, developers will hate not being able to give users a good look at their software, and users will surely balk at not being able to try the full version of a program before purchasing it. And “lite” versions are less appealing on the Mac side, as they’re usually just that—light on features. When spending $50 or more on a piece of Mac software, you want to be able to try out all the features before plunking down the cash.
No paid upgrades: Just as with the iOS App Store, developers must sell a major new version of their software at a single price—they can’t offer a reduced price for people who purchased earlier versions. They’re thus forced to make a difficult decision: If they charge full price for the new version, they risk alienating loyal users, who feel as if they’re being taken advantage of, but if they charge a lower price, they’re leaving money on the table because many new customers likely would have paid the full price.
Apple’s cut: Apple takes 30 percent of each sale. You might say, “So what—that’s exactly the same system as on the iOS App Store.” But the iOS App Store is a completely different market, and one in which there wasn’t already a thriving, successful software market before the store opened. There is such a market for Mac software, and there has been for decades. For all the reasons I mentioned in my previous article, that market is at times fragmented and, especially for new users, tough to navigate, but it’s there, and it’s possible for third-party developers to make a living selling their software directly to customers using online-hosting and payment-processing services that cost far less than 30 percent of each sale.
No direct relationship with customers: Developers don’t know who’s purchasing their software and, thus, can’t contact them directly. Similarly, the App Store is in many ways a wall between the developer and the user. Again, this is how the iOS App Store works, but it’s now how the Mac market works. For starters, there’s the topic of support. Technical issues are more complex on a Mac than on an iPhone, iPad, or iPod, and often require a more hands-on approach to support, yet the App Store model doesn’t encourage—indeed, to some extent it gets in the way of—this kind of direct user support. In addition, usually when you purchase or register software, the developer gains your email address and can thus contact you directly if a major issue arises—for example, to let you know that a major bug that affects data has been discovered and what you should do until an update is available. With the App Store model, the developer’s only option is to release that update as soon as possible and hope users don’t lose data in the meantime. Similarly, many developers will occasionally send an email to existing customers letting them know about new products. That’s not possible for customers who purchased via the Mac App Store.
Not knowing if an app will be rejected: Perhaps the biggest concern for developers of the iOS App Store is that there’s no guarantee that, after spending months and many resources developing an app, Apple will approve your app—even if you followed every guideline, Apple can reject it on even a conceptual basis. And that reality doesn’t seem to have changed in any meaningful way for the Mac App Store—for example, there’s no “pre-approval process” through which you can get the OK that your program is conceptually acceptable. This uncertainty has driven a number of established developers away from the iOS App Store, so I wouldn’t doubt if it alienates more than a few from the Mac App Store, as well.
It’s a beta
Now, it’s important to point out that the guidelines floating around right now are the 1.0 version—or perhaps not even that. It’s possible—nay, probable—that Apple will tweak the guidelines before the Mac App Store opens. And if the evolution of the iOS App Store’s guidelines is any indication, we should expect to see a good number of revisions over time, as well. (Indeed, the document itself even states, “It is a living document that will evolve as we are presented with new apps and situations, and we’ll update it periodically to reflect these changes.”)
And I hope that’s the case, because the overarching theme above, it seems to me, is that the Mac market is very different from the iOS market, but Apple is—at least so far—aiming to use the iOS App Store model, minimally changed, for the Mac App Store. And I don’t know how realistic that really is.
It’s also notable that, unlike with iOS, Apple has made it clear that the Mac App Store won’t be the only way to get Mac software—you’ll continue to be able get software, just as you always have, directly from developers. I’ve seen a good amount of concern that this is just a first step, and that eventually Apple will restrict all Mac software distribution to the Mac App Store, but there are a good number of reasons, unique to the Mac market and not present in the iOS market, why I don’t think that will happen. (For example, developer Rafe Colburn points out that such a move would kill a major market for Mac sales.)
Given that, why the concern over how Apple handles the Mac App Store? Can’t developers just choose whether or not to go through the store? Of course. But the risk here—and make no mistake, it’s a risk for both developers and users because of the impact it will have on software diversity—is that if the Mac App Store becomes popular enough, users may eventually expect, mistakenly or not, that it’s the only place they can get (or at least want to get) Mac software. If the App Store becomes the de facto method for getting new programs, we could end up in a situation where developers feel forced to write software that meets Mac App Store guidelines. And if that happens, and if those guidelines don’t change dramatically, we’ll all lose.