Introducing the iPhone SDK (part 1) - Understanding Model Differences & Platform Limitations

Understanding Model Differences

When it comes to application development, many iPhone apps never have to consider the platform on which they’re being run. Most programs rely only on the display and touch input. They can be safely deployed to all the current iPhone-family devices; they require no special programming or concern about which platform they are running on.

There are, however, real platform differences. These differences are both significant and notable. They play a role in deciding how you tell App Store to sell your software and how you design the software in the first place. Should you deploy your software only to the iPhone? To the iPhone and the second generation and later iPod touch? Or should your application be targeted to every platform? Here are some issues to consider:

Camera

Each iPhone ships with a camera; iPod touches do not. These cameras are useful. You can task the camera to take shots and then send them to Flickr or Twitter. You can use the camera to grab images for direct manipulation, and so forth. The iPhone SDK provides a built-in image picker controller that offers camera access to your users, but only on camera-ready platforms. Video services are limited to the 3G S model and later.

When building camera-ready applications, know that you cannot deploy them to iPods. Camera services are limited to the iPhone family. The first and second generation iPhone’s built-in 2 megapixel camera will never win awards. The third generation camera is much improved, offering autofocus, macro photography, video recording, and better low-light sensitivity.

Speakers and Microphones

First generation iPod touches lack the built-in speaker found on the iPhone and the second generation iPod touch. Although the 1G touch is perfectly capable of powering third-party speakers through its bottom connector port, Apple considers those to be unauthorized accessories and their use is rare.

Don’t assume that end users will wear headphones when using applications. When designing for the first generation iPod, carefully consider the role of audio cues. If they are critical to the program, you may want to either recommend headphone use or consider skipping the 1G iPod as a distribution platform.

The second generation iPod touch supports external headset microphones. The first generation does not. If you do plan to deploy a recording application, make sure you specify clearly that the iPod will require extra equipment to use those features.

The third generation iPhone 3G S provides a number of accessibility features including voice control. It’s unclear at the time of writing whether voice control APIs will be opened to iPhone developers.

Telephony

It may seem an overly obvious point to make, but the iPhone’s telephony system, which handles both phone calls and SMS messaging, can and will interrupt applications when the unit receives an incoming telephone call. Sure, users can quit out of apps whenever they want on both iPhone and iPod platforms, but only the iPhone has to deal with the kind of exit that’s forced by the system and not a choice by the user.

Consider how the different kinds of interruptions might affect your application. It’s important to keep all kinds of possible exits in mind when designing software. Be aware that the choice to leave your app may not always come from the user, especially on the iPhone.

Another fall-out of telephony operations is that more stuff ends up running in the background on iPhones than on iPod touches. This means that as a rule, the amount of free memory is likely to be reduced on the iPhone compared to the touch. This is one reason that making the iPhone your primary development device over the iPod touch may be a smart move. Working within the iPhone’s greater limitations may produce software that operates robustly on both the iPhone and touch platforms.

Core Location Differences

Core location depends on three different approaches, each of which may or not be available on a given platform. These approaches are limited by each device’s onboard capabilities. Wi-Fi location, which scans for local routers and uses their MAC addresses to search a central position database, is freely available on all iPhone and iPod touch platforms.

Cell location, however, depends on an antenna that is available only on the iPhone. This technology triangulates from local cell towers, whose positions are well defined from their installations by telephone companies. The final and most accurate strategy, GPS location, is available only to second generation iPhones and newer. GPS was not built into the first generation iPhone and is not currently available to any iPod touch units.

The third generation iPhone 3G S introduces a built-in compass (via a magnetometer) along with the Core Location APIs to support it.

Vibration Support and Proximity

