Understanding RIM's tablet platform app strategy

Yesterday RIM reported their quarterly earnings. The results were mixed to slightly negative and the shares were down 10% in after-hours trading.

I’ll work through the smartphone market data at a later time but for now what I want to focus on is RIM’s strategy which really means understanding RIM’s intentions or their approach to the market. For that we have to go straight to the source: what management actually says. Trouble is, management often speaks in a jargon that is unfamiliar to people (sometimes unfamiliar to anyone outside the company).

Strategy analysis involves translation. So here follows the interpretation of Jim Balsillie’s remarks during the conference call (transcript sourced from

What Balsillie Said My interpretation
First of all, what we announced is Gingerbread. This is not Honeycomb. I don’t know what the number of Honeycomb apps is, but it’s not very many. Whereas Gingerbread they’ve got lots of them. RIM will support Android apps in the PlayBook tablet. As there is not one Android, I need to clarify that RIM will not support Android tablet (Honeycomb) apps but Android phone (Gingerbread) apps. So RIM’s tablet will support Android phone apps even though our tablet does not actually have a phone in it, but requires tethering to a BlackBerry for cellular data.
You’ve got the volume of the handset apps, so if you’re looking for the tonnage of apps, or some kind of long tail stuff, you’ve got it. This support means there will be many apps including apps that are not very popular. We don’t like supporting unpopular apps. We like a few good quality apps but this approach allows us to offer all kinds of apps.
At the end of the day, people are going to want performance. However, many apps will not run smoothly.
You’re just not going to get things like gaming and multimedia, you’re not going to get the speed going through a VM interface. If you want content, or Flash type stuff, or you’re looking at AIR-type, evolving web-type assets, that’s what you’re going to do. Games and graphics will not run well through emulation. For processor intensive experiences we will have native execution options or browser apps.
There’s no compromise here. You’ve got the tonnage of apps. And you’ve got the performance. Do I think the tonnage is overplayed? Yes. By supporting emulation of Android apps we can offer a large catalog of so-so apps while having a small portfolio of high quality native apps.
But if you think it’s about having a couple hundred thousand apps, there you go For people who value large selections, they can go to one store.
Do we believe it’s about super high performance? Yes But for those people who value quality, they can come to our store.
I’ll just offer that observation that today broadly in the world without any specific comment on us or our competitors, there are multiple ecosystem patterns that need to be considered Beside emulation and native we also think there are many other ways to deliver applications.
Do we believe it’s about full web fidelity? Yes. For example, Flash.
These are concepts that were really relegated as not technically possible, which we’re doing here. This is a no compromise environment. Because of Moore’s law, Flash is becoming viable on a mobile device.
If you want to work on Android, great. Do we think people will want to migrate web assets? Yes Then there are browser apps.
Do we think they’re going to want super high performance native assets with the SDK? Absolutely We will have our own native SDK.
You think they’re going to want to use their Flash based stuff for an offline Flash/AIR type environment? Yes And support Flash.
I’m just not interested in these sort of religious application tonnage issues.  I really think we put that issue to bed. We have a new platform but catalog sizes can no longer be used against us.
And if you think the whole world’s going to want to develop for Gingerbread, fine. Do I think that’s going to happen? Then why is there a different environment for a tablet? And you know about the performance issues and you know about the app volume issues, cause it’s tough. And that’s why QNX matters Google’s ecosystem is fragmented, Android apps are not able to rely on competitive hardware and there is too much competition. That’s why developers should target QNX (which is unfragmented, built on fast hardware and there are few apps on it).
Is this stuff going to go more in the browser and HTML 5 and more native? These are going to be strong trends. But if you want these app players for different VMs — and don’t forget we have 25,000 BlackBerry 6 apps Browser apps will increase in value and we also have legacy BlackBerry apps.
So, at the end of the day, we believe this is going to be about performance. It’s going to be about enterprise greatness. But we believe in a future with native applications running on QNX.
Things like multi-threaded capability, symmetric multiprocessing. We believe it’s about an uncompromised web. We believe it’s about enterprise security. True multitasking, not with suspension — and that matters because you’re going to want to run these things in the background. Because QNX is a robust operating system with PC-like performance. It also supports a good browser.
But I’m out of the religious war on tonnage, which I’m delighted. However, before QNX takes off, we will provide access to catalogs of apps which are built for other platforms.