Learning iOS Programming, 3rd Edition

Chapter 1. Why Go Native?

When the iPhone was originally introduced back in 2007, there was no native SDK. Apple claimed that one wasn’t needed and that applications for the device should be built as web applications using JavaScript, CSS, and HTML. This didn’t go down well with the developer community; they wanted direct access to the hardware and integration with Apple’s own applications.

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 “jailbroken” by their users, allowing them to run these unsanctioned third-party applications.

However, the book you hold in your hands isn’t about the open source “hacker” SDK, because in March 2008, less than a year after the release of the first iPhone, Apple publicly changed its mind and released a native SDK to a waiting developer community. Whether this release was in response to the open source community’s efforts, or perhaps because it was just the plan by a notoriously secretive Apple all along, we’ll probably never know.

The Pros and Cons

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 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.

Just to be clear, this isn’t a criticism of HTML, CSS, and JavaScript. The Web’s technology stack is solid and maturing, and the attraction of having a cross-platform code base is going to be immediately obvious to you as a developer. However, to your users, it’s not so obvious. Most of the arguments that are put forth in support of using web technologies, or other non-native frameworks, are from a developer’s perspective. While that doesn’t make them invalid, you should take a serious look at those arguments from a user’s perspective, because none of them really address their main concern: usability.

Consumers won’t buy your application on their platform just because you support other platforms; instead, they want an application that looks like the rest of the applications on their platform, that follows the same interface paradigms as the rest of the applications they’re used to, and that is integrated into their platform.

If you integrate your application into the iOS ecosphere, make use of the possibilities that the hardware offers, and make sure your user interface is optimised for the device, the user experience is going to be much improved. All of this is possible using web technologies, but most of the time it’s actually really hard to write non-native applications that work well across multiple platforms. It’s harder still to make them look native on half a dozen different platforms.

Why Write Native Applications?

The obvious reason to use the native SDK is to do things that you can’t do using web technologies. 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 Safari browser on iOS supports the 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 in HTML 5, so it’s unlikely that you will see the arrival of augmented reality web applications.

Note

If you are coming from a web development background, you may be interested in the cross-platform PhoneGap framework. This framework provides native wrapper classes and allows you to build native applications in HTML/JavaScript on a range of mobile platforms. One of the platforms it targets is the iOS.

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 iOS are actually web applications wrapped inside native applications. Just like the iTunes and App Stores on the Mac desktop, the main panel you see is actually just 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 cleanly.

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 user interface locally, and populating it with data pulled from the Internet.

Network performance will affect the user’s perception of speed; rendering your user interface 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 iOS devices, if you want to delve deeply into game programming on the platform, I recommend Tap, Move, Shake: Turning Your Game Ideas into iPhone & iPad Apps by Todd Moore (O’Reilly).

The Release Cycle

Paul Graham, one of my favorite dispensers of wisdom, argues that the arrival of web-based software has changed not just the user experience, but the developer experience as well:

One of the most important changes in this new world is the way you do releases. In the desktop software business, doing a release is a huge trauma, in which the whole company sweats and strains to push out a single, giant piece of code. Obvious comparisons suggest themselves, both to the process and the resulting product.

— From “The Other Road Ahead” by Paul Graham

He is exactly right. Working in the cloud, you rarely make a software release in the old sense of the word. Despite the benefits, I must admit I actually somewhat miss the “big push” where, usually with a great deal of trepidation, you roll out a new, improved version of a piece of software. However, one problem with writing native applications is that we’ve made a return to the release cycle.

With web-based software you can make incremental releases, fixing bugs when and if they occur. Native applications are far more like desktop software.

I cover the details of how to submit applications to the App Store in Chapter 13. However, you should prepare yourself now for some amount of pain. The review process is notoriously opaque, and it can and does take time. Plus, each of your applications must go through it, not just when you initially submit it to the store, but also for each new version you release. Typically, it can take up to seven days from submitting your application for it to be approved (or rejected) by the review team, although it can take much longer. While some of my applications have sailed through the submission process in only a couple of days, I have had applications in the review process for up to four months before receiving approval.

Note

If you’re interested in how the average review time for iOS and OS X applications changes with time, look at Average App Store Review Times. The site, written by Dave Verwer, a well known iOS developer, tracks the average App Store review times for apps submitted to both the iOS and the Mac App Store using data crowdsourced from developers on Twitter.

Build It and They Will Come

Earlier in the chapter, I argued against web applications because they require an Internet connection; of course, that’s not entirely the whole truth. You can write an offline web application using the Offline Application Cache available in HTML5, although there are obvious limitations to that approach. However, the big advantage of a native application, even with today’s crowded App Store, is exposure. If nobody can find your application, nobody can pay for it, and the Web is a big place.

One big advantage a native application has over a web application is that it’s easier for potential users to find, and much easier to pay for when they find it. That is, if you can get people to pay for web applications at all. People don’t impulse-subscribe to a web service; they impulse-buy from the App Store.

However, don’t assume that if you build it, users will appear. Unless you’re really lucky and your application goes viral, you still need to market your application. The App Store may be a lot smaller than the Web, but it’s still a pretty big place.

Marketing your application is like marketing any product; you need to make use of the tools available and your contacts to get news of your software to your target market. Apple provides promotional codes for your application (although at the time of this writing, these work only in the US App Store) that will give free downloads of your applications. Many developers reach out to high-profile blogs or the many application catalog sites and offer them review copies in hopes that they will publicize the application. If it’s well designed and useful, they might well be interested in reviewing it.

Produce a screencast showing how your application works and how to use it. Also, applications with good support resources (such as forums and trouble-ticket systems) sell more copies. Applications with good design stand out in the store and sell more copies.

Good design often means that you do things “the Apple way.” Integrate your application well with the other applications on the phone. Don’t reinvent the wheel—use the standard widgets and interface elements familiar to iOS users.