Yes, the iPad is a “Real Computer.”

April 21st, 2010  |  Published in mac and iphone  |  2 Comments

I’m in the middle of waiting around for my 3G iPad to arrive, but that hasn’t kept me from reading about iPads and peoples’ reactions to them. Emery Fletcher wrote a brief dismissal of the iPad on LinuxPlanet that summed up a certain school of thought:

Amid all the breathless hype about the iPad, I think one point has been severely overlooked: the iPad is not a computer, it is not a phone – it is constructed to be a receiving instrument. If it were an acronym, I would suggest it was PAD, Passive Amusement Device.

He goes on to say that “[real computers] let you talk back, add your voice to the topic, contribute your own masterpiece.”

Fletcher’s making the same mistake a lot of people have made: He’s assuming that because Apple has provided tools that enhance media consumption (iTunes, iBooks, etc.), and because media players have latched on to the large display and publisher-friendly SDK, that must be all the iPad is good for.

You wonder if people who think that way did the same thing when the first IBM PCs came out, assuming that because IBM marketed them for spreadsheets and word processing, PCs must have been good for nothing else.

Over the course of the week the iPad was in the house, I used Pages to do a little writing and editing, fiddled around with some photo editing software, stalked out how to connect it to online file repositories so I could get my creative work on and off of it, considered a few HTML editors for the iPad that had already hit the market in the week it had been available, and bookmarked apps that do things like make it easy to wireframe Web sites and iPhone OS apps.

So much for not being a “real computer.”

I also ordered O’Reilly’s Building iPhone Apps with HTML, CSS, and JavaScript before the end of the first day the iPad was in the house. Just over a week later, I had a copy of Stephen Kochan’s Programming in Objective C. I really want to learn the platform, and once I have I fully intend to write applications for it.

The thing a few years of iPhone use and a week of iPad use have caused me to consider is the ways in which Apple’s perceived “retreat” from Steve Jobs’ initial insistence than Web apps would be enough wasn’t really a retreat so much as a reframing. To help make the point, here’s a picture of all the apps on my iPhone, some with red checks.

app_chart.jpg

I’ve left a few things out:

  • I haven’t included the apps that ship with the iPhone.

  • I haven’t included the page of games I’ve got.

  • I haven’t included Web pages that I’ve saved as launcher icons.

If an app depends in large part on access to some sort of Web or online data service, it gets a red check.

Out of 70 apps, 58 get the red check. Of the remaining 12, most (seven) are photo or image apps of some kind. A few wouldn’t be there if I couldn’t use them with a Web service, but they can stand alone and require access to the hardware to work correctly.

Of the remaining five, three depend substantially on a network connection and wouldn’t be useful without one, even though they aren’t talking to Web services.

Even among the system apps, which I left out, the address book, calendar, map app, YouTube app, Safari, stock ticker and weather app are all dependent on Web services of some kind to be useful to me (I sync the address book and calendar with Google’s services).

In the end, though, if I just go with the 58 out of 70 apps that depend on Web services for the preponderance of their functionality, that’s 83 percent of the apps I use.

Looking at those 58 apps another way, we can ask how many of their related Web services could just as easily work with another, non-iPhoneOS client. The answer there is “all of them.”

In other words, developers might have wanted the ability to use a more complex toolkit than simple HTML, JavaScript and CSS allow, but since Apple gave them an SDK to play with, they’ve gone to work writing apps that talk to the exact same data stores a person sitting down to a PC would experience via HTML, JavaScript and CSS. That makes sense: iPhones and iPads are touch-driven and they’re very different from desktop browsers. HTML wasn’t created for touch devices and its conventions are dictated by the presence of a largish display and a mouse. All you get with the iPhoneOS SDK is a different set of conventions for getting at the same pool of connected data. That’s how it has worked out in practice, anyhow.

So what’s that got to do with me wanting to learn how to program iPhone and iPad apps?

Simple enough: Initially, I’ll be thinking in terms of how anything I write will relate to some sort of Web service. I’ve got a few ideas already, and I won’t be writing anything in isolation so I’ll be talking to other people who have their own ideas, but in the end anything I write will depend in large part on the Web and it will definitely involve people talking back to that content, either by organizing it in a way that benefits them, sharing their insights about the content with other people, or contributing their own content. Most of the apps I run on my iPhone are all about that. (O.k. One is for ordering pizzas and a few are for checking account balances, but still.)

The platform invites me to indulge my creative urges as a programmer, and it will allow me to create software that lets other people indulge their creative urges as explorers, travelers and sharers. And when I’m looking for a break from programming, it’ll allow me to sit down and write a story, compose an e-mail, edit some photos or wireframe a site.

It’s a real computer. Why some people don’t want to admit that is for them to answer.

Responses

  1. gl. says:

    April 22nd, 2010 at 9:26 am (#)

    interesting! apps as an overlay to web apis allows it to be controlled and open at the same time.

    also, why didn’t anyone tell me there was a pizza hut app before? ;)

  2. Yes, the iPad is a real computer. Just not like that. :: dot unplanned says:

    May 30th, 2011 at 4:35 pm (#)

    […] Let’s walk this back: […]

Leave a Response

© Michael Hall, licensed under a Creative Commons Attribution-ShareAlike 3.0 United States license.