What you need to know before writing apps for either platform — or for both

By Jonathan Hassell

Note: This story is excerpted from Computerworld.

Computerworld – Smartphones and their apps are the new way of the world, and developers are lured by their increasing popularity. But with two major platforms — Apple‘s recently upgraded and renamed iOS 4 and Google‘s Android — competing with one another, how does a developer choose between them?

In fact, how would developers interested in maximum exposure for their apps fare by targeting either — or both — platforms? What roadblocks are there, and how does a developer get around them? I’ll take a look at these questions and relay advice from experienced developers on both platforms.

Programming languages

For developers who have one app in mind and envision their code running on multiple mobile platforms, the going is rough in today’s world.

Android apps are written in the Java programming language. Many developers have made careers in enterprises by becoming very proficient in Java, so developing for the Android platform is a natural fit for those folks.

On the other hand, applications that run natively on the iPhone operating system are written in Apple’s Objective-C, a dialect of the more common C language that has elements of Smalltalk. (Technically speaking, Objective-C is a small, strict superset language on top of C, so any C program will compile with an Objective-C compiler, and a developer can include C code within an Objective-C class.) Developers who have spent their careers working with C and C++ probably won’t find Objective-C to be a difficult language to pick up, although there may be speed bumps along the way.

"There is no obvious way to write one set of code that targets both platforms," says Matthew Baxter-Reynolds, director of AMX Software Ltd., a software development firm in England, and author of the upcoming book Multimobile Development: Building Applications for Any Smartphone. "You cannot run Java on iPhone, and you cannot run Objective-C on Android."

Writing for multiple platforms

That was the story for a while — you had to develop your apps in the native language for each device. Over the past year or so, however, new tool kits and development platforms have emerged in the marketplace to make it possible for programmers create iPhone applications without having to study Objective-C.

Tool kits such as Rhomobile’s Rhodes, Nitobi’s PhoneGap, Appcelerator’s Titanium and Ansca’s Corona make it relatively simple to create apps that will run on some combination of the iPhone, BlackBerry, Windows Mobile, Symbian and Android platforms.

However, these emulators and runtime layers are new and not full-featured. While simple applications accessing the Web and bringing information back to the phone are appropriate for these types of frameworks, mobile apps relying on intense calculations and heavy database access — which includes some custom-written line-of-business applications — are not good candidates, because running a compatibility framework exacts an overhead penalty on a limited-power mobile processor that most users find unacceptable.

In addition, there are currently no good solutions for providing cross-platform support for a graphically intensive application, like a game or a video editor.

In other words, there’s still nothing to change the fact that you’re working with two different platforms and two different native languages. For now, the solution is to rewrite the application into the desired target platform’s native language.

Closed vs. open systems

Android is well liked by some developers because it provides an open development platform, one on which rich applications with potentially game-changing feature sets can be deployed. Developers can leverage the Android device hardware, create location-aware apps by accessing GPS and other sensory information on the device, set alarms to remind users of events, include notifications and other information on the status bar of the device, and more.

In contrast, iPhones have difficulty displaying multiple notifications, since applications are restricted to pop-up messages that are shown only one at a time. Additionally, developers on Android, at least in the United States, can leverage various carrier features across the spectrum of Android devices, whereas iPhone devices are limited to the network features that AT&T allows.

With the functionality of the Android 2.2 software development kit (SDK), a developer can build apps that use either the touch screen or the device keyboard. This is an important point, since Android developers have to accommodate a larger set of devices, all with different hardware configurations.

In a recent TechRepublic article, Justin James reported that Jason Chen, an Android developer advocate at Google, said the two biggest hurdles for first-time Android developers to overcome are understanding and handling the multitasking on the Android platform and dealing gracefully with app interruptions, like receiving an incoming SMS text message or phone call.

On the other hand, developers fare pretty well when writing apps for the iPhone, at least at the outset. Since the iPhone operating system is a closed system, created specifically by Apple for its own devices, developers have a known spectrum of devices to target, with a well-defined scope of capabilities and limitations.

Some developers report that this closed-system model makes for better usability — a trait for which Apple products have traditionally been lauded. With such tight integration of the phone, operating system and third-party apps, users’ defined expectations are met with a minimum of fuss around getting an app on the phone, what it does when it’s on the phone, and what features that app will support.

That’s a good thing from the drawing board perspective, but in some instances — for example, where your software could work better, or at least differently, with a different type of device — it limits the flexibility developers have in creating apps.

Learning resources and testing tools

Getting up to speed is an important part of the development process. Apple makes information for iPhone app developers available in many forms, including multimedia. "Important concepts are explained in videos, which makes grasping concepts easy," says David Green, a software developer at MAKE Technologies Inc. in Vancouver, British Columbia. "However, I did find that videos progressed slowly and I was watching for what seemed like hours to find information that should have taken minutes."

