As I discussed in Chapter 1, "Introducing Safari/WebKit Development for iPhone 3.0," the world of iPhone applications has two breeds: native apps that are installed and run on the device, and Web apps that run inside of Safari on iPhone. The focus of this book has been on creating Web-based applications. But suppose you develop a Web app and find that, as time goes on, needs change and you must consider a native solution instead. Or suppose your user base is clamoring for a native version of your app, but you have no clue how to go about developing one.
If your experience has been primarily with Web technologies, don't simply dismiss the idea of porting to a native solution because you do Web. You may find that moving your app to the native iPhone platform is not only the best move for your application and user base, but the best move for you professionally — learning a new skill set while you port.
In this final chapter, I'll introduce you to native iPhone application development. As part of that, you'll explore the advantages and disadvantages of both breeds as well as the iPhone 3.0 SDK. I'll also talk about PhoneGap, which is a unique open source solution for wrapping your Web-based app inside a native shell.
Let's face it: The iPhone is not a level playing field for native and Web apps. Unfortunately for Web developers, it is biased toward native solutions. The iPhone App Store only carries native apps, not Web-based ones. Apple does not have a way to allow users to "install" a Web app on their home screen automatically; instead, it requires the user to go through the manual step of adding just as you would a browser bookmark. What's more, until recently, Web apps could not fully customize the Safari chrome (or UI shell). Therefore, you might conclude that the native route is always the way to go. Not so. As you've seen throughout this book, in spite of the aforementioned handicaps, you can create compelling applications inside of Safari on iPhone in which you can provide a user experience every bit as solid as a native app.
Web apps have several distinct advantages over native apps:
Leverage existing know-how and expertise: Perhaps the most personal and compelling advantage for Web developers is the fact that Web apps allow you to create iPhone solutions using your existing skill set and expertise. Instead of dealing with a learning curve, all you need to do is augment your existing knowledge base to deal with unique aspects of iPhone as a client.
Leverage existing technology: A Web solution enables you to directly leverage existing Web-based solutions and simply develop a presentation layer that works well and intuitively as an iPhone app.
Lower learning curve: Native applications are written in Objective-C, which is an object-oriented version of C. It is the ubiquitous programming language of Mac OS X development and is naturally extended to the iPhone. If you have never worked with a lower-level language like C or C++ before, it can be quite a jolt to the system. You can feel like you've stepped backward and have to deal with all sorts of issues that you simply don't think about when using a language such as JavaScript. There is no garbage collection, so you have to manage memory within your application; everything you create, you have to dispose of. You also have to concern yourself with challenging programming concepts like pointers and threads. What's more, although the iPhone SDK tools may look visual and advanced, the Objective-C code can look quite arcane. The code is nonlinear and is based on delegates, which are called only when the OS is ready. As a result, it's difficult at first to figure out the logical order and progression of an application.
As a result, Web application development has a distinct advantage over native application development for existing web developers or for those with no formal programming background at all. Web technologies, such as JavaScript, Ajax, CSS, and HTML, have a much lower learning curve than Objective C does. You don't need to worry about such low-level issues as memory management, pointers, and threads. Instead, you can let Safari deal with those issues while you focus on your solution.
Instant distribution without bottlenecks: If you keep up with tech news, you probably know already that one of the major handicaps that native apps have is the App Store bottleneck. It can take several weeks for Apple to approve a native iPhone app. What's more, this approval process is not just a one-time thing. Even if you are releasing a minor bug fix version, you can often experience the same processing and approval delays. In sharp contrast, because an iPhone Web app is a server-based solution, you can deploy an update and redistribute your app at a moment's notice. There are no barriers or bottlenecks to doing so.
Easy to maintain and update: Not only do you not have distribution bottlenecks with a Web app, but a Web app is much easier to maintain and update because you control the program on the backend.
Near-native capabilities: I argued before that the iPhone seems to have a bias toward native solutions over Web-based ones. At the same time, although the technology gap between the two was large during the initial release of the iPhone, this gap has largely disappeared. iPhone OS 3.0 gives Web developers access to the key touch events, the ability to fully customize the Safari chrome, and a way to get onto the home screen (even if the way in which it gets there is not optimal). What's more, with HTML 5's local storage capabilities, Web apps no longer depend on a live connection with the Internet. Therefore, although Web apps may still not be fully on the same playing field as native apps, the gap continues to shrink.
Google Latitude, shown in Figure 16-1, is one of the best examples of a popular iPhone app that is Web based rather than native.
Given the incredible popularity of the App Store, it is quite clear that a native app architecture has some advantages. Here are several of them:
Compelling user experience: When you interact with a well-made native iPhone app, there is an undeniable "look and feel" factor. It has a snappiness and robustness that make it a joy to use (see Figure 16-2). You could sum it up with the following statement: Web seeks to emulate, but native allows you to innovate.
Programming power: Although the innovations in Ajax, CSS animations, and HTML 5 give Web developers more and more power to create powerful applications, Web technologies will never provide the raw programming power needed for games and other processor-intensive programs (see Figure 16-3).
Speed: Safari interprets the client-side source code base of Web apps at run time before their instructions are processed. In contrast, native iPhone apps are compiled. As a result, native apps always execute faster than Web apps. What's more, unless the native app accesses Web services, some or all of its data and resources are stored on the iPhone. In contrast, Web apps always have to deal with bandwidth and latency issues.
Access to iPhone hardware and software services: Although Apple has made many of the services available to Web app developers, native apps get even more, such as the camera, compass, and photo gallery.
No Internet dependency: Although Web developers can take advantage of HTML 5's offline cache to operate when the Internet is not available, Web apps tend to have an underlying dependency on the Internet. In contrast, because native apps are installed on the device, there is no inherent dependency on the Internet.
Income generation: Apart from intra-app advertisements, there are no successful models for making money from iPhone Web apps. On the other hand, the App Store (see Figure 16-4) has emerged as the poster child of success stories for application developers. Therefore, if you are planning on trying to earn income from your work, a native app may be your only viable option.
One of the great advantages of iPhone Web apps is the ability to get something up and running. And, then, once you have an initial version deployed, you are free to decide where to invest your time and energies for future releases. Do you continue to develop a Web-based solution? Or do you decide to port your Web app to the native platform?
Here are some issues to keep in mind during your Web vs. native decision-making process:
Nature of app: Does the nature of the app lend itself to a native or Web model? Often, the key factor is whether the problem domain the app is in more or less makes the decision for you. If you are trying to create a game, the answer is simple: native gives you the graphics processing power you need. If you are creating a camera add-on, you'd go native to get the integration capabilities. On the other hand, if your app depends on Web services, a Web solution may be appropriate.
The choice is not always obvious. Google Latitude (see Figure 16-1) and the Amazon app (see Figure 16-5) are two apps that are completely reliant on Web services, yet choose opposite paths.
Existing technology: Do you have existing Web-based technology that you want to continue to utilize? If so, you could access it in an API fashion using a native app (such as the Amazon app). Or you may decide that a Web app solution gives a sound user experience all the while making the most of your existing investment (see Figure 16-6).
Timing: How important is time to market? A native app has a considerable learning curve for new developers, has a longer development cycle to develop comparable functionality, and is subject to the often-lengthy App Store review process.
User feedback: What are your users saying about their experience with your app? Do you get complaints about speed? Do you have iPod touch users who would like to use your app all the time, not just when they have Wifi access? Or do you have users frustrated that updates are too few and far between?
Native iPhone app development is centered on the iPhone SDK. The SDK contains all the tools and code you need to create native iPhone apps. It's available for Mac OS X only, so if you are a Windows developer, you're out of luck.
The basic process for developing and deploying an iPhone app is as follows:
Create a developer account at
http://developer.apple.com/iphone.Download the free iPhone SDK (Mac only).
Install the iPhone SDK, which includes the Xcode development tool.
Develop your app using Xcode and its suite of SDK tools.
If you want to actually install your app on an iPhone device, you need to make a one-time purchase of an iPhone Developer Program certificate ($99).
Once approved, you can submit an application to the App Store (or more specifically the online Developer Program Portal).
The iPhone SDK consists of a suite of tools and other resources called Xcode that you use to create a native Objective C app. Here is an overview of the pieces of the toolkit that you'll work with first:
Xcode IDE is your primary tool for writing and editing source code and managing your project (see Figure 16-7).
Interface Builder is a visual tool used to design your application's UI. The UI you create is then loaded by the app as resources (see Figure 16-8). You can create your own design from scratch or use UIKit templates to give you a head start.
iPhone Simulator (which I discuss in Chapter 15, "Debug and Deploy") is used to preview and debug your apps on your desktop machine. It looks like the iPhone, except on your desktop, that is (see Figure 16-9).
SQLite comes as part of the SDK. If you need a database for your app, you can utilize the SQLite database management library.
PhoneGap (http://phonegap.com) is an open source development tool that offers an interesting hybrid model to consider. You can build your application using familiar Web technologies but wrap it in a native iPhone shell. In other words, your Web app is packaged with a customized native WebKit browser that can be added to the App Store, alongside other native apps. Its developers express that the purpose of PhoneGap is "to solve device integration by Web-enabling devices' native functionality with open standards." What's more, PhoneGap enables you to do the same things for other mobile platforms, including Android and Blackberry.
PhoneGap enables you to create a native shell for your Web app using PhoneGap along with the iPhone SDK. After downloading the latest source from the PhoneGap Web site, you can start off by opening the PhoneGap.xcodeproj file, inside the iphone subdirectory (see Figure 16-10). The project is displayed in the Xcode window (see Figure 16-11).
In the iphone/www subdirectory, you'll find an index.html file (see Figure 16-12). The app displays this page when it is run. You can replace the existing file with your own Web app starting page, including necessary resources and other HTML pages in the www folder.
When you run the app in the simulator, the PhoneGap project provides a shell to the Web page you provided (see Figure 16-13).
You can customize the PhoneGap shell and undertake tasks before deploying your app, but this simple example provides a snapshot of how easy it can be to deploy a native app while utilizing your existing Web technology.
You can download the latest PhoneGap source at http://github.com/sintaxi/phonegap/.
In this final chapter, you were introduced to the iPhone SDK and the world of native application development. I compared and contrasted the advantages and disadvantages of Web apps and native apps. In the end, whether you should consider migrating a Web app to a native app is a personal or team decision, based on a variety of factors including programming experience and know-how, desired user experience, time to market, and commercial aspirations.
Then, after a survey of the key tools of the iPhone SDK, the chapter finished with a look at how you could distribute your Web app in a native shell using PhoneGap.