Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.



Pick an apple! 
Springy Dock Tricks

If you drag a file and hover over Dock icons, various useful things happen which are similar to Finder springing. If it's a window, the window un-minimizes from the Dock. If it's a stack, the corresponding folder in the Finder opens. If it's the Finder, it brings the Finder to the foreground and opens a window if one doesn't exist already. But the coolest (and most hidden) springing trick is if you hover over an application and press the Space bar, the application comes to the foreground. This is great for things like grabbing a file from somewhere to drop into a Mail composition window that's otherwise hidden. Grab the file you want, hover over the Mail icon, press the Space bar, and Mail comes to the front for you to drop the file into the compose window. Be sure that Spring-Loaded Folders and Windows is enabled in the Finder Preferences window.

Visit plucky tree

Submitted by


The iPad: A Developer's Anti-Contrarian View

Send Article to a Friend

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!"


CrashPlan is easy, secure backup that works everywhere. Back up
to your own drives, friends, and online with unlimited storage.
With 30 days free, backing up is one resolution you can keep.
Your life is digital; back it up! <>

Comments about The iPad: A Developer's Anti-Contrarian View
(Comments are closed.)

"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."

That's a bit of a straw man. Doctorow isn't saying that you can't write iPad apps on Macs. Instead, I think one of Doctorow's problems is that you can't write iPad apps *on the iPad*. Of course you can write apps for it - but only if you're doing it on a Mac. Chances are that a lot of kids will receive iPads instead of PCs from their parents, and schools will use iPads in one-on-one programs. Those kids won't be able to use their iPads to write iPad apps.

What's more, Apple (mostly) doesn't allow apps which interpret code into the App Store. So something like HyperCard or a BASIC interpreter (tools which are typically used by kids to learn how to program) won't be available for iPads.

It's not all bad. Kids will very likely be able to write web apps using only an iPad, and a Mac mini isn't prohibitively expensive for most families.
Matt Neuburg  An apple icon for a TidBITS Staffer 2010-04-05 13:25
I don't believe he's saying you can't program the iPad on the iPad, and in any case it wouldn't be a very telling point, since you also can't program the iPhone on the iPhone, you can't program an Xbox on an Xbox, etc. etc. - heck, when the Mac first came out you couldn't program it on the Mac (you had to get a Lisa). Mostly it seems to me he's saying the iPad is an appliance. Well, duh. And anyhow, Cory Doctorow is not the point; I'd written the article (all but that paragraph) before reading his screed.
"I don't believe he's saying you can't program the iPad on the iPad"

He touches on a number of points. One of them is that you can only buy apps on iPads, not make them. There's no HyperCard for iPads, and if Apple doesn't change its rules, there won't be one.

The comparison to iPhones and Xboxes misses the point, because people don't use these devices as replacements for PCs. Schools don't hand out Xboxes or cell phones in one-on-one programs, and parents don't give their kids an Xbox instead of a computer. The iPad, on the other hand, very likely will be used in that fashion.

The criticism here is quite specific: Kids whose main computer is an iPad will have a hard time using it to learn how to write code.
I know this will come as a surprise to most nerds and propellor heads, but not all kids want to learn to write code. But, as the iPad is not a computer replacement, if they want to learn they could probably use the family's desktop.
I have never seen anyone claim that all kids want to write code. However, some kids do, and a lot of schools have programming classes. Giving kids an iPad and then asking them to use their parents' computer isn't really an option. Besides, not everyone has a computer.

Finally, I think that eventually, the iPad will be a computer replacement for many people.
RidleyGriff  2010-04-06 18:08
Do you not also think that those students inclined to tinker will find their way to the jailbreaking community for iPhone OS? That this will not lead to further exploration? The curious are already finding their way, it could be argued.

Furthermore, I guess I don't see the point in arguing for being able to develop for a device, on a device, when the device is such a youthful platform. The iPad is days old. There's only one word processor for it, much less programming tools. It seems a rather intellectually dishonest argument to be making.
How does jailbreaking help? Are there BASIC interpreters for jailbroken phones? I guess it would be possible to install something like Perl on a jailbroken phone and write command-line apps, but telling kids to jailbreak their devices and write command-line Perl apps doesn't strike me as a particularly good solution to the problem.

And yes, the iPad is days old, but the iPhone isn't. The problem here is quite obviously not the age of the device. The problem is that Apple does not allow apps which interpret code into the App Store; hence, no HyperCard, no BASIC. The iPad could be two decades old; Apple's rules would still prevent these apps from appearing on it. So the intellectually dishonest argument would be to attribute the problem to the age of the device, when it's quite plainly Apple's rules that are the problem :-)
RidleyGriff  2010-04-07 11:25
But you wouldn't argue that people are being held back by not being able to program on their iPhones, would you? The whole argument is that appliance devices hinder exploration and discovery, not that we need to run BASIC on every device. The Jailbreaking community no doubt has piqued the interest of many kids and encouraged them to explore and learn further.

My larger point re: the iPad still stands - it is such a young platform it doesn't even have basic productivity tools yet. It is very clearly being marketed and sold right now as a device, not a full computer, and can't yet be used as one by anyone. Down the road, when it has matured and is being used as a sole computer by some as you project then Apple's stance will be a problem (if it stands). But we are clearly some time away from that scenario.

You can't critique them for future actions/scenarios that haven't yet occurred. It's, you know, dishonest. ;-)
I think we disagree on what the whole argument is. The argument I am making is very specific: The iPad will be used by schools in one-on-one programs. Parents will give iPads to their kids as their main computer. Those kids will not be able to use the iPad to learn how to program: there's not even a Logo interpreter in the App Store.

Furthermore, not allowing interpreters means IDEs and DBs with advanced features are not allowed.

How is any of this dishonest?

Neuburg's point that the iPad is great to program for is entirely orthogonal to the whole discussion as I see it, since he is using a Mac to write the actual code, not an iPad.

My criticism has nothing to do with the future. If you were to write a BASIC interpreter for the iPad *today*, Apple would not let it into the App Store. The age of the platform is not the reason why there are no BASIC interpreters in the App Store. In fact, there is at least one BASIC interpreter that was submitted and rejected (called BasicMatrix).
Have you seen the errors you're Tidbits app throws? I sent them to Glennf
Adam Engst  An apple icon for a TidBITS Staffer 2010-04-06 06:16
Yeah, the current TidBITS app does some wildly clever (and funky) things to work around limitations in Apple's controls, and thus doesn't work well on the iPad. I'm talking with Matt this week about an iPad-specific interface that would eliminate these troubles.
Matt Neuburg  An apple icon for a TidBITS Staffer 2010-04-06 10:48
The TidBITS News app has some visual glitches on the iPad, but that's Apple's bug - the iPad is supposed to reproduce the iPhone / iPod touch behavior exactly, and it doesn't for our app. However, the TidBITS News app works fine on iPhone / iPod touch, and that's what it was written for, so I'd have to say there's no problem. I use it every day and find it the best way to keep up with TidBITS. If the XML feed gets messed up, in can throw up an error message, but that message is perfectly correct (it's saying that the XML feed is messed up!), and such a thing has only happened once since the app went live, and was fixed at our end in a few minutes.
Nick Morris  2010-04-06 02:06
Actually, I have found the iPad a real challenge to program. Matt is right, you use the same tools as for Mac OS X and the iPhone, but as Adam said, it is a 'blank slate'. On the iPad you have to think about the interface and the user in a different way to what you would do on the Mac or iPhone. This is the really difficult bit as you want the iPad, as Adam put it, 'morph' in to the App. This takes thought, and careful planning. I know this as I have written an App for the iPad and numerous Apps for the iPhone (all can be found on the App store). I found coding for the iPad easy, and interface very difficult as it required a new way of thinking about things.
Adam Engst  An apple icon for a TidBITS Staffer 2010-04-06 06:18
That's true - we went through this when designing the TidBITS News app for the iPhone. But because of Apple's relatively small set of interface controls, what we saw is that people tend to copy other interfaces that work well, and refine them slightly in the process. And thus the user interface ecosystem evolves.
Revolution is the modern equivalent of HyperCard, and the ability for Revolution to create iPhone/iPad apps is already in alpha form and looking very good.
Matt Neuburg  An apple icon for a TidBITS Staffer 2010-04-06 20:20
Sounds cool. But $999? Competing with "free" (Xcode) won't be easy.
Another advantage of programming for the iPad is that when you press the "Build and Debug" button in Xcode, your app is much faster ready for debugging on the iPad than on the iPhone. One of my apps is fairly big (20 MB) and it takes a long time to install it on the iPhone 3G. On the iPad it's almost as fast as the simulator.

Downside: I need a faster iPhone :-)
"Cocoa and Objective-C don't even take care of basic memory management for you! "
Actually in Snow Leopard they do (GC) and if 4.0 doesn't have it it will eventually be there.
Matt Neuburg  An apple icon for a TidBITS Staffer 2010-04-08 14:35
But I'm talking about the iPad now.