Why I don’t program for the iPhone

Drifting off to sleep the other night, I realized that what turns me off about developing for the iPhone isn’t the overcrowded market, or the hardware with its limited resources, or even the multitude of fart apps. What turns me off is that the iPhone is a brilliant platform, but an awful ecosystem.

Programming the iPhone means, simply and solely, writing an ‘app.’ And an ‘app,’ that modern, pithy term for ‘application,’ as currently defined, means a narrow, vertically-oriented, resource-constrained program: an ivory tower. My ivory tower could be beautiful, comfortable, functional, even life-changing: but it is still an ivory tower, and one that is torn down in full whenever the iPhone user decides they want to run another application. Another ivory tower is built; it, too, eventually falls.

I wrote my first computer program at age 10, which means I’ve been programming for 32 years. For most of that time, I’ve done what used to be called ‘systems programming.’ This term is hard to explain, but I’ve always visualized it as being somewhere in the middle: not down at the kernel or hardware level, nor up at the pure, user-oriented application level. Rather, when I program I am navigating the swirly paths of APIs and protocols, moving amidst the foggy realm of interprocess communications, banging up against all sorts of scary and friendly daemons and scripts and ports and sockets and god knows what else. Systems programming is not about the edges, but rather about the center: it is the glue that binds the components, thus making a bag of parts into a coherent whole.

And this is what I like. Even in those primordial days of 8-bit microcomputers running CP/M, I was hacking on code (admittedly, written by someone else) that injected itself into the operating system, installing itself in the nether reaches of what seemed like a vast landscape of 64 kilobytes of memory, modifying the swamp of system call jump tables to intercept the BIOS calls. Why? So I could run what was then called a ‘computerized bulletin board,’ and what we’d now call a forum. (For a window into that time, see Remote CP/M Software Exchange Systems, List # 26; search for ‘Bethesda’ to find my face in the crowd of 1982.)

Eventually I discovered Unix, whose existential core not only admitted the relevance of systems programming, but reveled in it with its pipes, sockets, and processes. Programs on the scale that we’d call ‘apps’ today were rare; even those large-scale programs like Emacs were themselves an ecosystem, replete with hooks and modules and plugins.

My Mac today is a tiny ecosystem that I have let evolve out of 25 years of Macintosh technology, merged with another 25 years of Unix. Some of the utilities I use are descended from programs written a decade ago; every day I type commands that I’ve typed for so many years that I almost feel the patina on their letters.

Most of my research today revolves around heavily networked web-based ecologies of data, code, and the links between them. I’m exploring ways of distributing information even further apart, splitting up heavy applications into lightweight, gossamer threads of code out in the clouds. The work is intentionally airy, abstract, independent.

None of this richness is possible on the current iPhone platform. This restriction is akin to the earliest computers that only ran one program at a time; once the stack of punchcards was loaded, that program was the sole identity of that computer. In 1950, that was reasonable and expected; in 2009, it seems pointless and limited.

There is, of course, a world out there of the jailbroken iPhone or iPod touch. Talented folks have figured out the cracks and crevices, raised their flags, reskinned the official UI, even invoked the old Unix daemons to run silently in the background. But it’s not an attractive, welcoming world to me. I understand the challenge, appreciate the incredible effort in cracking open the back door to the ivory tower, and find a jailbroken iPhone to be useful, even essential. But it’s a risky world that can be entirely undone with a single software update from Apple. That’s not a healthy ecology, either.

So for now I will sit back, content in my comfortable Mac environment, happy with the symbiotic flora and fauna of code, and observe. Perhaps those ivory towers will turn to follies, half-ruined structures that still remain upright amongst the barren fields of the iPhone. And perhaps even later the follies will be remade into small but lively abodes, both large and small, all cooperating to build a more inclusive, verdant, and interesting landscape. And perhaps then, I shall start to program for the iPhone.

Published in: on 23 January 2009 at 12:54 am  Comments (1)  

The URI to TrackBack this entry is: https://johnlabovitz.wordpress.com/2009/01/23/why-i-dont-program-for-the-iphone-2/trackback/

RSS feed for comments on this post.

One CommentLeave a comment

  1. Another well thought out explication, John. Reading this reminds me why I like chatting with you so much. I’m curious to hear more about your “research [that] revolves around heavily networked web-based ecologies of data, code, and the links between them.” There are so many possibilities embedded in there and I’m wondering what you’re seeing.

    I feel very similarly. While the excitement of the developing mobile world has a lot of pull for me, I’m generally wary of putting much effort into building systems that might be displaced at that whim of an executive. That’s part of the reason I’m keeping a close eye on Android, even though the nay-sayers claim it won’t amount to anything.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: