Mobile Development Platforms: a survey

How many mobile development platforms does the world need? One? Maybe two? At most, three?
How many do we have?
Here is my list, in a certain order of importance.
1) Java (or J2ME). This is more of a 'write once debug everywhere' platform, with every phone manufacturer deciding to implement subtle differences in the platform, JSR compliance and behavior. A midlet written for one set of devices (say series 40 on nokia) can take anything between 2-4 weeks to work on another set of devices. Then, we have discoverability issues: most midlets disappear somewhere two-three menu levels deep in the phone menu. The core MIDP APIs fall short for doing complex UI: you either have forms (which are ugly but look equally ugly in all phones) or do your own drawing on the canvas (pretty on one phone but would not work on another). In short, it really makes me wonder why companies are spending so much resources developing J2ME midlets. The short answer, there is nothing better, yet!
Sun has its SDK and simulator for Windows only. Mac users may try out mpowerplayer. The simulator gives a decent debugging environment, but then the developer is pretty much stranded on the actual devices.
2) Symbian: It comes in two major flavors: Series 60 (Nokia) UIQ (Sony Ericsson, Motorola). Series 60 has its series on editions as well, so application writers have to be careful about that. Series 60 is more powerful than J2ME in terms of how much of the device is open to the application developer. But as the charts in http://www.mobref.com/statistics/world/allPlatforms show, Java has a slight edge in terms of numbers. (The reason why the total crosses 100% is because Symbian phones run Java as well). Symbian also has windows based simulators, for both flavors. Nokia's developer ecosystem is pretty impressive (with Forum Nokia, their own application store) which goes to show how serious Nokia is about their developer story.
Now, for the three platforms (OS) with less than 5% of total phone market share. (as of Sept. 2008), but most projections show that it is just a matter of time before they catch up.
3) Windows Mobile: The mobile operating system from Microsoft, with a pretty good development tools.
4) Blackberry: The phones from Research in Motion. The native development environment is based on Java, but the difference is significant which makes me count it separately. Here is a link to the development tools for the Blackberry.
5) Mac OS X (iPhone): Developers can use the iphone SDK to develop and debug applications and then work through the Apple AppStore to deploy it. The development environment is the best that I have used. Of course, it only works on Leopard. Good luck! Applications cannot be put in background, which means it is not the way to go for 'always on applications'. I think that Apple will eventually enable it, once they figure out how to solve the resource usage issues with multiple background applications.
Finally, two notable platforms with enough investment and activity, although they haven't shown much promise in the marketplace, yet.
6) BREW: The Binary Runtime Environment for phones with the Qualcomm chipsets. Mobile developers who want to target the CDMA market in a big way should consider this. The barrier to entry, however, is high, with cumbersome certification rules.
7) Linux: As usual, it comes in a lot of flavors, with some phone manufacturers internally adopting it as the OS. The two notable flavors are Qt (from Trolltech, now Nokia) and Android (from Google), the Android APIs use the Java Language.
Then, there are a few cross-OS platforms
8) The browser : Almost every data enabled phone today has a browser. How well the browser does in rendering web pages varies, though. There is a longer discussion on 'browser as an application platform' below.
9) Flashlite is trying to take Adobe's (formerly, Macromedia's) success in Flash to the mobile.
There is Silverlight for Mobile from Microsoft and Adobe's AIR, but it is too early to say where they are headed. Sun's work on JavaFx is also along the same lines, although I wish Sun spent more time on solving the JSR fragmentation issues. So, these three dont 'count', for now. (If they did, that would be a dozen developer platforms).
On the widgets side, there are a bunch of companies trying to do 'cross-platform' widgets. Yahoo Mobile Widgets (BluePrint) is a platform on top of Java. Opera has its own mobile widgets platform. The Astonishing Tribe (TAT) have their own UI framework, called TAT Kastor. There is Plusmo, there is widsets, and so on. Again, it is unclear where this is headed, including W3C's work on Widgets. The BONDI work from OMTP is on similar lines. Of the above, TAT is particularly interesting, with their relationship with S60 and Android. Opera's Widget work is interesting as well. They recently announced a relationship with UIQ.
Don't the developers need 'fewer' platforms? (The exact same sentiment as in this blog post from Little Springs Design )

So, what should a mobile application developer do?
Here are the options:
1) Try to develop on each platform, with diminishing returns with every new platform to which the application is ported to.
2) Understand your customer: That is, try to find out whether your customers need you to port on hundreds of phone models from at least half a dozen (Nokia, Sony-Ericsson, Motorola, Samsung, LG, Apple, HTC,...) manufacturers with different programming environments, or are you okay just concentrating on top two? Do you need a great user experience (in which case avoid Java), or, is reaching multiple devices more important than having a great application (in which case just use Java). If there is a need to reach non-data enabled device, use SMS.
3) Wait, for one (or two) dominant platforms to emerge. It may become a long wait.

Browser as an application platform.
This is where I spent a few years working on, unsuccessfully. The fact that the browser has been able to give an excellent programming environment is behind the success of the Web. Also, the fact that browser market share could jump from one dominant browser (Netscape) to another (Internet Explorer) meant that the developers did not have to worry that much about fragmentation. Internet Explorer came after Netscape got a dominant market share, which meant IE had to keep bug compatibility with Netscape. Anyone who wants to challenge IE now (Firefox, Safari, Chrome) will have to keep bug compatibility with IE. All good stuff for the developer. Standards obviously helped, but that was not the whole story. Unfortunately, this has not happened on the mobile front.
There is a real opportunity to standardize on the browser as THE platform for the mobile, that is, start with the current implementation of XHTML, CSS, Javascript, plus try to standardize on things that will immensely help the mobile developer: offline browsing (provide some data storage) and access to internal phone data: addressbook, calendar, file system, camera and the menu system. Then, add adequate security options and provide opportunities for mobile operators and handset manufacturers to monetize on that. In other words, the operators and handset manufacturers get to "sell" their interfaces (in a standardized way) to mobile application developers who want the richness. The security issues of a rich and deeply integrated platform probably needs a separate blog post. But security isn't a problem that can't be solved.
Yes, the browser itself will become a commodity (and it should be) and may cause the demise of companies trying to make money just by selling browsers if they dont innovate (think Openwave, think Teleca) or if they dont find anything connected to the browser (say, an SDK or a set of end to end services) that can be monetized. There is still a lot of scope for innovation in the browser itself: in terms of faster network access, less memory and battery consumption, better usability.
There is one problem here and that is a big problem. The current browser based tools do not give the ability to do what I call 'pixel-perfect' UI. The attempt to solve this in a standards based way has failed: with almost no adoption of SVG and the acquisition of Macromedia by Adobe. SVG lost out not for lack of implementation, but for lack of developer tools.
Which brings us to Flashlite, again. I think, among all the platforms, Flashlite has the best chances of making it. It has a dedicated developer community, good developer tools, a presence in major handsets and a viable business model.
The way for the browsers to compete here is not with yet another markup language, but by filling the gaps in HTML+CSS. The markup purists may not like it, but adding HTML tags and CSS properties to do advanced graphics is a good idea. Incremental ideas like border-image CSS property (draft, final version) can give a good path to mobile developers for a better UI experience.

Summary
Actually, there is no summary. The mobile developer has to pay the price of entering a chaotic market. Eventually, all markets mature and this will too. For now, I will advise mobile developers to follow option #2 (that is, select the platform based on your customer needs) and wait for consolidation. In the meantime, I will cheer for a browser based mobile application platform.