Learning the iOS 4 SDK for JavaScript Programmers

Chapter 1. Why Go Native?

Those who frequently develop mobile web applications with HTML, CSS, JavaScript, and related technologies tend to find a way to reuse those comfortable tools for every app challenge. The iOS (formerly iPhone OS) platform has attracted much attention in the web developer community, and Apple continues to evangelize web app development for the platform.

At the same time, there’s evidence of a desire among developers to adapt their web technologies to replicate the look and feel of native iPhone and iPad apps, whose look and feel users know from the built-in apps and other apps downloaded from the App Store. Perhaps you’ve used third-party libraries, such as iUi or jQTouch, to deploy your content and application ideas so that they look and behave like native iOS apps.

Despite advances in web technologies—especially the HTML5 and WebKit extensions to CSS and Document Object Model (DOM)—an iPhone or iPad web app lacks access to several key facilities built into iOS. You must also deal with the Mobile Safari browser address bar, especially if your users aren’t experienced enough to generate a home screen icon for your app. Additionally, even though both your iPhone-specific styles and scripts target a single OS platform, you still may encounter compatibility issues with earlier versions of Mobile Safari running on iPhone and iPod touch units in the field that haven’t been updated to the latest OS versions. For example, I saw from my server logs that nine months after the release of iPhone OS 3.0, some users of my native iPhone apps continued to use iPhone OS 2.2, especially with iPod touch devices (most of whose users once had to pay for major OS upgrades).

In other words, the choice to reach iPhone and iPad users through web applications, which were supposed to simplify development, introduces its own set of complications. Maybe it’s time to make the leap and start developing native iOS apps. This chapter highlights iOS features you can use if you choose to develop native apps—features that are not available to web-only apps. Even if your app designs don’t require a lot of native OS support, a native app still has advantages over web apps. To provide a fair and balanced picture, I’ll also discuss what you lose by using a native app over a web app.

Using an App Offline

It is hard to argue with the fact that iOS devices are intended to be used in a connected world. WiFi is built into all devices by default; iPhones and iPads (and likely future devices) equipped with 3G also have cellular data connections that free users from lurking around WiFi hotspots. Unfortunately, users may be out of WiFi range, have no cellular connection, be running dangerously low on battery power, or be secured inside a jet-powered flying metal tube whose attendants prohibit radio contact with the ground. When an iOS device cannot access the Internet, a traditional web app—which resides entirely on your web server—is not accessible. Although it is possible to code a browser-based web app to be copied and stored on a device, the mechanism isn’t foolproof.

A native app, however, is at least launchable even when the device has no connection to the Internet. Exactly how usable the app is while offline depends on the nature of the app, of course, but it’s clear from the apps that Apple supplies on every device that an iOS device does not completely die if Internet connectivity is missing. You can still listen to music, watch previously downloaded videos, look up your contacts, and tap out notes; with an iPhone and iPod touch, you can still be awoken by an alarm or calculate a total; and with any camera-equipped device, you can take pictures. Applications you download from the App Store let you do tons more things, such as play games, read gorgeous-looking downloaded books, edit photos, figure out restaurant bill tips, look up a dictionary definition, or identify a bird in the nearest tree—all without the need for a constant Internet connection.

Many native apps also connect with the Internet for some functions. Games commonly upload scores so you can see how well you perform against other users around the world. Many apps also rely on the Internet for up-to-date information, such as email apps, news readers, weather apps, Twitter and Facebook clients, and many more. For designers of many of these types of apps, the challenge is to create an app that can perform its basic functions offline, even if it means the user needs to download some current content before cutting the wireless cord. Once disconnected from the cloud (perhaps even while flying above the clouds), the user can relaunch the app and still access fairly recent content.

Unfortunately, you cannot rely on Mobile Safari to preserve a downloaded web page’s content for long. Even if the user manages to keep the Safari window open, restoring it for use sometimes causes the page to attempt to reload itself from the server. No server? No content, even though it may be in a cache someplace on the device.

Some web apps have successfully been converted to bookmarklets. A bookmarklet is a browser bookmark that contains a javascript: or data: URL whose code generates the HTML, CSS, image data, and JavaScript code for a web page when chosen from the browser’s bookmarks list. It’s true that this method allows a web app to be stored entirely on the user’s device, but a web page generated in this fashion has some additional limitations over regular web pages. For example, a bookmarklet app cannot use browser cookies because of security restrictions in the browser.

Mobile Safari does support the HTML5 offline application cache. This mechanism allows web app publishers to code their pages (and configure their web servers) in a way that allows the browser to store a copy of a web page and additional resources (e.g., images) on the device. Developers deploying this technique have a variety of limits to attend to, such as a maximum of 25 KB for any resource file, including any images. Of greater concern, however, is that if the user reboots the device (completely powering down the unit), all data in this offline cache can be lost. Native apps, however, survive such system reboots every time.

There is a risk that when you have been designing Internet-based content and software for a long time, you tend to take Internet connectivity for granted—after all, you have always-on broadband at home or work. Additionally, all the buzz about cloud computing makes it sound as though every computer user on the planet has ubiquitous and nearly free access to an Internet that is as reliable as the sun rising tomorrow morning. That is not always the case for all users.