The imminent Mac App Store
Wolf Rentzsch: Mac App Store
My fellow Mac developers are laughing at the Mac App Store guidelines. They’re reporting that apps they’ve been shipping for years — a number of them Apple Design Award-winning — would be rejected from the Mac App Store. These are proven apps, beloved by their users. The current guidelines are clearly out-of-touch.
While I disagreed with his reasons for shutting down C4, I agree wholeheartedly with everything in his post on the new Mac App Store.
He goes on to explain that many Apple Design Award-winning applications would be rejected from Apple’s Mac App Store outright, which sounds rather counter-intuitive. In fact it gives me concern that the Mac App Store might be edging towards the bad days of Windows shareware— a repository of little besides bland middle-of-the-road fare, yet prominent enough that most of the audience won’t look elsewhere for good software.
At the end of the day I’m happy to let Apple choose to vet what software it wants to ship in its store — it is Apple’s store after all, and I wouldn’t get all pissy if, say, Best Buy didn’t want to carry my product. I think that it should only vet applications in a user-centric way, however, which means not checking for uses of private APIs, and not limiting what an app can do with the user’s machine.
For instance: their clauses right now explicitly forbid any attempt to gain root privileges— which are a necessity if you want to provide, say, a nice firewall rule manager. This isn’t a nasty exploitative root privilege escalation through hacky means, however, it’s using documented authorization APIs, meaning that the system will require the user to confirm that they want this to happen, letting them know exactly which app requested the rights, etc.
In 10.6, there’s a new framework called ServiceManagement. It contains methods for working with launchd daemons: reading their config, updating them, etc. It also includes a really quite secure means of installing a root helper tool for your app without using setuid binaries. There are some strict rules, and everything must be tied up with code signing, but if you conform to those guidelines (which are designed to prevent people modifying your app/tool after installation to do something malicious without the user’s knowledge) then you can install a launchd daemon which will run as root when you need it to do so.
In that last case, I’ve written apps which do that. One app which I could potentially put on the App Store tomorrow is a Final Cut Server integration application. It’s designed to let you input your existing data schema and tables using a common tab/comma/newline/whatever delimited file, and lets you specify how your existing data should map into your new Final Cut Server system. It will then run the import, batching millions of files and suchlike. However, in order to import things into Final Cut Server you must run as root— the command-line utility shipped with FCS won’t let you modify data unless it’s called with an effective user ID of zero. So this app uses the ServiceManagement framework to install a daemon which runs on-demand, listening for securely-encrypted messages from the GUI app, which the root daemon then turns into a carefully-packaged command-line invocation.
The Mac App Store would deny that though, because it uses privilege escalation. It also makes use of something kinda-sorta like a private API in the shape of the command-line tool for Final Cut Server, which isn’t externally documented.
So it wouldn’t be saleable. End of story.
Therefore, my suggestions to Apple would be:
Vet applications based on their functionality and security as appropriate to the application’s problem and implementation domains.
If an application requires privilege escalation or needs to install code elsewhere in the system (be it a kext or a preference pane) require the developer to tell you this up-front so you can vet these features from a security standpoint. Understand and make clear that this means a longer review time.
Don’t use the store as a means of enforcing programming best practices. It’s a store-front, not WWDC.
If you feel something about the app might go wonky, such as the use of a private API or command-line tool, or something else which might change in future, don’t reject the app outright— put a bloody great badge on it. Require the developer to state explicitly what the dependencies are. I’d be happy to say that my FCS importer app works on FCS 1.5.x, but might not work on FCS 2.0 whenever that arrives. I’d be ecstatic at that, because I actually don’t want a lot of angry customers complaining to me that my app doesn’t work with FCS 2.0— I want to tell them that right up front.
At the end of the day, I’m looking forward to participating. I’ve got a couple of Mac apps I’ve been sitting on here for a while now which I’d like to bring to the App Store, so I’ll hopefully be able to get one of them ready within the next 90 days.