Extension hell
In its recent Worldwide Developer Conference, Apple has announced that we’ll soon be able to write extensions to expand the capabilities of iOS in hitherto-unexpected ways.
I’m not an iOS developer, but this news hit me like a kettlebell to the nose. My memory extends (ha, ha) back to the days when Apple created such a system for Mac OS 7. The system was, indeed, extended in ways well beyond its original intentions. And it became spectacularly crash-prone as a result. (Even OS X is not immune to it: it’s worth searching “kext conflicts.”) These days, when I work on Rails sites, the development problems I encounter are without fail due to gems, the Rails equivalent of an extension. I’ve lost whole days trying to figure out which extension caused sites to fall flat on their faces & why.
So, why should my trepidation extend (ha, ha!) to Apple’s latest effort to enhance its OS? After all, today’s Apple is a very different one from the one that created Mac OS 7: they keep closer tabs on everything. By its very definition, opening up a system to accommodate unforeseen needs means that they open up the platform to unforeseen problems, bugs, and—and here’s the terrible word that brings back OS 7-era shudders—conflicts. Developers will take shortcuts (as developers will) and their extensions will be poorly tested and incompatible with other extensions—to say nothing of exposing users to security problems. Apple will play constant catch-up in its developer documentation.
It opens up the platform to chaos. It leaves the job of untangling the problem to the end-user, tearing her hair out trying to figure out which extension is causing her phone to go bonkers.
I don’t normally like to steal the words of fascists, but whenever I hear the word ‘extension’, I reach for my gun.