While Apple's new iPad was widely anticipated to run the iPhone OS well before the company officially announced it, some observers have decided that it would make more sense for the tablet device to use the full version of Mac OS X instead, in order to enable the device to run a wide array of existing desktop applications.
Such a strategy would have resulted in the iPad looking more like Microsoft's Tablet PC and OMPC devices, which run Windows XP/Vista/7 with some extra software that enables stylus and or touch features.
Resolution problems in mobile devices
A primary problem with running a desktop operating system on a mobile device is that it would devote a lot of the available screen real estate to elements designed to support a mouse-based interface. While the iPad offers the same 1024x768 display resolution as the first iMac models, it squeezes those pixels into a 132dpi, 9.7" screen rather than the original iMac's 15" (13.8" viewable) display.
As screen pixels get packed together more densely, the targets of interface elements that were originally designed for a mouse pointer get smaller. But the iPad's multitouch screen is designed to be navigated by fingers, which are larger and less precise at pointing than a mouse cursor.
This means that in order to be usable, interface elements such as buttons, the menu bar, and window frames all have to be drawn larger than they would be on a conventional desktop computer at the same resolution. But since the resolution available on a mobile device isn't any greater, the user would end up with much less usable area for content, such as their browser page.
Rethinking for mobile constraints
Rather than delivering the iPad as a slower notebook with less usable area for content (which is essentially what Tablet PCs deliver), Apple used the iPhone as a starting point for creating its interface.
The iPhone already uses a relatively low but dense resolution, so the finger-optimized human interface guidelines Apple developed for it make much more sense on the iPad. Rather than being a dumbed down notebook, it's a scaled up iPhone.
In addition to thinking about usable screen resolution and interface target size, Apple also devoted a lot of thought into how the iPad would handle a multitouch interface, evolving upon the model set by the iPhone.
Applications created for the Mac OS X desktop all assume the use of a mouse or trackpad to navigate. While a few touch elements could be added to the mix as Microsoft has done with Windows 7 and as Adobe is working to do with Flash, all existing desktop software would have to be rewritten to take advantage of this new functionality, because existing titles simply wouldn't work as designed without a mouse pointer.
Cocoa Touch: no mouse pointer
For the iPad, Apple used the new Cocoa Touch platform created for the iPhone to deliver an interface that isn't just coated with a thin layer of touch functionality, but is designed from the ground up to be piloted by fingers. The differences are subtle, but significant.
With a mouse pointer, the user is constantly pointing at targets, and can select or open icons by clicking. In a multitouch environment, the system usually isn't aware of what a user is pointing at until his or her finger makes contact with the screen, which typically needs to be recognized as a click.
It quickly becomes complex (and increasingly less intuitive) to try to mimic mouse behaviors with touch. Rather than trying to emulate mouse pointer behaviors via touch and various combinations of gestures, Apple designed Cocoa Touch to intuitively respond to finger touches the way users would naturally expect to interact with the screen.
This resulted in Cocoa Touch being an entirely new platform developed around touch rather than a pointer. There's no mouse pointer on the iPhone's screen, and it's not missed because all the Cocoa Touch software developed for the iPhone is designed around direct finger contact rather than pointing devices.
Failing to make the leap
Most other mobile devices have attempted to retain some sort of trackball or directional buttons or stylus to rely upon in order to drive a mouse pointer, because they're trying to run conventional pointer-centric software. This was Microsoft's strategy with Window CE Handheld PCs and Pocket PCs, and its Windows XP-based Tablet PCs and OMPCs. None of those became very successful.
This is also an issue for Flash, because while new touch-oriented content can be developed using Adobe's latest tools, the vast majority of the installed base of Flash apps and other content make pervasive use of mouseovers and other dependencies on a pointer-centric environment. Trying to support this existing content on the iPad would result in a disappointing user experience.
In addition to simply lacking the vision to the migrate toward touch interfaces earlier (in the way Apple very decisively did back in 2007) other vendors have been slow to make a decisive leap into touch because doing so would necessitate a new platform (just as Apple created with Cocoa Touch).
The catch-22 of new platforms
The problem with creating new platforms is that they require a lot of work (and luck) to make them successful. In order to launch a really new platform, a vendor has to get customers to buy it, but users are unlikely to get very interested unless there are a lot of applications available.
At the same time, getting developers on board to create applications is difficult unless there is an existing installed base to sell those apps to, a vicious cycle that has prevented a number of promising new platforms from ever gaining any traction.
With Cocoa Touch, Apple was able to successfully sell the iPhone to a broad audience based solely upon its bundled apps, before ever launching a third party developer program. By that time, there was a significant demand for new apps that could fuel a development gold rush.
The iPad is leveraging that existing interest and expertise among iPhone coders to incite an expectation of tablet adoption that is driving iPad-centric development. If the iPad could run existing Mac software, there would be little new demand for software for developers to address. It would also run that desktop-centric software poorly, resulting in a disappointing experience for users.
Instead, developers have a great incentive to create original multitouch interfaces for their existing Mac apps, as well as more sophisticated versions of their existing iPhone apps. Apple has demonstrated examples of how to do both, showing off a multitouch version of iWork in addition to expanded versions of bundled iPhone apps like Calendar, Mail, and Notes.