Only a few months after the iPhone’s release, the open source community had accomplished something that many thought impossible. Despite Apple locking the device down, developers had gained access, reverse-engineered the SDK, and gone on to build a free open source tool chain that allowed them to build native applications for the device. At one point, it was estimated that more than one-third of the iPhones on the market had been “jail broken” by their users, allowing them to run these unsanctioned third-party applications.
This open source development effort is ongoing today, and if you want to know more, I recommend iPhone Open Application Development, Second Edition by Jonathan Zdziarski (O’Reilly). However, the book you hold in your hands isn’t about the open source “hacker” SDK, because in March 2008 Apple publicly changed its mind and released the first version of the native SDK to a waiting developer community. Whether this release was in response to this effort, or perhaps because it was (the notoriously secretive) Apple’s plan all along, we’ll probably never know.
When the native SDK was introduced, a number of people in the industry argued that it was actually a step backward for developers. They felt that web-based applications, especially once home screen icons for these applications arrived on the 1.1.3 firmware, were good enough. By writing code specifically for the iPhone in Objective-C, you were making it more difficult to port your applications, and porting a web application more or less consisted of simply restyling it using a new CSS template.
It seemed that the users of the applications disagreed. It’s arguable why this is the case, but it’s very hard to make native-looking web applications that can be reused across many different platforms, though it is possible. Just as applications on the Mac desktop that have been ported from Windows tend to stand out like a sore thumb by not quite working as the user expects, web applications, especially those that are intended to be used across different platforms, tend to do the same.
If you integrate your application into the iPhone ecosphere, make use of the possibilities that the phone offers, and optimize your user interface (UI) for the device, the user experience is much improved. It’s also really hard to write web applications that work well when you need to design for a smaller screen, implying as it does a simpler UI and less exposed functionality, without using native controls.
The obvious reason to use the native SDK is to do things that you can’t do on the Web. The first generation of augmented reality applications is a case in point; these needed close integration with the iPhone’s onboard sensors (e.g., GPS, accelerometer, digital compass, and camera) and wouldn’t have been possible without that access. Although the iPhone’s Safari browser supports the new geolocation capabilities HTML 5 provides, this doesn’t alleviate the problem entirely. It’s doubtful that all platform-specific hardware is going to get the same sort of treatment, so it’s unlikely that you will see the arrival of augmented reality web applications.
Sometimes it’s not about doing things that can’t be done; it’s about doing things faster, and doing client-side error handling. For instance, the Apple iTunes and App Store applications that are provided with the iPhone are actually web applications wrapped inside native applications. Just like the iTunes Store on the Mac, the main display you see is a web page, but the surrounding infrastructure is a native application. This means that while the application can’t do a lot without an Internet connection, it can at least start up.
But those are extreme examples. A lot of the applications in the App Store combine remote data and native interfaces. Without access to the network, some of the UI is generally disabled. However, native applications can be built to degrade gracefully when the device’s network connection disappears or if it was never present in the first place. The user can still use the bits of the application that don’t need a network connection to work.
Sometimes it’s also about what an application doesn’t need. If it doesn’t need a network connection, the idea that your phone needs to be connected to the network to use it, sucking extra battery power in the process, is wasteful. Even when it is connected, the device isn’t always connected to a fast Internet connection. Anything you can do to minimize the amount of data you need to suck down the data connection will improve users’ interaction with your application. That means generating your UI locally, and populating it with data pulled from the Internet.
Network performance will affect the user’s perception of speed; rendering your UI while a web request is made to populate it allows your application to remain responsive to user interaction even while it’s waiting for the network. That can only be a good thing.
I haven’t even mentioned game development yet, and with Apple pitching the iPod touch as “the funnest iPod ever,” that’s important. You cannot develop the sorts of games now starting to appear on the App Store using web-based technologies. While this book covers the basics of how to program for the iPhone or iPod touch, if you want to delve deeply into game programming on the platform, I recommend iPhone Game Development by Paul Zirkle and Joe Hogue (O’Reilly).