Cross-Platform Smartphone Apps Still Difficult

Too many platforms create challenges for smartphone developers

5 min read

Cross-Platform Smartphone Apps Still Difficult

smartphones display

Photos: ProOnGo
Prêt-à-porter: Moving an app from one smartphone platform to another is no easy feat.

Desktop programmers have it easy. Most can still program for 90 percent of the market—Windows—and ignore the Mac OS and all the flavors of Linux. For smartphones, though, things are different. Globally, almost half the 175 million smartphones purchased in 2009 ran the Symbian operating system, and one-fifth were BlackBerries. Most of the rest, about 14 percent, run Windows Mobile, according to a February 2010 report from the IT research analysis firm Gartner. Developers who want to target the large and rapidly growing U.S. market, however, need to consider that the BlackBerry is by far the leading platform there with 42 percent, followed by Apple with 25 percent, while Symbian has less than 5 percent, according to research firm comScore.

Despite the market’s heterogeneity, the nexus of smartphones, wireless broadband, and network-based cloud computing constitutes a perfect storm of opportunity for application developers, luring their attention toward the new platforms. ”There’s a lot of cool things that notebooks or netbooks don’t do so well or can’t do,” says mobile-device-watcher Chris De Herrera. Phones are always on and always connected, pushing e-mail and SMS messages every minute. Smartphones with GPS give turn-by-turn directions, geocode the pictures they take, and search around you for movies, restaurants, and sales at your favorite stores. Smartphones can identify the songs you hear playing and read bar codes and other tags. But all those capabilities can make application development a nightmare.

To be sure, all smartphones have Web browsers. Yet a Web app optimized for one phone may not run well on others—even on other models of the same platform. Processing power, storage, and functionality differ wildly from device to device. You can minimize the differences by processing data back on a server—one of the reasons cloud computing is all the rage. But Dan Turchin, CEO of mobile applications developer Aeroprise, in Mountain View, Calif., warns, ”Mobile browsers aren’t particularly responsive, and when every click needs to go back to the server, you can wait minutes to process a transaction.”

Moreover, browser-based apps can’t tap into a smartphone’s best features. Mobile application vendor ProOnGo, in Chicago, for example, has a BlackBerry expense-tracking app that lets you photograph a receipt with the phone’s camera; the software then reads the text and folds it into your expense report. CEO Phillip Leslie says, ”Our deep integration with smartphone cameras wouldn’t have been possible with just Web app code, nor would some of the image-processing algorithms we use to manipulate the resulting images.”

Still, a native app for the BlackBerry won’t run on an iPhone. If you want to reach even 70 percent of the market, you have to program for more than one environment.

So how much work is writing that second version? The short answer is, a lot. ”If you intend to develop your application in the native environment of a specific device, ’moving’ it to another platform is synonymous with rewriting it,” says Brandon Trebitowski, who heads software development at ELC Mobile, the mobile development arm of ELC Technologies. ”Most mobile devices support different programming languages and have entirely different software development kits.”

”To do multiple versions, there was nothing we could borrow,” reports Ray Bernaz, founder and CEO of Socialibrium, whose products—developed first for the iPhone—help users manage their social networks. ”We had to redo the entire user interface and back end for the BlackBerry. There was no code we could reuse, as the iPhone and BlackBerry use different programming languages”—Objective C/C++ and Java, respectively.

Of course, new implementations can benefit from previous ones. ProOnGo’s Leslie says, ”Our Windows Mobile version took us 12 months to write. When you port it, at least the feature set is nailed down. It took only five months to port to BlackBerry, three to iPhone, and two to Android. The one place where we got some good portability is BlackBerry and Android, because they’re both Java-based.”

So which platform comes first? With nearly half the market, it would seem an easy choice—BlackBerry, which excels in business-related applications, such as time and expense trackers, business-card readers, apps for creating and distributing forms, and De Herrera’s favorite, an HP 12c calculator emulator. ”CPAs love this,” he says, because it can make interest calculations not easily done in Excel.

OS chart

Click on image to enlarge.

Choosing among the other platforms isn’t as easy. The iPhone has the next-largest market, but according to Chris Chodnicki, chief technology officer of Internet marketing and technology firm R2integrated, in Baltimore, ”it is the hardest to program in terms of following Apple’s guidelines and protocols.” He says that the new Windows Mobile 7 ”would be the easiest to program due to its full integration with Microsoft’s Visual Studio integrated development environment.”

Chodnicki cautions that staying current can also be a challenge. ”The platforms change rapidly,” he says, ”and knowing more than two mobile platform languages at an expert level is a herculean exercise.”

Cross-platform development is hardly new, of course, and one classic industry solution—cross-platform tools—has come to smartphones. Among these tools are Appcelerator Titanium, Phonegap, QuickConnect, Rhomobile (pronounced ”roamable” not ”row-mobile”), and WidgitPad. Most use a mix of HTML, CSS, and JavaScript, plus some native ”wrapper” code for accessing hardware features like GPS, a camera, or an accelerometer.

Rhomobile’s software, which can be used to create native apps for iPhone, Windows Mobile, BlackBerry, Symbian, and Android, works so well that Aeroprise, which already has its own development platform, chose it to quickly create smartphone versions of one of its desktop programs. ”We had to support not just BlackBerry but also iPhone, Symbian, Android, and Windows Mobile,” says Aeroprise CEO Turchin, who sits on the Rhomobile board.

Vidal Graupera, an independent software developer, says, ”In Rhomobile, you write using HTML, CSS, JavaScript, and Ruby, which is a very developer-friendly language.” Graupera, who is coauthor of the not-yet-released book Pro Smartphone Cross-Platform Development (Apress), says, ”You can simply ’push the button’ for builds that will run on each environment.” Some tweaking will be needed, but the code will run. ”It might be a few weeks for each additional platform, to seriously tweak and test,” he says.

The testing is particularly important. ”When you use a cross-platform tool kit, you’re creating a new abstraction on top of old ones,” notes Aaron Hillegass, president of Big Nerd Ranch, in Atlanta, and coauthor of iPhone Programming: The Big Nerd Ranch Guide. ”And the ’leaky abstraction’ problem is that with any implementation of an abstraction, the details tend to trickle through.”

That means coding to the lowest common denominator, Hillegass says. For example, most platforms don’t have multitouch events like the iPhone’s pinch-and-spread-fingers way of enlarging a map or an image. ”To do a cross-platform tool kit, the first thing you’d do is say, ’You can’t have multitouch.’ ”

Game development, where a developer wants to be able to control every pixel precisely, loses a lot when programming to the lowest common denominator. Fortunately, business apps do not. ”Most enterprise applications don’t need fine graphic manipulation or interaction with the operating system,” says Michael King, a research director at Gartner. ”The cross-platform tools are quite good.”

Still, there may be deeper benefits to creating native apps with native tools. ”An abstraction layer is taking the industry into a dead end,” says Hillegass. ”To keep innovating, we need a richer environment, not a simpler one.”

This article originally appeared in print as "Writing Small."

This article is for IEEE members only. Join IEEE to access our full archive.

Join the world’s largest professional organization devoted to engineering and applied sciences and get access to all of Spectrum’s articles, podcasts, and special reports. Learn more →

If you're already an IEEE member, please sign in to continue reading.

Membership includes:

  • Get unlimited access to IEEE Spectrum content
  • Follow your favorite topics to create a personalized feed of IEEE Spectrum content
  • Save Spectrum articles to read later
  • Network with other technology professionals
  • Establish a professional profile
  • Create a group to share and collaborate on projects
  • Discover IEEE events and activities
  • Join and participate in discussions