Only time will tell whether the iPad really catches on. Expensive toy? Perfect grandma computer? Kindle-killer? First of a raft of competing touch-tablet devices? It's fun to argue and speculate, but there's little point debating the future of the iPad, because it's in the future.

This, however, I can tell you right now: it's great to program for. I know this even though I haven't yet written a line of iPad code. You see, the way you program for the iPad is essentially the same as the way you program for the iPhone - and that is something I have done. In addition to coding the TidBITS News app (see "Free TidBITS News iPhone App," 4 January 2010), I've written:

• A free joke app called 99 Bottles! that uses Mac OS 9 speech synthesis to sing "99 Bottles of Beer on the Wall," in the traditionally annoying fashion of that song.
• A free utility app called Albumen that looks in your iPod (music) library for albums and displays their song title and artist information in full (unlike the iPhone's native display of that information); this is particularly useful for classical music, where artist and title information tends to be long.
• Two free educational Greek and Latin vocabulary flashcard apps. These are tied to specific textbooks and are of interest only if you're using those textbooks.
• One paid app, called Zotz! It's a simple casual game, without time pressure or scoring; it's based on my Mac OS X Zotz game, which is free (look in the Cocoa Things section of my site). But please buy the iPhone version so I can earn back my $99 developer fee! Here endeth the Shameless Plug.
• Some contract-based stuff I can't tell you about.

I started writing my first app about five minutes after I received my iPod touch, in early October 2009; so you can see that I've been banging away at the keyboard diligently since then. My first move, indeed, was not to write code but to read about coding. I worked my way through some essential documentation at Apple's site (reading it, of course, on the iPod touch). And as I read, one thought kept running through my head: "This is really, really clever."

Here's why. The iPhone programming framework is essentially a variety of Cocoa - the same Cocoa that I've been using for years to write Mac OS X applications. Mac OS X Cocoa has a long and venerable history, stretching back to the 1980s and the days of NeXT. So it's very powerful, but it has grown by accretion and is full of complexities and inconsistencies that can confuse and frustrate the developer. The iPhone version of Cocoa, on the other hand, feels as if the folks at Apple said to themselves: "This is a completely new device, so we can start over from scratch!" The iPhone programming framework has a deliciously clean, rational quality; it's recognizably Cocoa, but it's a better Cocoa.

Not only did the Apple folks rationalize and simplify the programming interface; they also drastically simplified the design interface. Compared to Mac OS X, there is an astonishingly small repertoire of iPhone "widgets" (buttons, text fields, that sort of thing). Of course if you're writing a game you can take over the screen and design your interface from scratch; but if you're writing a utility app, your design is likely to consist of a very few standard elements - a navigation bar at the top, a toolbar or tab bar at the bottom, some buttons and text fields, maybe a table or a Web view, and boom, you're done.

Part of the reason for this, of course, is that the iPhone screen is so small. Apple has put considerable ingenuity into making the most of a limited space. In particular, they've made it easy to set up navigation between screens of information. For example, the TidBITS News app has two screens: a list of article titles, and the body of a single article. On the first screen, you tap an article title to go rightwards to the second screen and read the article; on the second screen, you tap a button to go leftwards and see the list again. This is all built-in interface; the app takes advantage of the tools Apple hands you to do this "list-and-detail" thing. That's why lots of apps behave in this same way.

With the iPad, Apple has done yet another clever thing - nothing. Okay, it isn't really nothing, but the programming and design interfaces for the iPad are nearly identical to those of the iPhone. By making almost no change, Apple has ensured that both programmers and users remain in a familiar world. There's a lot more screen real estate on the iPad; but Apple has eased the transition by allowing the programmer to display more than one "screen" simultaneously. Look at the Mail app, for example: in landscape orientation, it shows the "list" screen on the left and the "detail" screen on the right; in portrait mode, it has "detail" occupying the whole screen and the "list" screen at the left floating over it. In making the TidBITS app iPad-native, I'm thinking we should simply copy that model.

Another great thing about the iPhone and the iPad is that a simple app can be a good app. This is in part a consequence of the non-multitasking nature of the platform (see "Does the iPhone OS Need Multitasking?," 8 February 2010). It's common for a user to jump into an app, do something, jump out and do something else, and come back later (maybe days later) and expect the app to have preserved its state. A novelty or simple utility app that, on Mac OS X, might elicit contempt ("That's all it does?"), can be a hit on the iPhone. So the bar to entry is a lot lower.

Thus I was surprised at Cory Doctorow's much-cited recent critique of the iPad, since I think he has it exactly backwards. I completely agree with his nostalgic appreciation of the Apple II (which came with a printout of the disassembled ROM code) and of HyperCard (see "HyperCard 2.2: The Great Becomes Greater", 14 February 1994); I, too, cut my programming teeth on those. And I, too, believe that a computer is to program; that's why I've always been interested in whatever makes that true for the Mac (see "Yes, Virginia, There Is a REALbasic", 17 August 1998). But the iPhone, and by extension the iPad, are much more programmable than Mac OS X, because they're so much simpler and easier to develop for.

I'm not saying that the iPad is as easy to program as using HyperCard or REALbasic. There's definitely a learning curve. Heck, unlike a scripting language, Cocoa and Objective-C don't even take care of basic memory management for you! But the explosive growth of the number of available iPhone apps shows clearly that lots of people for whom programming Mac OS X seemed too hard, or not worthwhile, have jumped into iPhone programming with all four feet. And if the past is any indication of the future, I think we can expect the iPad to bring in even more programmers (especially given the relaxation of the screen space constraint). So the iPad section of the App Store, and hence the iPad platform itself, should be very healthy going forward.

Certainly, if I wanted to be negative, I could rail against the cost of becoming an iPad programmer. (In fact, I think I will. Come on, Apple, $99 per year is a reasonable price to be allowed to sell your apps through the App Store, but writing and distributing free apps should be free!) And, granted, the App Store interface - indeed, the App Store concept - isn't all that it might be. But my overall reaction to the iPad as a developer is extremely positive. I think the iPad's cheerful, bright screen cries out: "Hey there, programmers and prospective programmers, come on in! The water's fine!"