Learning the iOS 4 SDK for JavaScript Programmers

What You Lose

By and large, the full iOS SDK feature set offers your app designs far more flexibility and the ability to recreate the full range of user interface features you see on Apple’s own apps and apps developed by third parties. But there are costs—in monetary and toil currencies—to obtain those native app powers.

Except for apps designed for in-house corporate use, native apps that run on nonmodified devices—i.e., iPhones and iPads that have not been jailbroken (hacked to allow unapproved third-party apps)—must be distributed via the iTunes App Store. This is both a blessing and, for some, a curse for several reasons.

About Jailbreaking

When the first-generation iPhone landed in developers’ hands in 2007, quite a few programmers were put off by the lack of a publicly available development environment for applications. Apple granted itself the power to build native apps included with the phone, but the developer community was shunted to the web app world—with a Mobile Safari version boasting far fewer app-friendly features than today’s HTML5-empowered model. Some adventurous programmers, however, found ways to gain access to the same interior programming functionality that Apple’s engineers had and opened up native programming to third parties. Having pierced through Apple’s restrictions, they called the technique jailbreaking. To run one of these independent apps, an iPhone user had to “jailbreak” the device using a software-run process that grew easier and easier over time as jailbreaking tools improved.

Several months after the initial iPhone debut—and perhaps pushed by the encroaching jailbreak programming efforts—Apple released the iPhone SDK to allow third parties to write native apps, but only with publicly documented routines. That restriction still rankles some developers, so jailbreaking is still alive today, even as Apple continually opens more internal routines to all developers. Jailbroken devices reportedly account for as much as 10% of the world’s iPhone and iPad population (but a higher percentage of active tech bloggers, who make jailbreaking seem more prevalent than it is). Although jailbroken devices can still download apps from Apple’s App Store, a separate store, called Cydia Store, offers apps designed for jailbroken iPhones and iPads.

Some programmers believe it is almost an obligation to jailbreak their devices, lest they appear captive to the will of Steve Jobs. I personally prefer not to jailbreak my devices, for practical, rather than ideological, reasons: I want to know that when I test my App Store apps, the devices are working like the ones owned by 90% or more of my potential customer base. The ultimate choice, however, is yours.

Distribution

On the one hand, since the App Store is a single point of distribution, all users of unhacked iPhone, iPod touch, and iPad devices go to the App Store in search of apps that will help them scratch an itch. While you may have to choose your app’s description keywords carefully to help potential users search for your product, at least you don’t have to play search engine optimization games to get your app high in search engine results.

On the other hand, the App Store becomes the one-and-only gatekeeper between your app and the consuming public. You must submit your finished app to the App Store for approval before it appears in the store. Approval times can vary widely, often without explanation. Sometimes it’s a matter of only a couple of days; other times it can take weeks. The same is true for updates to existing apps. If you need to issue an update to fix a bug, the approval time can be just as long—and, inexplicably, sometimes longer—to get that maintenance release out to the world. You can apply for an emergency update to help hasten the approval, but if you abuse that privilege, you risk upsetting the gatekeepers.

App Updates

Speaking of updates, the web app scenario is far superior to the App Store native app. You instantly deploy an update to the server that hosts the web app whenever you want, as often as you want. This encourages web app developers to issue frequent incremental updates rather than storing up fixes to submit to the App Store in less-frequent batches.

If your app updates are more content-oriented, you can still pass along those updates to a native app in a couple of ways. I described earlier how I use HTML to supply my native apps with news updates. Similarly, updated material can be supplied in other formats (e.g., property list XML files), which a native app can read whenever it launches. Users can save newly acquired material to the device so that it is available to the app even if the device is not connected to the Internet the next time the app launches. Implementing this approach to updating an app takes a bit of advance planning, so it is well worth exploring the possibility early in the design phases of any iOS app.

Apple iOS Developer Program

A prerequisite to submitting a native app to the App Store is an annual paid membership to the iOS (formerly iPhone) Developer Program. The current fee is $99.00 per year. Membership lets you obtain the necessary digital certificates that permit developers to load native apps onto test devices and to upload finished apps to the App Store for approval. You also have access to beta versions of the next version of iOS SDK and iOS software (all under nondisclosure agreements, so you can’t blab about them).

In addition to paying the developer program fee, you must also complete a distribution contract with Apple. For paid applications, the contract process also requires that you establish banking relations with Apple. As with app approvals, the time required to complete the contract varies depending how busy Apple is. It’s not something to leave to the last minute, because it can take several weeks to complete, even longer for developers outside of the United States. Once you pay for the iOS Developer Program, you should begin the contract process, even as you work on your first native app.

Content

As the gatekeeper to “shelf space” on the App Store, Apple’s approval process also imposes restrictions on the content of native apps. Your developer agreements spell out the fundamental guidelines, but Apple inspects each app for compliance on a case-by-case basis.

Such is not the case for web apps. You can serve up whatever you want (within the confines of your own local laws, of course) because the web app is hosted on your server and the device’s owner can freely decide to visit your server or skip it.

If you are already aware that web apps—indeed any content designed to be played through the Mobile Safari browser—cannot avail themselves of Flash or Java, you should also be aware that native apps don’t get you any further with respect to those two software platforms. As of this writing, iOS does not natively support either runtime environment.

Authoring Platform Choices

You can write HTML, CSS, and JavaScript code with a text editor on any operating system platform of virtually any generation. Plain text editing doesn’t even require a graphical user interface, which is why you can find plenty of Unix programmers composing web code in command-line interface editors, such as Emacs and vi (or variants thereof). The key to this flexibility is that conversion to machine code occurs in the web browser. Such is not the case for writing native apps.

Developing native iOS apps requires Apple’s integrated development environment (IDE) called Xcode (pronounced EKS-code). Even though Windows users can sync their iOS devices to their PCs via iTunes for Windows, the Xcode IDE is available only for Macintosh computers.