Vibration, which adds tactile feedback to many games, is limited to iPhones. iPod touches do not offer vibration support. Nor do they include the proximity sensor that blanks the screen when holding the iPhone against your ear during calls. Until SDK 3.0, using the proximity sensor in your applications has been theoretically off limits although it was used in a number of App Store products, most notably in the mobile Google application (http://itunes.com/apps/googlemobileapp). Starting with version 3.0, the UIDevice class offers direct access to the current state of the proximity sensor.

Processor Speeds

The second generation iPod touch features a 532MHz processor. The touch offered the highest power processing in the iPhone line until supplanted by the iPhone 3G S, running at a reported 600MHz. Make sure to test your software on older, slower units as well as on the newer ones. Application response time can and will be affected by the device on which it’s being run.

If your application isn’t responsive enough on the older platforms, consider working up your efficiency. There is no option in App Store at this time that lets you omit the first generation iPhone from your distribution base.

OpenGL ES

OpenGL ES offers a royalty-free cross-platform API for 2D and 3D graphics development. It is provided as part of the iPhone SDK. Not all iPhone models provide the same OpenGL ES support. The iPhone 3G S and newer models support both OpenGL ES 2.0 and 1.1. Earlier models including the 2G and 3G iPhone, and the first and second generation iPod touch, run only OpenGL ES 1.1. The 2.0 API provides better shading and text support, providing higher quality graphics.

To target all iPhones, develop your graphics using only 1.1. Applications leveraging the 2.0 API are limited to the iPhone 3G S and other future models.

Platform Limitations

When talking about mobile platforms like the iPhone, several concerns always arise, such as storage, interaction limits, and battery life. Mobile platforms can’t offer the same disk space their desktop counterparts do. Along with storage limits, constrained interfaces and energy consumption place very real restrictions on what you as a developer can accomplish.

With the iPhone, you can’t design for a big screen, for a mouse, for a physical keyboard (yet), or even for a physical always-on A/C power supply. Instead, platform realities must shape and guide your development. Fortunately, Apple has done an incredible job designing a new platform that somehow leverages flexibility from its set of limited storage, limited interaction controls, and limited battery life.

Storage Limits

The iPhone hosts a powerful yet compact OS X installation. Although the entire iPhone OS fills no more than a few hundred megabytes of space—almost nothing in today’s culture of large operating system installations—it provides an extensive framework library. These frameworks of precompiled routines enable iPhone users to run a diverse range of compact applications, from telephony to audio playback, from e-mail to Web browsing. The iPhone provides just enough programming support to create flexible interfaces while keeping system files trimmed down to fit neatly within tight storage limits.

Data Access Limits

Every iPhone application is sandboxed. That is, it lives in a strictly regulated portion of the file system. Your program cannot directly access other applications, certain data, and certain folders. Among other things, these limitations minimize or prevent your interaction with the iTunes library and the calendar. Your program can, however, access any data that is freely available over the Internet when the iPhone is connected to a network, and, new to 3.0, you can access a shared systemwide pasteboard.

Memory Limits

On the iPhone, memory management is critical. The iPhone does not support disk-swap-based virtual memory. When you run out of memory, the iPhone shuts down your application—as Apple puts it, random crashes are probably not the user experience you were hoping for. With no swap file, you must carefully manage your memory demands and be prepared for the iPhone OS to terminate your application if it starts swallowing too much memory at once. You must also take care concerning what resources your applications use. Too many high-resolution images or audio files can bring your application into the autoterminate zone.

Apple system engineers suggest that applications need to stay within 20MB of RAM. Here is the rough rule of thumb that circulates in developer circles. At about 20MB of use, the iPhone begins to issue memory warnings. At around 30MB, the iPhone OS shuts the application down.

Interaction Limits

Losing physical input devices and working with a tiny screen doesn’t mean you lose interaction flexibility. With multitouch, you can build user interfaces that defy the rules. The iPhone’s touch technology means you can design applications complete with text input and pointer control using a virtual screen that’s much larger than the actual physical reality held in your palm.

A smart autocorrecting onscreen keyboard, built-in microphone (for all units except on the iPod touch), and an accelerometer that detects orientation provide just a few of the key technologies that separate the iPhone from the rest of the mobile computing pack. What this means, however, is that you need to cut back on things such as text input and scrolling windows.

Focus your design efforts on easy-to-tap interfaces rather than on desktop-like mimicry. Remember, you can use just one window at a time—unlike desktop applications that are free to use multiwindow displays.

Energy Limits

For mobile platforms, you cannot ignore energy limitations. That being said, Apple’s SDK features help to design your applications to limit CPU use and avoid running down the battery. A smart use of technology (for example, properly suspending themselves between uses) lets your applications play nicely on the iPhone and keeps your software from burning holes in users’ pockets (sometimes almost literally). Some programs, when left running, produce such high levels of waste heat that the phone becomes hot to the touch and the battery quickly runs down. The Camera application is one notable example.

Application Limits

Apple has instituted a strong “one-application-at-a-time” policy. That means as a third-party developer you cannot develop applications that run in the background like Apple’s Mail and Phone utilities. Each time your program runs, it must clean up and metaphorically get out of Dodge before passing control on to the next application selected by the user. You can’t leave a daemon running that checks for new messages or that sends out periodic updates.

On the other hand, Apple does support push data from Web services as of firmware 3.0. Registered services can push badge numbers and messages to users, letting them know that data is waiting on those servers.

User Behavior Limits

Although it’s not a physical device-based limitation, get used to the fact that iPhone users approach phone-based applications sporadically. They enter a program, use it quickly, and then leave just as quickly. The handheld nature of the device means you must design your applications around short interaction periods and prepare for your application to be cut off as a user receives a phone call or sticks the phone back into a pocket. Save your application state between sessions and relaunch quickly to approximate the same task your user was performing the last time the program was run. This can demand diligence on the part of the programmer but is worth the time investment due to the payoff in user satisfaction.