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 assist functionality 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 asked whether 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."
Next: Approval and Payment