Carriers band together for cross-platform apps, manufacturers laugh heartily 64
Announced at MWC was yet another partnership between the world’s cellular carriers that will end up resulting in, well, very little. Networks around the world have banded together to create the Wholesale Applications Community, which in essence will be a global cross-platform app effort. And here’s why it’s going to fail: manufacturers, particularly the ones that are invested in an operating system (such as Apple, Palm, and Nokia), will have no interest in participating. Especially those that have created an app store, Apple in particular.
The Wholesale Applications Community (WAC) will end as a failure, at best withering away as a token gesture to interoperability. There are a million political reasons why it won’t work, but the biggest hurdles to overcome are the technical ones: programming languages and APIs. While we can see feature phone manufacturers rallying around the WAC, nobody buys a T9 flip phone to run apps. They lack the hardware to properly execute - that’s why they’re feature phones.
App developers too aren’t interested in feature phones, because the meager hardware will limit what they can do. Not to mention the varying screen sizes, processors, radios, keypads, and everything else. App developers are interested in smartphones, and that’s where the WAC starts to fall apart.
The largest hurdle to jump is the diverse programming languages used by the various smartphone operating systems. webOS is hinged on web standards while iPhone OS apps run in Objective-C. A Windows Mobile (and presumably Windows Phone 7 Series) developer works in Visual C++, but his Android-programming counterpart codes in Java. BlackBerry OS also uses Java, but it’s an entirely different beast than Android. And let’s not forget the newly announced MeeGo from Nokia and Intel. God knows what programming language you’ll need there.
These myriad platforms use programming languages so diverse that attempting to unify them would be an exercise in frustration. No OS developer is going to give up on the language they’ve invested in developing an SDK for, and many aren’t going to be open to making wholesale changes to their OS to support a different programming language. The most likely choice for any cross-platform development language by WAC would likely be Java, and most likely of the J2ME variety. Many feature phones already run applications written in J2ME, as does BlackBerry.
Seeing as manufacturers aren’t about to jump ship on their operating system languages, could the WAC put together a code translation suite to take these J2ME apps and translate them into Objective-C, Visual C++, and everything else? Yeah, probably. But the challenges involved in translating code from one language to another are already astronomically high. There’s a reason Adobe’s taken over a year to finish rewriting the CS5 Suite for Mac in 64-bit Cocoa, up from the 32-bit Carbon that is the CS4 Suite. The more complicated your app, the harder it becomes to translate the code and you end up rewriting it by hand anyway.
Assuming that a translation engine could be developed to make an app compatible with multiple OS’s, what kind of apps would we get? It’d be much of what fills the App Catalog already: basic apps like calculators, custom web searches, and the like. Adobe talks about using their Air software to run apps on multiple platforms - but that's after support for Air is installed on the platform. Much like Windows and Mac machines, smartphones can't run Air apps without having Adobe Air installed first.
After making that assumption we run into a new problem: APIs. Every OS has its own set of APIs tailored to the capabilities of the hardware it is designed to run on and the unique aspects of the OS itself. Applications on webOS can take advantage of the interactive notifications bar API that iPhone apps cannot, while iPhone apps can hook into the push API offered by Apple and get their notifications that way. While both are notification APIs, they’re completely different in code and execution. Getting manufacturers to agree on common APIs is just as likely to happen as getting them to agree to support a common programming language.
Again, there’s no reason a translation engine couldn’t be built to move apps from the WAC’s common APIs to those used by the various operation systems. But in the end you arrive at the same problem as the programming language translation: only the most basic stuff can be reliably translated. Using our notifications example, there’s no way to resolve the unique differences between the iPhone notifications API and that of webOS. In this hypothetical API translation situation the best you can get to ensure a common experience across all platforms will be a pop-up notification on the iPhone and the equivalent non-interactive dashboard notification on webOS. The lowest common denominator amongst all platforms will not result in an experience that will thrill users.
These programming hurdles are contingent upon overcoming the political gridlock that would result from trying to get Apple, Nokia, Palm, Microsoft, Research in Motion, Google, and everybody else who wants to play to agree on those common standards. Some, like Palm and Google, might be open to supporting a new standard. Others, such as Research in Motion, may be looking to overhaul their OS anyway and be willing to adopt the new standard as their own standard.
But for each manufacturer that may be open to exploring something new, there are five more that aren’t. Every manufacturer has invested tens of millions, if not hundreds of millions, in getting their OS up and running. They chose to make their own OS because they thought they could do it better; they picked their programming language for that same reason. They didn’t pick it because it would be compatible with somebody else’s apps. That defeats the purpose of making your own OS. If it can do the same things as one already made, then you might as well just license that OS and skin it instead. Successful smartphone OS makers don't play "me too." They innovate and expand and explore new capabilities and features, and chaining an OS to what other OS's are capable of will only stifle development.
The problem that the WAC faces is unique to the smartphone industry. If gas stations were to band together and invest in building a natural gas or hydrogen distribution system, they wouldn’t have to convince car manufacturers to join in. With hundreds of millions of dollars invested in several different platforms, there’s no way the WAC manufacturer commitments will ever reach the critical mass needed to be a draw for developers. In fact, the only manufactures that have signed on with the WAC right now are Sony Ericsson, LG, and Samsung. The only smartphone OS maker out of those? Samsung, with their just unveiled Bada.
So why are Orange, Verizon, China Unicom, AT&T, Wind, Sprint, Softbank Mobile, and 16 other carriers banding together to form this Wholesale Application Community? It’s a publicity stunt, and something they can point to whenever anybody complains about not being able to get X app from platform Y onto platform Z (webOS users aching for Shazaam, we hear you). Carriers will get a small and temporary bump in public good will, but even that may backfire if consumers expect this to actually pan out. In the end, very little - if anything - will come of the WAC in the smartphone space.
Honestly, that's probably a good thing.