Has Apple changed the world again with the release of the iPad? To app developers, the change is both subtle and enormous. It's subtle because the new OS version 3.2 is only a minor update from the previous version 3.1.2, and because there are few changes in the APIs (just some additions). On the other hand, this is an enormous change because the iPad presents an entirely new market for both existing and new applications. It is likely to spark another "app gold rush" similar to what we saw when the App Store opened and the iPhone SDK was first released two years ago. It also significantly changes the development paradigm for programmers of iPhone apps. They must now learn to optimize their apps for the iPad as well as the iPhone and iPod touch.
Existing iPhone app support
One of the most exciting things about the iPad is that it can run virtually all of the 140,000+ iPhone apps already available. Because the iPad runs the same operating system as the iPhone and the iPod touch, existing apps can run on it displayed in the actual iPhone size centered on the iPad's screen, or in 2X zoom mode filling up the screen. Existing apps designed for the iPhone won't look as good as apps optimized for the iPad. But it is very significant that Apple chose to include backward compatibility for existing apps to take advantage of the incredible momentum of the "app revolution."
With the iPad and iPhone OS 3.2 comes three new categories of applications: iPhone Applications, iPad Applications, and Universal Applications. iPhone Applications are designed and optimized to run on the iPhone and iPod touch but can also run on the iPad in their original or 2X zoomed size. iPad Applications are optimized for and take advantage of new iPad features. Therefore, they are not compatible with the iPhone or iPod touch. Universal Applications are designed and optimized to run on all iPhone OS-powered devices, including iPhone, iPod Touch, and iPad. This new class of Universal Applications must include the logic to detect the device that it is running on and optimize the user experience for that device's hardware and screen size. The design of Universal Applications must be centered on a paradigm of conditional coding—where classes, methods, functions, and resources may be different for the varying device types, hardware capabilities, and API availability. Keep in mind that the conditional coding goes both ways. For example, the camera-related APIs are currently not available for the iPad.
Optimizing the user experience
Even though the iPad might be running the same OS as the iPhone, the user experience is actually quite a bit different, and app developers must be aware of these differences. For instance, supporting multiple orientations is valuable for certain apps, but is not necessarily required as there is a default orientation for holding and using the app on the iPhone. On the iPad, however, there is no default vertical orientation and as a result, every application should support multiple orientations. Additionally, given the vast screen real estate on the iPad as compared to the iPhone, it might often be valuable to combine multiple iPhone screens into a single screen on the iPad (potentially across a side-by-side split view). Finally, the iPad's screen size also allows for a new way to present options to users through a user interface component called Popovers. As a result of all this, developing Universal Applications in a single code base that are optimized for both iPad and iPhone/iPod touch is the next big challenge that developers must face and begin to master.
A new vein of Apple gold
In the sixty days from the announcement to the release of the iPad, there will be a mad rush as developers optimize existing apps for the new device. Those that get there first may be able to "strike it rich," mining this new vein of Apple gold!Spring 2010iOS Devices11