You are previewing Learning iPhone Programming.

Learning iPhone Programming

Cover of Learning iPhone Programming by Alasdair Allan Published by O'Reilly Media, Inc.
  1. Learning iPhone Programming
    1. SPECIAL OFFER: Upgrade this ebook with O’Reilly
    2. A Note Regarding Supplemental Files
    3. Preface
      1. Who Should Read This Book?
      2. What Should You Already Know?
      3. What Will You Learn?
      4. What’s in This Book?
      5. Conventions Used in This Book
      6. Using Code Examples
      7. How to Contact Us
      8. Safari® Books Online
      9. Acknowledgments
    4. 1. Why Go Native?
      1. The Pros and Cons
      2. The Release Cycle
      3. Build It and They Will Come
    5. 2. Becoming a Developer
      1. Registering As an iPhone Developer
      2. Enrolling in the iPhone Developer Program
      3. The Apple Developer Connection
      4. Installing the iPhone SDK
      5. Preparing Your iPhone or iPod touch
    6. 3. Your First iPhone App
      1. Objective-C Basics
      2. Creating a Project
    7. 4. Coding in Objective-C
      1. Declaring and Defining Classes
      2. Memory Management
      3. Fundamental iPhone Design Patterns
      4. Conclusion
    8. 5. Table-View-Based Applications
      1. Simplifying the Template Classes
      2. Creating a Table View
      3. Building a Model
      4. Connecting the Controller to the Model
      5. Adding Navigation Controls to the Application
      6. Adding a City View
      7. Edit Mode
    9. 6. Other View Controllers
      1. Utility Applications
      2. Tab Bar Applications
      3. Modal View Controllers
      4. The Image Picker View Controller
    10. 7. Connecting to the Network
      1. Detecting Network Status
      2. Embedding a Web Browser in Your App
      3. Sending Email
      4. Getting Data from the Internet
    11. 8. Handling Data
      1. Data Entry
      2. Parsing XML
      3. Parsing JSON
      4. Regular Expressions
      5. Storing Data
    12. 9. Distributing Your Application
      1. Adding Missing Features
      2. Building and Signing
      3. Submitting to the App Store
      4. Reasons for Rejection
    13. 10. Using Sensors
      1. Hardware Support
      2. Using the Camera
      3. The Core Location Framework
      4. Using the Accelerometer
      5. Using the Digital Compass
      6. Accessing the Proximity Sensor
      7. Using Vibration
    14. 11. Geolocation and Mapping
      1. User Location
      2. Annotating Maps
    15. 12. Integrating Your Application
      1. Application Preferences
      2. Custom URL Schemes
      3. Media Playback
      4. Using the Address Book
    16. 13. Other Native Platforms
      1. PhoneGap
      2. MonoTouch
    17. 14. Going Further
      1. Cocoa and Objective-C
      2. Web Applications
      3. Core Data
      4. Push Notifications
      5. In-App Purchase
      6. Core Animation
      7. Game Kit
      8. Writing Games
      9. Look and Feel
      10. Hardware Accessories
    18. Index
    19. About the Author
    20. Colophon
    21. SPECIAL OFFER: Upgrade this ebook with O’Reilly
O'Reilly logo

Chapter 1. Why Go Native?

When the iPhone was introduced, 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 “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.

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

Why Write Native Applications?

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.


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 iPhone. I talk about PhoneGap, and the other alternative native development platforms for the iPhone, in Chapter 13.

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

The best content for your career. Discover unlimited learning on demand for around $1/day.