I don’t presume to know what’s going to happen – if anything – now that Apple outlawed third-party API abstractions, but it did make me think a bit about the different ways people see portability.
The whole dance seems strangely fascinating: developers have obvious reasons to want their applications to run on the most diverse number of architectures – specially in a market which still isn’t so clearly defined as the PC market – and platform vendors have an equally obvious interest in having the best applications around run on their platforms.
But it gets further muddled up when platform vendors control the gateways to the platform, something that’s – as far as I can tell – unique to the mobile market. Now the platform vendor not only wants the best applications for themselves, they can filter out competing applications and leverage the system to keep good applications out of competitors’ platforms.
But back to portability. Portability becomes progressively harder – and less efficient – the higher we go in the abstraction scale.
Hardware portability may have many pitfalls, but is homogenous enough to be achievable in a wide range of targets without sacrificing too much functionality, as is the case for the Linux kernel.
OS portability gets a bit trickier. Even though the underlying hardware may have conceptually similar interfaces, the exposed APIs may vary greatly and the problem becomes two-fold: keeping the amount of OS-specific code low and providing an integrated experience in the different OSs. This can still be somewhat solved either with additional abstraction layers, like Java’s Swing, or with using one ported toolkit, like Gtk for Windows, but both options make sacrifices.
The current mobile market takes these problems a step further, by having wildly different hardware platforms, even more incompatible APIs and to some extent even different interaction paradigms (while most other PC architectures agree on folder/file, click/drag and window/desktop paradigms).
All this culminates in the only non-dubious argument for Apple’s move: quality assurance. They’re hold on developers might turn out not to be as strong as they wanted, but at least in terms of quality, demanding applications to be written specifically for them is a certain win.
Or course, this rambling is pretty much moot when it comes to Apple, which has a force-choke grip on their specific market niche and an equally force-related hypnotic influence over masses of developers and users. They can pretty much put “receive a kick to the balls/tits” as an EULA requirement and you’d still see millions flocking to Apple Stores to buy whatever cute gadget they’ve got next.
It’s just interesting as an open-source developer, to whom portability is such an obvious advantage, to see it being used as leverage tactic.
And in the end I’m only slightly annoyed by Apple’s decision because it’s another reminder of a possible 1984-esque future where access to technology – both by users and developers – is metered out by our not-so-benevolent corporate overlords.
There are certainly other giants out there intent on keeping general-purpose computing alive, but the thought is still haunting, that a sort of K-T extinction event might creep on us without our noticing and cause all the PC dinosaurs to die of uselessness when the mobile devices become powerful enough, suddenly taking away all our hacking freedoms.