Smartphone programming is booming. The little leash that lets your boss reach out and ruin your time off is turning into a platform of seemingly infinite possibilities. It's more than just iPhone applications that simulate a glass of beer that drains as the accelerometer measures the amount of tilt. The new smartphones can act as a wallet, a personal shopper, a personal trainer, and a source of endless amusement.
The bad news is you're going to need to cool your jets and take a few breaths. While every good programmer looks at a smartphone and sees a machine that can run rings around yesterday's desktops, not everyone has the same vision. The phone companies, the ones that own the towers and deliver your inspired bits to the general Internet, don't see your dreams. They worry that your totally awesome idea is going to totally flood their network with packets and shut out everyone else. They know that the infinite loop you forgot to debug is going to drain batteries. They're afraid that you'll find some clever way to cut them out of text-message profits. They're sure that you just want to spam someone, anyone, because now you can do it with a cell phone while you buy milk.
There's no point in thinking about it too much. If you want to write code for the iPhone and enjoy the wonderful playpen that Apple built for us, you're going to have to play by their rules. If you want to write for the Google phone, your life will be a bit freer, but you'll need to remember that they've got a kill switch and the power to destroy your dream. The good old days of peeking and poking around in memory are gone. The word "root" won't come through your fingers unless you decide to run up the pirate flag, void the warranty, and live forever outside the civilized world, where updates are supposed to work.
To understand the world of smartphone programming, I waded up to my ankles into six major platforms: the iPhone, Google Android, RIM BlackBerry, the Palm OS, Windows Mobile, and Nokia Symbian. I downloaded the development kits, wrote a few lines, and spoke with some programmers who have waded in a bit deeper. Limiting this survey to six platforms was still difficult because it leaves out some good opportunities, like the very open OpenMoko and the cross-platform power of the Java Micro Edition, a version of Java that runs on a number of phones.
The ankle-deep survey left me in awe of the wide-open competition and opportunity for everyone. Unlike the desktop world, there are more than a few players, and the niches are evolving, merging, and splitting. Some of the platforms are better for tightly integrated enterprises, while others offer much better opportunities for gamers and experimenters. Some require the highest-end hardware with the most expensive contracts, while others work well with cheap phones too.
Jason Flick, president of the Ontario-based Flick Software, a mobile solutions company, says he pushes his clients to identify the most important demographic group that will be using the software, then target the phone that's most popular for that group.
"On the business side, those guys are into BlackBerrys," he says. "All of the executives are using them. If you have a business app, that's what you want. But it's hard to do sexy and exciting."
Other applications fit better with low-end platforms because the users don't own the high-end phones. The groups usually don't intersect, but that's changing. Apple is working hard to attract business customers, and RIM wants to add more flash to the BlackBerry platform. The Nokia Symbian and Windows Mobile worlds live on phones with a wide range of IQs, display sizes, and features.
But only native apps make full use of the accelerometer, GPS, and other prize features. And if you want to build native apps, you'll have to make a choice regarding audience, devices, languages, tools -- in other words, the entire ecosystems of the major smartphone vendors. With that choice in mind, here's a snapshot of where those ecosystems are right now.
The roots of Apple's success with the iPhone are easy to see. Every part of the development chain, from the initial Xcode application to the final store, is polished and polished again. The programmers at Apple sweat the details and spend their time trying to make things simple, elegant, and intuitive. Programmers get to bathe in the same production values as the end-users because the tools are polished, with almost as much care as the main interface. The documentation is great, the instructions are copious, and there are plenty of examples.
The main tool, Xcode, has been a staple of Mac programming for some time. While I continue to like Eclipse for many reasons, the speed and polish of Xcode put it to shame. There's no need to stop and get coffee while Xcode starts up. And there's no need to hide your eyes.
The iPhone's main language is Objective C, and the main framework is Cocoa. If you're still in doubt as to whether NeXT took over Apple or Apple acquired NeXT, the iPhone should end it. It's an updated NeXT machine that fits in your pocket. You can stitch up your application and thread the widgets together just like it's 1988. The same names and concepts, like "Interface Builder," are still around even though the implementations are enhanced.
I think it really helps to have some history programming the Mac if you take up the iPhone. While much of the work is threading together widgets, just as with all of the other frameworks, there will be moments that remind you why C is called machine-independent assembly code. Java programmers will need to remember that the data is dynamically typed, then spend a few minutes relearning how to allocate and free memory because it's their job.
Samuel Kass, a programmer who created a Chess Clock for the iPhone, says, "There are lots of little gotchas, and as someone who's used to Java, it's frustrating to have to go back to worrying about explicit memory allocation." There are major APIs for all of the cool features. If you want a picture, you can grab an image from the camera. If you want to know which way the device is moving, you can query the accelerometer. These APIs are pretty low-level, and it's a long path between getting the acceleration vector and any usable UI. One programmer joked that once you find out the acceleration, it's a snap to write Super Monkey Ball.
Developers are also chafing at Apple's decision to allow the iPhone to run only one application at once. If you're used to relying on the operating system to swap out your application and keep it out of the way while someone starts up another one, you can start learning what life was like before the Mac came with MultiFinder. This rule probably has some utility because it forces developers to consciously give up control and save their work -- something everyone should be doing already. But it means more coding for developers, and you won't be able to blame someone else when your app crashes. The competing platforms, though, can sense the vibe flowing through the community, and they're emphasizing the fact that their phones can handle more than one task at once.
It's worth noting that there's a great deal of confusion over the breadth of Apple's nondisclosure agreement. One developer who was offered a chance to talk about his iPhone software wanted to check with a lawyer. Some of the development documentation that used to be more public is now locked behind a wall that requires you to log in.
All these hurdles are manageable for those who want to make cute applications and sell them through Apple's store. As long as you cross your fingers and avoid the big landmines -- porn, bandwidth hogging, competing with Apple -- you'll probably be fine. But nothing is certain because even Google saw its iPhone application delayed at birth.
The iPhone marketplace is a great innovation -- if your end-user is a customer who will use iTunes to download it and install it. The sales numbers are phenomenal, and Apple's done a nice job making it easy for developers to push a button and watch the money roll in. Some wonder if the flood of applications is driving prices to zero because many developers seem to cut costs frequently, but that's life with a free market.
Everyone else, though, is going to jump through some hoops that will seem odd to everyone who is used to sharing binaries without saying, "Mother, may I?" The Developer Enterprise Program is "available to companies with 500 or more employees." All registered developers can "share your application with up to 100 other iPhone or iPod Touch users with Ad Hoc distribution." But what if you want to mail it to between 101 and 499 friends? Or what if you're a restaurant owner who wants to build something for the iPod Touch? It's all rather dicey. There are reports of new developer codes for the iTunes Store that make everything much simpler, but it's still not like the good old days when you could just hand a floppy to a friend. After a few days of trying to get all of the cryptographic certificates correct, I started cursing the people who developed public key cryptography. This isn't what the cypherpunks imagined way back when.
A number of developers use the h-e-double-hockey-stick word to describe the process of actually testing code on an iPhone. Xcode lets you do anything with the simulator, but using an actual device means filling out forms on the Apple Web site. Someone somewhere is clearly worried that something will be done without permission from the mothership, and boy, does it cut into development time.
There's some indication that Apple has heard these pleas. Apple has improved the provisioning process and it will probably spend more time improving it again. But you can pretty much forget about using the word "my" in front of the word "iPhone" because it's Apple's sandbox, Apple’s App Store, and Apple’s code stack. Apple just lets you play in it -- and it kicks back 70 percent of the revenues from the store too.
Google's Android is remarkably similar to the iPhone in many ways. Accelerometer? Check. Camera? Check. Application store? Check. OpenGL for graphics? Check. GPS? Check. Sure, the first Android phone comes with a keyboard, but that's not really a concern for you. You'll still get your keypress events just like an iPhone programmer.
There are some differences under the hood, but they're not as big as might be expected. Both the iPhone and the first Android phone use OpenGL to render the graphics and the UI, but Apple's can take the lead with floating point values. The iPhone's processor is better suited to floating point math.
The deepest differences may be in the language itself. Google chose Java, a language that's well understood by many new graduates. Then it built special plug-ins for Eclipse, so all of the lovers of programming Java with Eclipse can write code, push a button, and simulate running their app on the phone in a separate Java process. The tools are all available for free, and it takes only a few minutes to get the Hello World application up and running, most of which is spent waiting for Eclipse to create a bazillion objects of its own as it starts.
Java programmers who don't use Eclipse can still get it all to work, but it seems to be a bit rougher. The framework for projects are built with some Python code, a perfectly logical choice, but one that seems a bit discordant. Much of the other work can be handled by Ant plug-ins.
It's a bit of a misnomer to say that Google chose Java because much of the actual work can be done with a maze of XML files. Anyone who writes this code should get used to typing the word "Android" because all of the XML files use the word for the namespace specifying the attributes for the nodes. Programmers -- or maybe I should say XML form-filler-outers -- can build up all of the user interface and some of the details with a maze of XML nodes all tagged with integers. It's been a long time since I wrote down unique ID integers instead of unique ID strings when I tried to work through some code, but I did when I looked at some Android apps.
After getting lost in these files filled with options for localization and UI widgets, I gave up and started writing pure Java code. It's actually possible to create Java objects directly and link them up with other Java objects instead of sketching this out in XML and waiting for some Java code to parse the XML, create the objects, and link them together. The direct approach worked much better for me.
After wading through this, I began to see the same basic widgets and ideas that are common in the iPhone and, for that matter, many UI frameworks. There are TextViews, TableLayouts, and MapViews just like on the iPhone. These platforms really are small desktops with rejiggered proportions for the windows.
There is one point, though, where iPhone and Android diverge. While Objective C is similar to Java for many intents and purposes, it is a dynamic language. Some Java programmers report that they are much happier to let Java take care of the memory management and catch bugs at compile time. Other Java programmers point out the usefulness of still thinking like a C programmer, because memory is at a premium on a smartphone and garbage collection can cause hiccups.
I have noted some divergences that might rankle people. Why did Google build its own framework instead of using something a bit more standard, like the Java Micro Edition or plain old Swing? Neither has a wonderful reputation, but it might have made sense to rework them instead of starting anew. I'm not sure I can even guess except that it wanted to do things the Google way. Anyone who's used other Google tools -- such as the Google Web Toolkit or the App Engine -- will recognize the spare, no-nonsense aesthetic immediately.
It's worth noting that the Android platform is significantly more open than Apple's. If you want the documentation, it's available for you without clicking through some gateway. The discussions about the platform are open and encouraged. All of this should be a big advantage to enterprise developers who want to ship something to everyone in an office without jumping through the hoops from Apple.
"When I was writing a chapter on sound for 'Hello, Android,' I found it useful to study the source for the media player to clarify a few things that were not covered well in the documentation," says Ed Burnette, the author of the Hello, Android tutorial.
Still, there are limits that may be practical but won't please the faithful followers of Richard Stallman. Android may be all open source, but not everything in the Google phone is part of Android.
There are some loopholes. Google is now selling developers a completely unlocked phone for $400. This is an excellent option that will attract many programmers who long for the joy of logging into the phone as root and of flashing the ROM with as much modified code as they want. I have a hard time imagining how end-users will ultimately benefit from developers having more access, but that doesn't matter. It's a nice option that will encourage more creativity.
When a friend of mine moved to Washington, D.C., he was told he needed to get a smartphone because that's what one did. There's plenty of spare time between meetings and more than enough nervous energy to be turned into thumb taps. The new apparatchik, a longtime Mac lover, wanted to get an iPhone, but his new colleagues set him straight. The iPhone would flag him as an artsy trend chaser, but a BlackBerry would establish him as a bona fide member of the group serious enough to run the country. So he chose a BlackBerry.
BlackBerry developers will quickly learn how well the company knows that people choose the BlackBerry because they're dedicated team players. RIM's market is the enterprise developer. Within a few seconds of starting to create an application in the BlackBerry MDS Studio, I put up a form wrapped around a Web service. The tool's software wizards took the URL for the Web service, popped up a list of public methods, then designed a form for me once I chose a method. Boom. The BlackBerry has a front end that funnels input from the keyboard directly to a Web service call, then formats the result. It's not pretty. There are no flashy OpenGL graphics or flippy cards warping through multiple dimensions -- just a form, a Web service call, and the answer.
This example comes from the Rapid Application Development collection of classes and tools, built as plug-ins for Eclipse or for Microsoft Visual Studio. This collection of tools lets you build a set of forms by dragging little widgets to a page. In the background, the tool bundles all the descriptions into an application that's loaded on to the screen of the simulator. You don't really write Java code at all for this level.
There is another level that's open to the developer if you feel the need to write Java applications. The BlackBerry system is a proper version of the Java Micro Edition, something that makes it easier to migrate to the platform from some of the other phones. You run into javax.microedition classes frequently, and they become part of your code. The GPS functionality is based on JSR 172, and the multimedia follows JSR 135. In other words, BlackBerry looks like a closer partner to Sun than Google does.
"We created our own proprietary APIs," explains Mike Kirkup, a manager of developer relations at RIM. "You can write a pure MIDP [Mobile Information Device Profile] application, and it can work independently across a variety of platforms, or you can write only using BlackBerry-specific APIs, or you can mix and match."
The BlackBerry-specific APIs open up more access to the BlackBerry's hardware controls and don't abstract them like the Java MIDlets.
There are some other features that aren't as available on other phones. RIM is quite proud of the fact that the applications don't have to die when a user switches to another application. Your code can start up threads that watch for incoming messages pushed from the server. That's a nice feature for desktop and Web programmers who are used to a looser sandbox and also one that makes the platform richer and more useful.
Game programmers used to spitting out OpenGL won't be happy with the BlackBerry OS, but it's still possible to do a perfectly good job with animated SVG (Scalable Vector Graphics) files and many other forms of video codecs available with the JSR 135-compatible media programming framework. Those may be enough because many BlackBerry users spent their teen years with Nintendo games, and some were even born before Pong came along. Cool graphics may not be necessary to pique their interest.
The simulator lets the programmer experiment with what happens when the user reacts to events by answering a call, ignoring it, or placing the handset in a holster. There are also options that simulate moving the phone to any coordinate.
"The simulator is way better than the Windows Mobile emulator," says Jay Flick. "They really put a lot of work into simulating the incoming calls, simulating the GPS. For delivering a quality product without having the device in your hands, RIM has that down pat."
BlackBerry's software distribution model is also more of a throwback to the days when you installed software by copying files, not by syncing with some iTunes store. You can even use a command line to load the software over a USB link. Java MIDlets can be downloaded from Web sites out there. All of this makes the BlackBerry world a bit more familiar to desktop programmers. Nevertheless, the success of Apple's App Store hasn't been lost on RIM. The company recently began accepting submissions to the BlackBerry Application Storefront.
One of the trickier conundrums facing the BlackBerry programmer is supporting the installed base. The new BlackBerry Storm comes with a bigger touch-sensitive screen and an accelerometer, two features that make it more like the iPhone. Longtime users love the old-style thumb boards, and their visceral reaction to change may mean that the old screen sizes and layouts will be with us for some time to come. This shouldn't be much of an issue for enterprise programmers and others who want to write serious software for serious people who want to plow through some serious data.
It's easy to forget about Nokia and the Symbian platform after wading through the hype about iPhone and the Google phone. As I'm writing this, AT&T is selling a Nokia 2610 for $10 with no two-year contract. An iPhone might cost you several thousand dollars over two years, but the Nokia will do the job for $10 and 25 cents a minute. The low-end phone might not offer a great Web browser, GPS, OpenGL graphics, or other tools, but it runs Java ME (Micro Edition) applications and delivers the packets for a dramatically lower price point.
The good and bad news is that this is far from the beginning or end of the Nokia line. The company just introduced another phone, the N97, which comes with a touchscreen, GPS, Bluetooth, and too many other acronyms to list. One devoted fan writes on Engadget, "One has copy and paste, A2DP, a QWERTY keyboard, and a screen resolution which is 1.5 times larger than its rival. Meanwhile, the rival has a (inconsistently) walled garden and a smug bastard swimming in sacrificial fanboy donations from Cupertino." The Nokia phones are good enough to attract their own fanboys.
The challenge of developing for Nokia and Symbian is working with such a wide range of platforms. There are phones that cost hundreds of dollars and show video at 30fps, and there are others with black-and-white screens with big fonts, features that incidentally play well in markets like Florida, where older people with poorer eyesight need to look at the screen in bright sunlight.
The good news is that the Symbian world is much closer to the desktop world than are some of the bigger phones. If you want to download someone else's software for your phone, you don't need to ask "Mother, may I?" or search very far. Shareware and freeware are everywhere. Dozens of people seem to offer download sites with open and not-so-open packages for Nokia phones. Academics like Stefan Damm, Benjamin Gmeiner, and Andreas Jakl post their semester projects on sites like symbianresources.com, where anyone can download their software, including gBoarder, a package that uses the accelerometer to measure the jumps of a snowboarder descending a slope. It's not a walled garden, but just another corner of the chaos of the Internet. There are safer harbors, though, because Nokia runs its own Download Store filled with applications that range as widely as Apple's.
The development tools reflect the breadth of this world. The latest batch is almost 500MB, and that doesn't include an IDE. Some Symbian developers use Microsoft's Visual Studio, others turn to Eclipse or Carbide. I think some even use GCC (GNU Compiler Collection) with a command line.
If you want to write to the Java ME, you're encouraged. If you want to write C++, you can. In fact, there are three different flavors of C and C++ to muddle your choices: standard C++, Symbian C++, and Linux C for platforms like the 810. The Symbian version of C++, the preferred solution for most phones, adds features that help the programmer live with the small screens and limited memory by offering tighter exception handling, a certain amount of garbage collection of objects, and some network tools for handling asynchronous calls. These limitations are fading, though, because Nokia is proud that the newest version of Symbian C++ includes standard C++ exceptions too.
If that's not enough, there's also a nice implementation of Python and a good community built up around the platform, and Nokia's research group also delivers an open source version of Perl. Adobe Flash Lite is an option too. My favorite choice may be called PAMP -- short for Personal Apache, MySQL, and PHP -- for your phone, a tool that lets the Web developer create personal applications without learning C++, Java, or those other icky languages where instructions are written without HTML tags. Don't ask me if it really works -- just the fact that it exists says a lot about the platform. While the iPhone brought a real Safari browser just like a desktop, Nokia is delivering all of the crazy extremes we've come to expect from the Internet.
The world of development for Palm and the Treo is pretty similar to the world built around Nokia phones. The Palm OS is one of the original handheld operating systems, and its world is broad and deep. When I was poking around for weird languages that run on handhelds, I found the most for the Palm. One version of Python, called Pippy, was last updated in March 2003, long before the iPhone and even before Apple rolled out the first really successful iPod, the 3G. The Palm OS is sort of a museum, in a way, but one that comes with a broad and deep collection of software.
This is changing now that Palm officially announced its new webOS. I wasn’t able to work with it at all, but it sure looks promising. It takes some of the great ideas from the iPhone and seems to extend them further. The Web and HTML promise to play an even bigger role in the new Palm OS than in the iPhone, and that's bound to be useful for everyone except game programmers looking for maximum performance.
The old OS will continue to be important in the short term because other products like the Treo and the Centro will use it. I hope some of these roots make their way to the Pre because there are many advantages to working on a platform with such a long history. Open source coders have built tools for working with 2-D text in PDF forms, audio files in a variety of formats, and even video. All of these are available for you with open source licenses if you choose to wade in. If you like working with a command line and your favorite editor, there's a good version of GCC available with many of the favorite Linux world tools. (See prc-tools.sourceforge.net.)
If you want more than freedom, Palm itself offers the PDN (Palm Developer Network) with all of the tools and a long user agreement full of noise about confidential information.
After spending some time with Palm, it's easy to understand some of the rationale behind Apple's tight relationship with AT&T. The information about developing for the Palm is not just segmented by device (Treo, LifeDrive, and so on) but also platform (Palm OS or Windows Mobile) and carrier. Palm helps cut through this clutter with its Virtual Developer Lab, a process that lets you try out your software on any handset in a number of markets throughout the world. You sit at your desk and boot up your software on some handset somewhere else just to make sure it will work for purchasers in that corner of the world.
Some of this confusion must make it hard to keep the PDN Web site up to date because it was easy to trip over old links and musty information. But despite the cruft and dust, I still find myself enjoying the simplicity of the Palm OS. The more I use my Apple iPod Touch, the more I appreciate my Palm TX, a similar platform that delivered all of this palm-sized fun in a very simple and elegant way. The browser, called Blazer, is deliberately minimalist, and that makes it easier to use than Apple's much cooler grown-up browser that requires an endless amount of pinching and twisting to actually read something. Perhaps it's nostalgia, but I think there's something more to this design goal. It's not pretending to be a desktop; it's happy to be small. And if it's nostalgia you really want, there are emulators for the Palm that let you play Nintendo NES games, and they've been around since before the iPod too. I only hope that Palm can keep some of this simplicity intact as it builds out the new OS.
Sure, the Internet is cool. Sure, the Web is neat. But if you live in a Microsoft world, as many companies do, then you're probably writing .Net applications talking with Microsoft servers that store their data in Microsoft SQL Server boxes. Windows Mobile is for you. All of that experience maps over, and while it can be a bit hairy to make the components fit on a tiny screen, you can think of them as one and the same thing.
Windows Mobile is almost as old as Palm's OS, but it's been refreshed a bit more often. Microsoft devotes a fair amount of time to keeping older, legacy platforms like Windows Mobile 2003 and Pocket PC 2002 running. The newest versions support the touchscreens, GPS, mapping, and more.
Jay Roxe, a group product manager for Windows Mobile, explains the breadth of Microsoft's reach: "Windows Mobile phones are made by 56 handset makers [Samsung, LG, Sony Ericsson, Motorola, etc.] and distributed through 160 mobile operators in 99 countries."
Starting up with programming requires buying Visual Studio ($299 to $2,799 with a 90-day free trial), something that's a bit unusual in this arena, where other companies have embraced the open source tools like Eclipse. Still, many Visual Studio developers sing the praises of the platform and often turn up their noses at the lack of polish at the open source tools.
After you buy into the platform, the next investment is in wading through the initial dump of data. You can easily download more than a gigabyte of templates, sample code, simulators, and headers. Microsoft shareholders can rest a bit easier because there were probably more than 1 billion keystrokes devoted to developing this platform, and many of them are still part of the distribution given to everyone.
Much of this complexity comes from the gradual evolution of the mechanism. There are different emulators for all of the combinations that have come out of the electronic factories, like Standard Landscape QVGA (240 by 320 pixels, 131dpi) or Professional Square VGA (480 by 480 pixels, 192dpi). You can fire up your application on these and see how they work.
There are a number of ways to program the platform. Low-level work with the hardware is done in C++. Higher-level work with more customized, form-centered user interfaces is done in either C# or Visual Basic. The tools reach out over the Internet and work with distant Microsoft SQL servers running ASP.Net.
There are other options too. Many parts of Microsoft have caught on to the mobile idea, and they're integrating themselves with the platform. Windows Live blogging, for instance, works with Windows Mobile now.
The greatest strength of this stack of software is probably its place in the Microsoft .Net tradition. It's becoming, like the others, more of a smaller version of the desktop than a handheld with a way all its own. Microsoft stopped calling them "Pocket PCs" and switched to "Windows Mobile," a change that was more than cosmetic. You can feel the overlap between the desktop .Net and the mobile .Net grow. Some sophisticated controls that didn't work on the earlier, tinier screens are now available. Other parts of the API now offer fuller features like XPath for cruising through XML. Threads can abort and join each other.
The options for distribution are quite good. Microsoft doesn't run its own store, at least not in the same big way that Apple does, but it seems to be moving in that direction. Its Total Access program offers plenty of free games, ringtones, and other goodies. Trial versions of games such as Guitar Hero are free but cost $14.99 to unlock all of the features. Developers will probably want to turn to other distribution platforms, and there are a number of companies, including Kagi and Handango, that sell software to phones. There's not one path from compiler to paying customer.
"Windows Mobile is by far the most open," says Flick Software president Jay Flick. "There's very little you can't do." He explained that it was much easier for the programmer to modify all parts of the phone's appearance, including the front page, a place where other development environments exclude third-party software.
Joining the club
Which platform should you choose? Most programmers will be led by their past experiences. These devices, after all, are becoming more and more like little desktops, so it only makes sense to follow the same path. One iPhone programmer's résuméthat crossed my desk pointed out he had been programming Cocoa applications for the Mac for some time. It was only natural that he would migrate to the iPhone.
For the same reasons, many shops with a big investment in Windows .Net programming will see a natural path to migrate to the Windows Mobile world. There are fewer differences now to get in the way, so why not rejigger that desktop app to work with the smaller screen? Most of the widgets work the same way. Java programmers will feel more at home with the phones from Google, Nokia, and RIM.
The big difference between these worlds and the desktop is the greater amount of discordance. They're still too new for many of the differences to be worked out. If you want to write code that will run on many different platforms, Java Micro Edition is one of your best choices, but it's far from a slam dunk. A Swing application may run on almost every desktop these days, but a Java MIDlet won't. The iPhone may be running something close to Mac OS X, but that doesn't mean it has the same Java support.
What should a new business do if it has no legacy code weighing it down? It depends heavily on the nature of your product. Java ME applications run on very cheap phones, and they're widely supported on different lines. The development tools can cost next to nothing, and there's a path, albeit imperfect, to high-end phones like Google's Android that are also programmed in Java.
If you're after sales to end-users, there's no doubt that Apple's tightly controlled garden has delivered some stunning sales numbers. They offer a simple, direct, and trusted pathway that's hard to duplicate with the other phones. But the iPhone is a pain for every other type of development.
Other companies are certain to follow Apple's success. Mike Kirkup, a manager of developer relations at RIM, explains: "We did announce an application store front for launch in March 2009. It's important to understand that what we're focusing on is providing a clear and single point of location, but it won't be the only or sole channel." They'll continue to support many other paths, including independent merchants such as Handango and enterprise channels.
After peeking and poking all of these platforms, I came away assuming that we're only a few years away from the end of the desktop for many casual users. Most of the world will just plug their smartphones into a dock that connects the phone with a full-sized keyboard and a big monitor. The phones already have the power to let people browse the Web and do much of what the average user needs. Only programmers, scientists, number crunchers, and gamers will keep their desktops, but even those cycle hogs will probably follow eventually.