Last
Wednesday, BlackBerry made the transition from being a company that was
developing a new smartphone platform to a company that actually has a
smartphone platform out in the market. The game has now changed.
We know that BlackBerry 10 launched with an BlackBerry World catalogue that was 70,000 apps strong. That catalogue has some problems -- most notably that apps are of a certain relatively low quality and utility, and that virtually all of hero apps that contribute significantly to the dominant platforms (iOS and Android) are missing.
There's also a perception that the catalogue is very "Android heavy". BlackBerry 10, like PlayBook before it, has an "Android Player". This is a runtime that allows Android apps to run on BlackBerry 10 as if they're normal application. In fact, as of the time of writing only 17 percent of the catalogue are repackaged Android apps. At the current run rate where they're adding about a thousand apps per day, that suggests about 13,000-odd of the apps in the catalogue are actually Android apps.
Notionally, this is fine. An app is an app, and as a user if I like an app I'm not sure if I care too much whether it's a full-blown BlackBerry 10 app or an Android app. But it does create a problem for BlackBerry.
Conversion
The actual process of moving an Android app onto BlackBerry 10 (and PlayBook, incidentally) isn't so much "conversion" as "re-packaging".
BlackBerry provides tools to do this and the process is very easy.
Over the past two years whilst BlackBerry has been rebooting, the company has put a staggering amount of effort into schmoozing developers into developing apps for the platform.
What I hadn't realised was how popular the BlackBerry apps ecosystem was before BlackBerry 10. Each quarter BlackBerry currently adds between 10,000 and 15,000 new apps to the BlackBerry World catalogue just for old school BlackBerry OS 7 devices. We can add to this the fact that a good number of larger, old school BlackBerry shops developed in-house, "behind the firewall" apps to expose internal systems data on BlackBerry handsets. What this suggests is that when BlackBerry reached out to its developer community and started talking about the new BlackBerry 10 they had a lot of goodwill to draw upon. Not diminishing what they managed to do in terms of building a huge app catalogue at launch, just like BlackBerry has now gone from being a business with a platform under development to one with a platform in the market, that story may well be changing as they now have to "on-board" software developers who don't have prior investment in BlackBerry.
If you're a software developer, if you take a very high-level view of the market, we know that in terms of smartphone sales in the US iOS and Android account for a little over 95 percent of smartphone sales. A "first principles" view suggests that if you have "x" amount of dollars to spend on development, hitting both iOS and Android covers almost all of your potential market. Of course, you may know something about your customer base that's not expressed in this blunt "95 percent" figure, but let's just assume you've nothing weird going on.
When it comes to BlackBerry, we're talking about the third ecosystem. Microsoft is also competing for this space for Windows Phone. Remember, in the US at least the sliver of market share left for a third ecosystem is currently just five percent of the market. Of course, this sliver might get relatively bigger over time.
The rather odd situation BlackBerry now finds itself in is with regards to the Android Player. Say you have an app that does rather well on iOS and Android and the third ecosystem is starting to push demand up from your customer base. If that third ecosystem is Windows Phone to satisfy that demand you have to rebuild your app as you can't just take the source code used to build the iOS and/or Android apps and cross-compile it for Windows Phone. If that third ecosystem is BlackBerry 10, all you have to repackage your Android app and submit it to BlackBerry World. Assuming it works first time, that job that could take about ten minutes.
The only problem is that BlackBerry don't want you to do that.
Experience
Like Microsoft, BlackBerry has a vision with regards to the user experience that they want their smartphone users to enjoy. On BlackBerry this is things like BlackBerry Peek (the gesture where you can see incoming notifications, emails etc) and BlackBerry Flow. Flow is a little more wooly -- it's the idea that rather than, as per iOS, you dip in and out of siloed apps you can zip around smoothly without really being aware of flowing around between different apps from different vendors.
The problem is that unless you build a native app for BlackBerry 10, ideally using the Cascades framework you don't get any of that new user experience stuff. An Android app ported to BlackBerry 10 is just a siloed app just like it might be on Android or iOS. However, that's more of a problem for BlackBerry than it is for the users. There's little evidence that a top-down user experience that permeates the entire OS delivers much value to the user. This sort of approach is a solution created by platform vendors seeking a problem. (Interestingly Microsoft does this both on Windows Phone and Windows 8/Windows RT, but iOS and Android don't do this -- yet those two enjoy 95 percent market share figure?)
On iOS, if you build a native app you use Objective-C. On Android you use Java. On BlackBerry 10, you use C/C++. (For reference, on Windows Phone, you use C#.) This is the classic cross-platform engineering problem of mobility -- you can't take code from any one platform that you develop for and just cross-compile it over to another platform. Hitting multiple platforms requires distinct, costly development effort both in terms of initial cost, and in terms of ongoing costs.
I tend to regard multiple platform support as the biggest problem faced by software companies targeting mobile platforms. It's simply a massive unfathomable mess of risk and cost. Insanely, the presence of Android Player on BlackBerry 10 in one fell swoop solves the problem. If you're already invested in Android, or you want to invest in Android, you essentially get BlackBerry 10 for free.
That's great for you, but bad for BlackBerry if they wish to remain true to their vision of pushing the user experience in BlackBerry 10. For the record, they like people coming over to BlackBerry World using the Android Player track, but they see it as a "toe in the water" exercise with the desire to see the vendor create a proper, ported, app that takes advantage of everything the platform has to offer. But being able to use Android Player in this way it's not a "toe in the water". It's a nice, relaxing, warm bubble bath with candles and soft music.
Whereas I can see that software developers with an pre-existing investment in BlackBerry will want to do a native version of the app and push through the BlackBerry 10 user experience vision, I can't see that with commodity developers who are simply ticking a box to keep what by definition in most cases has to be a relatively small subset of the customer base happy.
BlackBerry's intention is that they'll incentivise developers to produce apps that are "Built for BlackBerry". You'll be familiar with this idea -- adhere to certain rules and your app will gain certification. Over time, BlackBerry intends to shift to a position where they're only giving the big love to apps that are "Built for BlackBerry". (For example, eventually only apps that are "Built for BlackBerry" will appear on the BlackBerry World carousel.) And, of course, if all you've done is just moved an app over from Android, you don't get to be certified and hence don't get the big love.
Conclusion
This is a slightly tricky position for BlackBerry. The Android Player could be the silver bullet against Windows Phone by -- from the perspective of a software developer -- essentially turning BlackBerry 10 into an additional Android variant. Developers that target Android are already having to deal with fragmentation -- BlackBerry 10 is just another dimension to that fragmentation. By being able to lift Android apps directly over to BlackBerry 10 developers avoid any requirement to re-engineer their apps. On Windows Phone this re-engineering is unavoidable, adding significant additional cost to targeting that platform.
Remember that "17 percent Android apps in the catalogue" figure from earlier? I wouldn't be surprised if the majority of apps for BlackBerry 10 were Android apps as we get to the end of 2013. And I can't see how that's a problem -- the software developers would be happy, the users would be happy, and BlackBerry World's catalogue increases in utility.
We know that BlackBerry 10 launched with an BlackBerry World catalogue that was 70,000 apps strong. That catalogue has some problems -- most notably that apps are of a certain relatively low quality and utility, and that virtually all of hero apps that contribute significantly to the dominant platforms (iOS and Android) are missing.
There's also a perception that the catalogue is very "Android heavy". BlackBerry 10, like PlayBook before it, has an "Android Player". This is a runtime that allows Android apps to run on BlackBerry 10 as if they're normal application. In fact, as of the time of writing only 17 percent of the catalogue are repackaged Android apps. At the current run rate where they're adding about a thousand apps per day, that suggests about 13,000-odd of the apps in the catalogue are actually Android apps.
Notionally, this is fine. An app is an app, and as a user if I like an app I'm not sure if I care too much whether it's a full-blown BlackBerry 10 app or an Android app. But it does create a problem for BlackBerry.
Conversion
The actual process of moving an Android app onto BlackBerry 10 (and PlayBook, incidentally) isn't so much "conversion" as "re-packaging".
Over the past two years whilst BlackBerry has been rebooting, the company has put a staggering amount of effort into schmoozing developers into developing apps for the platform.
What I hadn't realised was how popular the BlackBerry apps ecosystem was before BlackBerry 10. Each quarter BlackBerry currently adds between 10,000 and 15,000 new apps to the BlackBerry World catalogue just for old school BlackBerry OS 7 devices. We can add to this the fact that a good number of larger, old school BlackBerry shops developed in-house, "behind the firewall" apps to expose internal systems data on BlackBerry handsets. What this suggests is that when BlackBerry reached out to its developer community and started talking about the new BlackBerry 10 they had a lot of goodwill to draw upon. Not diminishing what they managed to do in terms of building a huge app catalogue at launch, just like BlackBerry has now gone from being a business with a platform under development to one with a platform in the market, that story may well be changing as they now have to "on-board" software developers who don't have prior investment in BlackBerry.
If you're a software developer, if you take a very high-level view of the market, we know that in terms of smartphone sales in the US iOS and Android account for a little over 95 percent of smartphone sales. A "first principles" view suggests that if you have "x" amount of dollars to spend on development, hitting both iOS and Android covers almost all of your potential market. Of course, you may know something about your customer base that's not expressed in this blunt "95 percent" figure, but let's just assume you've nothing weird going on.
When it comes to BlackBerry, we're talking about the third ecosystem. Microsoft is also competing for this space for Windows Phone. Remember, in the US at least the sliver of market share left for a third ecosystem is currently just five percent of the market. Of course, this sliver might get relatively bigger over time.
The rather odd situation BlackBerry now finds itself in is with regards to the Android Player. Say you have an app that does rather well on iOS and Android and the third ecosystem is starting to push demand up from your customer base. If that third ecosystem is Windows Phone to satisfy that demand you have to rebuild your app as you can't just take the source code used to build the iOS and/or Android apps and cross-compile it for Windows Phone. If that third ecosystem is BlackBerry 10, all you have to repackage your Android app and submit it to BlackBerry World. Assuming it works first time, that job that could take about ten minutes.
The only problem is that BlackBerry don't want you to do that.
Experience
Like Microsoft, BlackBerry has a vision with regards to the user experience that they want their smartphone users to enjoy. On BlackBerry this is things like BlackBerry Peek (the gesture where you can see incoming notifications, emails etc) and BlackBerry Flow. Flow is a little more wooly -- it's the idea that rather than, as per iOS, you dip in and out of siloed apps you can zip around smoothly without really being aware of flowing around between different apps from different vendors.
The problem is that unless you build a native app for BlackBerry 10, ideally using the Cascades framework you don't get any of that new user experience stuff. An Android app ported to BlackBerry 10 is just a siloed app just like it might be on Android or iOS. However, that's more of a problem for BlackBerry than it is for the users. There's little evidence that a top-down user experience that permeates the entire OS delivers much value to the user. This sort of approach is a solution created by platform vendors seeking a problem. (Interestingly Microsoft does this both on Windows Phone and Windows 8/Windows RT, but iOS and Android don't do this -- yet those two enjoy 95 percent market share figure?)
On iOS, if you build a native app you use Objective-C. On Android you use Java. On BlackBerry 10, you use C/C++. (For reference, on Windows Phone, you use C#.) This is the classic cross-platform engineering problem of mobility -- you can't take code from any one platform that you develop for and just cross-compile it over to another platform. Hitting multiple platforms requires distinct, costly development effort both in terms of initial cost, and in terms of ongoing costs.
I tend to regard multiple platform support as the biggest problem faced by software companies targeting mobile platforms. It's simply a massive unfathomable mess of risk and cost. Insanely, the presence of Android Player on BlackBerry 10 in one fell swoop solves the problem. If you're already invested in Android, or you want to invest in Android, you essentially get BlackBerry 10 for free.
That's great for you, but bad for BlackBerry if they wish to remain true to their vision of pushing the user experience in BlackBerry 10. For the record, they like people coming over to BlackBerry World using the Android Player track, but they see it as a "toe in the water" exercise with the desire to see the vendor create a proper, ported, app that takes advantage of everything the platform has to offer. But being able to use Android Player in this way it's not a "toe in the water". It's a nice, relaxing, warm bubble bath with candles and soft music.
Whereas I can see that software developers with an pre-existing investment in BlackBerry will want to do a native version of the app and push through the BlackBerry 10 user experience vision, I can't see that with commodity developers who are simply ticking a box to keep what by definition in most cases has to be a relatively small subset of the customer base happy.
BlackBerry's intention is that they'll incentivise developers to produce apps that are "Built for BlackBerry". You'll be familiar with this idea -- adhere to certain rules and your app will gain certification. Over time, BlackBerry intends to shift to a position where they're only giving the big love to apps that are "Built for BlackBerry". (For example, eventually only apps that are "Built for BlackBerry" will appear on the BlackBerry World carousel.) And, of course, if all you've done is just moved an app over from Android, you don't get to be certified and hence don't get the big love.
Conclusion
This is a slightly tricky position for BlackBerry. The Android Player could be the silver bullet against Windows Phone by -- from the perspective of a software developer -- essentially turning BlackBerry 10 into an additional Android variant. Developers that target Android are already having to deal with fragmentation -- BlackBerry 10 is just another dimension to that fragmentation. By being able to lift Android apps directly over to BlackBerry 10 developers avoid any requirement to re-engineer their apps. On Windows Phone this re-engineering is unavoidable, adding significant additional cost to targeting that platform.
Remember that "17 percent Android apps in the catalogue" figure from earlier? I wouldn't be surprised if the majority of apps for BlackBerry 10 were Android apps as we get to the end of 2013. And I can't see how that's a problem -- the software developers would be happy, the users would be happy, and BlackBerry World's catalogue increases in utility.
No comments:
Post a Comment