There’s something to be said for consumer choice. I’m certainly glad for the fact that when I buy a cell phone, I have the option of choosing Verizon over AT&T and a Blackberry or Android-powered smartphone over, say, the iPhone. In the mainstream computing realm, choices are mostly limited to Linux (and one of its many flavors), MacOS, or Windows. Sure, there a few other obscure platforms out there, but those are the major players until you hit mainframes.

For years, consumers have had the privilege of making an informed decision about which operating system they want their computer to run. The exception to this rule, of course, is Apple who requires you to buy a Mac in order to run their OS, but even if you do, the choice of running Linux or Windows still exists via BootCamp.

But in spite of consumers and their choices, this level of choice presents a definite problem for software application developers. If I write an app for Windows and decide I also want it to run on Linux, I have to ensure I’m not using platform specific APIs before I recompile or, if I do use proprietary technology, I must rewrite the application for the other platform. This is a huge issue when writing an app that is intended to run on either Windows or MacOS, because the GUIs and core OS capabilities are so different from one another. Building a good-quality application for OS X almost exclusively requires the use of the XCode suite of tools.

Take this issue to the relatively new world of smartphones. If you write an application for the iPhone and then want that same app to run on Android-powered phones, you must totally rewrite the app using a completely different language, system, tool, and so on. It is a LOT of work. Think about the plethora of smartphone OS’s out there: Blackberry OS, iPhone OS, Android, webOS, Symbian, Windows Mobile, and so on. (I’m sure I’ve left a few out). Writing an app for one precludes that app from running on another without significant effort. This is a serious problem because of the time, effort, and money required from a company to develop the same software for each platform. Something needs to change…but what are the viable options?

1. Reduce the number of platforms. This will probably happen to some degree over time simply because of the forces of nature. I can’t say I could pick which of these platforms I’d like to see go away, but it’s likely that two or three players will force the rest out of business. I see the main three being Android, iPhone OS, and Windows Mobile; however, Symbian and Blackberry are still major players, so it’s difficult to say what will happen to them. Right now, the iPhone platform holds the majority as far as smartphones go, but we’re going to see this taper off over the next couple years and the phones and App Store will become much less of a market force. Don’t get me wrong, they’ll still be relevant, but Apple’s closed system is going to hurt the company in the long run unless they change things around significantly. Expect Android to come out on top. This still doesn’t solve the problem entirely.

2. Produce collaboration and standards between platforms. Right now, every platform has their own SDK and set of dev tools. We need open systems that allow development in any language for any platform. The core application functionality will be the same and the OS should take care of the interface look and feel using a standard set of UI widgets. As long as my development tool supports these standards, I can build an app that can be compiled down to a binary compatible with any platform. The UI will look slightly different across platforms, but the overall user experience will be the same. This is the best option.

3. Move everything to the web. Google would probably be a huge fan of this option–just forget about installing applications directly onto your device. Instead, apps can place launch widgets into the phone’s launcher and run the app from the web. Natively. This is a pretty cool idea overall, but it’s hard to say if it will take off. I mean, Steve Jobs tried it and failed, right? Still, if there’s one market force that can pull off a feat like this, it’s Google. How many people have left their standalone email client on the side of the road and jumped on the Gmail bandwagon? It’s ubiquitous, simple, and fast. Can’t say I’m quite ready to toss my Outlook install just yet, but if Google offered Gmail, Calendar, Contacts, Docs, etc in one tightly integrated package…it would be pretty tempting. This is rapidly becoming a possibility, so look for no-install applications coming to a smartphone near you. How will their interfaces work? I can’t say, but I’d imagine there will be some new mobile standards hitting the shelf in the not-so-distant future.

So, at this point, I don’t think there is a good answer to our multi-platform problems, but the problem is being worked on–that’s for sure. As more and more users demand identical apps for their Android/iPhone/Blackberry/Windows/webOS powered device, we’re going to see a much bigger effort to unify platforms and bring disparity to a distinct end. On the mobile front, expect plenty of flamebait to be flung from all sides of the argument at hand. It might be a bumpy ride…