iPhone SDK: Correcting BREW and J2me

My friend Robot Two over at  2 Robots recently wrote an article about how the iPhone SDK is actually the best of both worlds and not nearly as bad as some are stating. The first half of his article is below.

“Apple seems to be getting a lot of negative press on its recent SDK announcement. Much of the criticism seems to focus around two issues: That not all functionality of the phone is accessable via the SDK, and that Apple controls the distribution method to the phone. I’ll adress the second point first. Some perspective on the history of apps on cell phones will do a lot to put this in perspective, and see why these decisions were made as tradeoffs, and actually strengthen the position of the iPhone as a leader in custom applications.

For a minute, put yourself in the mindset of a developer of phone software. Arguably, having developed applications which were sold on Verizon Wireless and other cell carriers, this is a bit easier for this author. As a developer then, and attempting to receive some sort of compensation for your work, it would seem that there are too many platforms to develop for, all of them bad for different reasons.

QUALCOMM’s Binary Runtime Environment for Wireless (aka BREW) is used by several major wireless carriers. From a technical perspective, it is a C-based API, which means that the learning curve is slight for C programmers. The best thing it has going for it, though, is that there is a centralized game store and market place. In theory, developers post their applications and games up to Qualcomm’s website. Carriers look through those apps and choose which ones they want to sell to their customers. Customers have one place to go to buy apps (Verizon calls it “Get It Now.” For a developer, BREW sounds like a great model. You don’t need to worry about selling to end users, or billing, or packaging up your product and selling it in a store. Customers can go on their phone and see a list of every piece of software available to purchase. If they do buy yours, they get the price of your app added to their phone bills. Nice and simple. What could be wrong with this?

Well, as it turns out, carriers aren’t interested in providing, what is to them, low margin software to their customers. They want to be able to sell games and applications (and ringtones) mostly as a way to get customers to switch to their network, and buy their cellphones. Consequently, there is little or no incentive for a carrier to decide to actually carry the game you (the developer) posted to the Qualcomm web site. This is why if you have Verizon Wireless, almost all the games available from “Get It Now” are from either from a huge game studio like EA or Sony, or based on a popular TV Show or Movie. The carriers simply don’t want to be bothered by a plethora of developers for what they consider to be chump change. As a developer, if the carrier doesn’t choose to carry you, you are out of luck. No way to get around them, no way to appeal, do not pass go, do not collect $200.

The other major platform for phone development is Java 2 Mobile Edition (AKA, J2me). This is the complete oposite end of the spectrum. Anyone can create a J2me app. When it first came out, J2me looked very promising. Like Java, which it is a subset of, software written in J2me could be run on any phone with Java support. Customers would be free to acquire software from any developer, anywhere on the planet — the carrier wouldn’t have complete control of the application pipe like in the BREW model. This would mean that developers have a much larger market of customers to sell to. Sounds like a good solution, right?

Unfortunately, while J2me was promised to be a great equalizer, this has turned out to be far from the reality. While BREW apps do require some amount of customization for each different handset it is released on, J2ME can vary even more greatly between them. Even different phone models released by the same manufacturer may not support the same J2me program! Because of the sheer number of phones and carriers which support J2me software, it is nearly impossible for a developer to write and test software on all of them. This means that any J2me application will only run on some subset of J2me phones.

Additionally, while the phone carriers cannot blockade access to their devices, developers must figure out how to get their product in front of customers. They must conduct marketing, figure out a billing model, and make sales individually to each customer. Applications are not digitally signed (as they are in BREW), so it becomes difficult for developers to prevent piracy of their product. Combined with the fact that most phones have a horrific user interface in general, and especially for installing J2me software, there are a series of significant barriers for selling J2me software which make it unpredictable to determine beforehand whether a product will succeed. This is a scenario that deters buisness-minded developers.

Of course, there is also the set of “Smart Phone” platforms, Palm-OS(now defunct), Windows Mobile, and Simbian. These each have their own sets of pros and cons. Certainly they have been successful targets for some developers, but for the purposes of this article we will say that the average user of those phones are typically very different from the average user of a regular phone, and specifically of an iPhone.

This brings us to the iPhone SDK. Apple seems to have derived the strengths of the business models of both BREW and J2ME.”

For the rest of this article, please follow this link to 2Robots.

Tweet This Post Plurk This Post Buzz This Post Delicious Digg This Post Ping This Post Reddit This Post Stumble This Post