App Store vs. apt-store
Being a completely new linux user used to suck. Not because there wasn’t much software for it, but as a completely new user, it was difficult to install the software you wanted. Software had to be compiled by the end user. You’d have to go out and get source to the software you wanted, the dependancies for that software, that dependencies dependencies, and so on. RedHat introduced its Redhat Package Management system to begin to alleviate these difficulties, but it was the Debian distribution that really solved the problems of software distribution on the Linux platform with it’s Advanced Packaging Tool, apt.
Using apt, it was possible to install and update software, and even upgrade the OS, with just a simple instruction. apt-get would download and install not only the program you wanted, but also take care of all of the dependencies it required. There were many official mirrors of the core debian programs, called repositories, and thousands of unofficial repositories one could rely on if they couldn’t find the application they were looking for inside the core debian distribution. apt was decentralized, yet controlled and efficient enough to provide a sufficient user experience for its core audience. If your software didn’t make it into the core repositories, users could paste a URL into a text file, and unofficial software could be distributed along side the core Debian distribution.
The advantage of being in the core apt repositories was that users wouldn’t have to go to additional lengths to install your software since it was in the repositories that shipped with the OS (meaning increased distribution and use). These were packages vetted by the core team, demonstrated to work with that version of the OS, and cause minimal compatibility issues. Unofficial repositories couldn’t inherently guarantee that level of safety and stability, but applications distributed this way were just as easy to install.
And none of this precluded someone from distributing an application as source and compiling it locally.
In short, apt kicked ass.
The apt repository model was replicated by RedHat (and Centos) with yum and ultimately powered the Jailbroken iPhone’s Installer.app.
The apt-get model is fantastic for distribution of open projects, but doesn’t work natively for distribution of paid applications (though it wouldn’t take much to add it).
Yet when it comes to the iPhone, Apple is intent on acting as the sole distribution outlet. There are several real benefits to both the end-user and most developers of Apple acting as the sole distributor, but it also means Apple is going to become (and maybe already has become) a bottleneck to distribution.
Apple is expecting itself to serve as the protector of its users, filtering inappropriate content (no porn apps) and malicious apps (no virus laden or private information stealing apps) out. And while this can provide a huge benefit to its users (and provide assurances on behalf of developers) for content and distribution, it also serves as a gatekeeper for applications that might threaten the current business model of Apple or partners, or more realistically, simply just be a bottleneck for releases. Applications will have to be re-approved, even for the slightest changes, in order to continue these assurances from Apple, as a developer could change an innocuous, approved application into a malicious one fairly easily. That’s a lot of responsibility for Apple. This means it’s going to be a lot harder to developers to rapidly iterate on their designs (as Apple promised would be possible) and push out updates, particularly critical security updates.
We’re apt to see an official apt-style model of distribution on the iPhone outside of the Jailbroken installer.app, though it doesn’t mean that the Jailbroken environment isn’t a fantastic playground for developers to innovate in (and it might even be possible to use the Apple SDK as a starting point, even for Jailbroken apps, though I’m not sure this is possible yet).
So what can be done about getting apps into the store faster?
For Developers:
Document like crazy – your code has an audience: You aren’t just developing so your code can be used by yourself and your team. It also has to be read by the Apple vetting team… EVERY SINGLE TIME. Flag changes you’ve made and make it easy to find what you’ve done (detailed changelogs are insanely valuable here). Apple has a limited team reviewing applications. Make your code so an intro computer science student could understand what’s going on. The reviewing team isn’t dumb, but after staring at other people’s source code all day, they’ll sure appreciate not having to decipher cryptic elements of yours.
For Apple:
[note I'm not in the developer program yet so I'm not sure how your process works entirely yet]
Implement a priority point release update approval process, and make it completely transparent. Security updates should be moved up in review speed. Security releases should be moved up in the priority queue.
Publish code documentation standards – if people know how to document their code for more efficient approval, they’ll assuredly do it.
Make your approval process transparent. Sure, SJ’s temper might decide who has a job this afternoon, but that doesn’t mean your app approval process needs to be equally as opaque. Let us know how things work. We’ll work on making our apps better suited to you as a result.
Yet, Apple in the Middle means that if the Middleman fails, nobody wins. There is absolutely no way to route around Apple, so as a developer, if Apple fails, gets backed up, or just decides your app is good enough as is, that’s final. At least wiht Apt, even if the distribution stopped updating, or the repositories went down, the system could still live on. No such luck here.