In contrast, Android’s support of open-source applications makes sample apps and other programs easy to learn from. "I also downloaded many open-source Android projects for ideas on architecture and API usage. This is an area where Android has the advantage, [since] with Apple’s previous NDA policy there isn’t much out there in terms of open source for iPhone," says Green.

Of course, the development environment and testing tools comprise a significant part of the overall experience for app creators. Green says that here, Android is the clear winner. "Android development leverages the excellent JDT tools, which are pretty much stock and standard with every Eclipse installation," he says. "I’ve used these tools now for many years and they’re excellent. Everything Java is indexed, the IDE has a rich model of the source code, and refactoring is so seamless that it has changed the way that I work."

On the flip side, Apple’s Xcode integrated development environment (IDE) is not up to par, according to Green. "Xcode is so shockingly bad that I almost don’t know where to start," he says.

Green suggests that at a minimum, Xcode should be improved to include a decent windows/editor management system for ease of use, integrated API documentation to save time, and content assistfunctionality that represents a larger set of coding styles than is available now. "Content assist provided by XCode is often wrong, and almost always suggests a small subset of what’s actually available," says Green.

No Java or Flash allowed?

Lately, much has been made of Apple’s public spat with Adobe over the stability and ultimate usefulness of the latter’s Flash Web technology. Apple has, in the past, similarly cast the Java language in a negative light. In a dictum likely coming directly from the top (Steve Jobs), the company decreed that the iPhone and its various brother and sister technologies will not support Flash or Java. During the recent rollout of iOS 4.0, Jobs was askedwhether this position was likely to change. "No," he said.

In an environment where just a few touches or clicks let you download, install and run an application, all done seamlessly and over the air, one can argue that certain reasonable protections must be employed to shield users from ill-intentioned apps. Still, that limits the flexibility that developers knowledgeable in those rich media platforms have to build applications for the iPhone, particularly when audio, video, animations and so on are core components of an app.

"At the current time, there are some question marks over Apple’s SDK licensing with regards to whether Apple will, on an ongoing basis, allow applications onto the App Store that have been written using intermediate layers or conversion tools," says Baxter-Reynolds.

"The message [Apple is] putting out there at the moment is that iPhone applications have to be natively written for that device and hence developers may struggle to maintain and develop a single set of code that includes iPhone in its set of target platforms," he says. "This is a particular shame because it will be for legal and not for technical reasons."

Approval and payment

The limitations on the iPhone platform haven’t slowed down the popularity of the phone itself, which continues to sell in large quantities, or the success of the iTunes App Store, which has more than 225,000 iPhone, iPod and iPad apps for sale.

Apple also offers an open API for developers who don’t want to submit their apps for review and approval on the App Store. These developers can host the packaged application on their own site and instruct users to visit that location to download and install the code. But clearly, by deploying iPhone applications this way, a developer loses out on the thousands upon thousands of eyeballs that exclusively surf the App Store and part with their money in that venue.

Developers who go the App Store route can sign up for the iPhone Developer Program Standard track, which allows them to receive 70% of sales revenue without paying any distribution costs for the application. To use the iPhone SDK, however, developers must pay an annual fee of $99, after which they receive the required digital certificate signature needed to sell the app on the App Store.

The approval process, which in 2009 was often a weeks-long affair, has been reduced to just a few days, although iPad-specific applications may facelengthier delays right now.

In contrast, the Android Market has no restrictions on the language apps are written in, the functions they perform or any other property of the app. Developers registering for the Android Market pay a one-time $25 fee to register, and 70% of subsequent revenues go to the developer. Developers are also free to publish the same apps in other application markets without facing any restrictions.

Looking toward the future

Ultimately, the arguments for and against the approaches taken by Apple and Google are irrelevant from the perspective of end users, the eventual consumers of the applications that the developers create. What matters to all but the tiniest minority of customers is the overall experience: the marriage of form and function.

Besides, the onward march of technology generally renders obsolete any arguments about tool kits and platforms. As Baxter-Reynolds notes, the upcoming HTML 5 standard will solve much of the Adobe-Apple argument for many developers.

"It’s not all doom and gloom," he says. "Both Android and the iPhone use the fabulous WebKit browser framework, which is pledged to fully support HTML 5 and which will eventually turn into a cross-platform application platform in its own right over the next few years." Developing in HTML 5, additionally, will mean widespread documentation for learning about the language, and freedom to develop HTML code in any environment that a developer wishes.

No matter the outcome, interesting times in the mobile app space lie ahead.

Jonathan Hassell is a frequent Computerworld contributor and is an editor for Apress Media LLC.