Today's desktop application developers have it easy. We essentially have three OS platforms to choose from: Windows, Mac OS X, and Linux. And even then, there are often ways to make software written for one platform run on the others. Compare that to the early days of PC software development, when developers were forced to choose between Apple, Atari, Commodore, IBM, and other proprietary hardware platforms, with little commonality in between. But even those Bad Old Days pale in comparison to the situation mobile application developers face now.
Even if we limit the choices to smartphone platforms [1] alone, mobile developers must choose between Android, BlackBerry, iPhone, Palm webOS, Symbian, and Windows Mobile -- am I forgetting any? And each is incompatible with the others. In turn, the choice of platform limits the choice of tools and languages that are available, not to mention the range of devices the apps can run on. That's true even for Java -- Java ME was a nice idea, but the world of mobile handsets is still a far cry from "write once, run anywhere."
[ Dig into mobile development with a developer's-eye view of smartphone platforms, [2] and check out InfoWorld'sguide to the best mobile devices. [3] ]
Obviously, reaching the broadest possible audience is a top issue for mobile application developers, but there are other factors to weigh. Here are a few things to think about when choosing a smartphone platform for your mobile apps:
1. Which carriers offer devices for the platform?
BlackBerry devices are ubiquitous across U.S. mobile carriers, but not every model is available on every carrier's network. Similarly, customers who want iPhones have no choice but to sign up with AT&T (assuming they also want support from Apple, warranty coverage, and access to the full feature set of the device). So far T-Mobile is the only carrier offering Android phones in the United States, while the Palm Pre is exclusive to Sprint -- although it's rumored that both phones could show up [4] on AT&T's network [5] before long.
One potential gotcha of carrier exclusivity is data plan pricing. If your app relies heavily on Web access or other Internet data transfer, you'll want to ensure that the carriers offering devices for your chosen platform also offer competitively priced data plans. This is area is heating up; for example, Sprint now offers a low-cost plan for moderate data users [6]. But that's the exception; the pricing at AT&T, which has exclusives on the two most popular devices (the BlackBerry Bold and iPhone [7]) is high, and may increase further [8].
Another issue is the underlying technology behind the network. AT&T and T-Mobile are based on GSM, which means phones for their networks will often work in Europe and Asia, as well as the United States. Sprint and Verizon use technology derived from CDMA, which means most of their handsets will be incompatible with overseas networks, but they'll work better in rural areas of the United States. Consider your app's intended audience.
2. How many handsets are available, and what features do they offer?
Customers are picky about handsets. Some love their iPhones, while others won't use anything without real, physical buttons. The greater variety of devices that are available for your chosen platform, the more likely your app will reach a broad audience (read: the more likely it will compete with iPhone apps).
More important, the nature of the application you want to build may limit which devices it can support. If you need a touchscreen, an accelerometer, or a compass, for example, you've already ruled out the majority of the handsets on the market. Why code for a platform that encourages backward compatibility with less full-featured devices than you require?
Then again, some platforms are more mature than others. So far, there is only one Android phone available for the U.S. market, although Google says as many as 18 Android handsets [9] may be available by year's end. Similarly, the prerelease hype around the Palm Pre [10] may be hot, but it's all alone running webOS. You may prefer to stick with a more proven platform, such as BlackBerry or Windows Mobile, especially if you will be developing apps for enterprise customers. BlackBerry has long catered to the business audience[11], while Apple hasn't made enterprise readiness a priority [12].
3. How robust is the platform's development environment?
Like it or not, the mobile platform you choose will largely determine the tools you will use to develop your apps. Java ME gives you access to a wide range of standard handsets, but when it comes to smartphones you'll generally want to code to higher-level APIs. Often these are proprietary and cater to specific languages, which may not include Java. For example, you develop iPhone apps in Objective-C, while Symbian and Windows Mobile call for C++. In turn, the IDE you will use will follow from the language: Eclipse for Android development, Visual Studio for Windows Mobile, Xcode for iPhone, and so on.
One important consideration is your comfort level with the frameworks and APIs available for your platform. Some platforms may offer multiple ways to develop applications -- for example, BlackBerry may offer too many [13]. The critical issue is the amount of documentation and support available to developers. Apple, for example, based its iPhone SDK [14]on familiar Cocoa APIs from Mac OS X, ensuring that iPhone developers would benefit from the wealth of existing information about the Mac OS X development platform. Other smartphone platforms have a fairly steep learning curve; be sure you know what you're getting into.
4. Does the platform's application delivery method measure up?
Like it or not, application delivery is the new frontier for mobile software development. Apple showed the way with the iTunes App Store. From now on, few consumers will be willing to put up with a smartphone platform that can't deliver fresh applications on demand or an ISV that doesn't deliver its apps through "proper channels." Unfortunately, to access the iTunes App Store, you need an iPhone.
Plenty of other vendors have stepped in with app stores of their own [15], but it's still too early to determine whether any of them will be as successful as Apple's. It's worth evaluating them yourself to see if their user interfaces, payment methods, and pricing match your own expectations. Still, be prepared for slow sales, for the time being.
Of course, not every app is targeted at consumers. Apple offers an enterprise developer program [16] that enables private distribution of apps within a company, and other platforms provide alternative delivery methods, as well. Do you want to be able to load apps "over the air," from the Web, or via USB? All of these choices will limit which platforms you will want to develop for.
What choices have you made?
Application development for the smartphone market is only just heating up, but it's guaranteed to be one of the hottest areas of the software market in the immediate future. Smartphones are already the preferred devices for connecting to the Internet in Asia and other markets, and their use in the United States is expected to explode in the coming years. That means the platform wars are only just beginning -- so tread carefully.
Have you standardized on a single platform for mobile app development, or are you trying to remain agnostic? If you have chosen a platform, which one have you picked and why? Sound off in the comments below, or in InfoWorld's new mobile app dev discussion forum [17].
No comments:
Post a Comment