Developing iPhone Apps: What You Need to Know

by Gary Hayenga

At the MacWorld Expo in January 2008, Apple CEO Steve Jobs announced a greatly anticipated event: at last Apple was going to allow third-party developers to write native iPhone applications!
When Apple started shipping its hot new smart phone in July 2007, the only applications that were allowed to run on it were Apple’s own. Oh, there was the claim that it could run Web 2.0 applications—but these were just regular AJAX-enabled server side applications that would run in any Web browser, with the same limitations. Hardly things that could exploit the power and flexibility of an almost complete desktop operating system—a slightly modified version of the Mac OS X desktop operating system—running on a handheld device.

In late March of 2008 the first beta version of the native iPhone SDK was released, complete with a simulator for running the applications on the Mac. Apple began accepting applications for a limited number of beta developer licenses. When the App Store opened on July 11th (www.apple.com/iphone/appstore), Apple began approving applications for all developers, as long as they filled out their paperwork correctly and could be verified. Applications for licenses for a business, rather than an individual, continue to receive much more scrutiny and thus seem to take longer. This is mainly true for new businesses whose bona fides cannot easily be verified.

The Development Environment

The iPhone SDK development tools require an Intel based Macintosh running Mac OS X 10.5 Leopard. The tools use Apple’s XCode IDE and (optionally) the Interface Builder GUI design tool. The Cocoa Touch frameworks—and thus iPhone applications—require the code to be written in the Objective-C language. Objective-C is a strict superset of C, which means that it can run C and C++ code, which is very handy. But any interaction with the iPhone OS APIs has to be done using the Objective-C syntax which looks very different and takes quite a bit of imagination to wrap your mind around for most people—even if they’re familiar with Object Oriented programming and design.

For instance here are two lines of code that declare and intialize two strings:

NSString *currentFolder = [[NSString alloc] initWithString:[[NSUserDefaults standardUserDefaults] objectForKey:kCURRENT_BOOKMARK_FOLDER]];
NSString *currentNotesFolder = [self fixSqlQuotes:[[NSString alloc] initWithString:[[NSUserDefaults standardUserDefaults] stringForKey:kCURRENT_NOTES_FOLDER]]];

Notice the multiple sets of nested brackets. Each bracket contains a “message” being sent to a “receiver” object. The items after the colons are parameters that may themselves be values returned by messages sent to other objects that return a value or another object reference. In this case these are creating string objects that are having memory allocated for them, and then their value is being initialized to the string contained in the standardDefaults dictionary with the key equal to the given string constant.

Allowed App Content

Many stories about Apple’s screening process for iPhone apps have been told in the press and on the Web, some true and some not so true. Apple’s basic reasoning is to enhance their users’ experience and confidence by making sure that third party applications meet their guidelines for dependable user experience. Additionally all applications must meet certain general criteria, some designed for security, some for Apple’s brand image, and some for contractual limitations that Apple has with other parties.

Examples of restrictions include: no pornography, nothing that drains the battery excessively, nothing that uses excessive bandwidth (on the cellular network, thus there are certain applications that are WiFi only), and several others.

Most restrictions are designed to keep the user experience pleasant and Apple’s iPhone brand squeaky clean. It’s an evolving standard. Case in point: early in the process the App Store rejected applications that made annoying bodily noises. If you have any knowledge about the recent top 10 entertainment apps you know that policy has changed.

But other restrictions have been a product of Apple’s concern about competition. For instance, Apple wasn’t sure about how to handle Web browser submissions that would compete with its own Mobile Safari browser. Recently the decision was made to approve third party WebKit based browsers.

The remaining restrictions are more technical.

  1. For security purposes—to prevent malicious or inept programmers from illicitly accessing or modifying things they shouldn’t.
  2. No third party applications are permitted to run in the background—although Apple’s can and do—otherwise a non-technical user may end up with a bunch of apps running in the background eating up CPU cycles, making everything sluggish and draining the battery rapidly. Apple doesn’t want users unable to make phone calls because their batteries mysteriously only last an hour.
  3. Third party applications are also confined to their own internal sandbox. Files and settings for one application cannot be accessed or changed by any other, except for specific Apple APIs, which provide the ability to access the central photo database and address book contents.

App Review and Approval

To prevent non-approved applications—which may contain malicious content, or be ineptly programmed, or (most important to developers) be pirated—from being installed on the iPhone, Apple requires that each application be code signed. Using Apple’s online tools, a registered developer must generate a distribution provisioning file from his or her account. The provisioning files must then be copied into the XCode project and compiled into the finished app binary. This makes all apps traceable back to their originators. Additionally, it prevents the app from running if any changes have been made to it after if was compiled.

After the app is compiled with the appropriate code signing provisioning files, it gets uploaded to the App Store along with screenshots, icons and text descriptions of the app for display in the App Store. The app is then put into the review process. This may take anywhere from two days to six weeks, depending on the complexity of the application and how many applications are currently in the queue for review. Unfortunately, and maddeningly, Apple will not tell developers what that wait time might be, or even if they will lose their place in line if they find and fix a bug and then submit a new binary. Thus some developers have had an app rejected for a simple bug within two days of submission, fixed the bug and resubmitted the new binary within the day, and then waited six more weeks for a fairly simple application to be approved for sale.

As Apple becomes more comfortable dealing with the security of the phone and third party applications, most of the limitations will probably relax. The long approval process, however, may well continue as there has been no evidence that it is hindering third party development. With 17 million iPhones and even more iPod Touches already sold, 22,000 applications available for download from the App Store and over a billion apps already downloaded, Apple doesn’t really have any cause for concern.

info@stoutsystems.com
877.663.0877
© Copyright 1995-2021 - STOUT SYSTEMS DEVELOPMENT INC. - All Rights Reserved
envelopephone-handsetlaptop linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram