RIM announced yesterday that the upcoming Playbook will be able to run Android and Blackberry Java applications in what they call a an “app player”. RIM is also releasing a native SDK for Playbook, but this uses C/C++ and a different API. Being able to run Android apps is interesting, but it comes with a catch: a developer will have to rebuild and repackage their Android apps, and submit them to Blackberry App World for approval and distribution. Anyone hoping to be able to obtain their apps from the Android Market or Amazon will be out of luck. Even Blackberry developers will have to go through the rebuild/repackage step, which is disappointing.
On the surface, this looks like a good idea, and it might work to jumpstart the moribund Blackberry App World inventory. However, requiring developers to essentially port their Android apps over means that there is always the possibility that the Playbook environment and API won’t be the same as the Android API, specifically in how it works. Then there is the issue of how far behind RIM is compared to where ever Android is, version wise. Don’t be surprised to find that some apps don’t work properly, if at all. Android developers will still want to obtain a Playbook, and thoroughly test their apps before submitting them to RIM for sale and distribution.
While I understand RIM’s desire to maintain some control over how apps are distributed on their devices, this was a chance for them to potentially get a leg up on the Android and iOS tablets, by being a somewhat open platform. But requiring developers sign up with RIM, set up yet another set of payment instructions and agree to yet more contracts, creates a small barrier that some developers may decide isn’t worth crossing.
However, RIM’s approach to development still appears to be disjointed and fragmented. By using C/C++ for the native SDK, they’ve created yet another toolset and framework that developers need to learn and use. That means that, for the two platforms RIM offers, a developer has to write apps in two different languages with two different APIs. While it is unfortunate that Apple is the lone holdout with Objecctive-C, at least the coding differences between MacOS and iOS aren’t onerous. My bigger concern for RIM, though, is the effort involved with having to maintain 3 different API’s (Android, Blackberry, QNX) and 4 run-time environments (Blackberry native, Blackberry Player, Android Player, QNX). Based on experience with other technology vendors, the likelihood of one or more of them getting out of synch with the rest is pretty high. Trying to keep track of which is current and which isn’t (and what is deployed in the wild) becomes a bit of a headache for 3rd party developers, and a bunch of work for RIM.
This announcement sounds promising, and how successful it is remains to be seen. I hope the Playbook does well, because a vibrant market for products typically makes all the products better. But I’m not sure that this announcement is a great as it seems on the surface.