Forgot your password?

Update: RIM Needs to Provide Guidance on Super Apps, BBM SDK

Update: Mea Culpa. Below is the final copy of Chris’s article that is now correctly updated.
He wrote the draft we posted earlier today before we mentioned the slides from MWC. He then updated the article and I accidentally published his older draft. Sorry for the confusion. -RH

Platform Roadmap

You wouldn’t know it from reading the mainstream media but the BlackBerry platform has a number of competitive advantages that remain unmatched by the competition.

One of them is the Super Apps API through which BlackBerry apps can integrate richly with the user’s data and native applications on the device – anything from memos, messages, calendar and tasks to call logs, notifications and LED controls and even things like Facebook and Twitter messages getting embedded in the Messages app. Good luck doing that with Android or iOS (have you tried writing code to access something as simple as the Calendar on Android??! Anyways, I digress…).

Lots of apps like my high-end productivity apps Viira and the Viira Outlook Suite leverage the Super Apps API to create a rich experience that cannot be created outside the BlackBerry platform. By integrating with the user’s phone’s data and native applications or data stores in a secure, trusted way an app is no longer just an app but an integral and engaging part of the user’s day-to-day experience. And that’s a good thing. It’s a good thing for both developers who can make lots of new product ideas possible. It’s also a good thing for users who enjoy new capabilities on their devices.

There is only one problem though. As of BlackBerry 10 support for the Super Apps API will be cut down to a fraction of its former self, in a way that’s not very usable or practical to the majority of current BlackBerry developers (outside of games and themes).

According to released slides RIM plans on cutting down the Super Apps API to just HTML5 and TAT (according to this slide). So right now core BlackBerry developers who have been coding in Java have a number of equally unappealing choices.

Either web-iffy their apps (hello time lags and cheap-looking web UI) or port them to C++ (yikes!) and start relying on a new, as-of-yet unreleased UI framework with an unproven track record (beyond a few amazing looking demos). And with Android’s Super Apps API severely lacking in comparison to BlackBerry’s, current developers are staring at a number of equally unappealing alternatives.

In reality most app developers just won’t bother or have the time. So come BlackBerry 10 time many existing apps just won’t get ported, not in time for the launch anyways. And watch the visceral media have a field day with that. Lo and behold, the number of apps on BlackBerry is actually decreasing!

Now, I have been in the BlackBerry system for a long time and know that RIM is excellent at supporting the development community. But RIM needs to step in here and provide a technical migration path because most current developers are scratching their heads looking at the migration paths presented to them.

So let’s be constructive here. Here are some of the things that I think RIM can do:

  1. Provide a Java player in BB 10 to alleviate the migration pressure. This will just buy time but save some tense moments with the developer community and the media.
  2. Hack Android Extensions to provide Super Apps with the Android runtime somehow (messy!)
  3. (What every current developer would like to see): Provide a Java runtime with a Cascades UI environment. Ideally, make a dual RIM UI/TAT UI environment just like we now have a RIM UI/J2ME UI environment. This way existing apps can run without a problem on BB 10 (migration pain solved!) but new ones can take advantage of Cascades or on a per-OS build basis.

I don’t think 3) is that hard to pull off technically. RIM has plenty of time to execute on that – and even roll out a little beta program mid-summer to give developers a taste of what’s to come.But something needs to be done and waiting is not an option that is sitting well with the developer community at this point.

11 total comments on this postSubmit your comment!
  1. First of all, I think the author considerably underestimates the time, people, and general ressources necessary to push out a SuperApp API for Android that only works on BB10/PB2.0 devices. Practically, it would mean pushing back other more important objectives.

    If you want perfect portability, develop in HTML5 for use with Apple, Android, Vita, Gecko, Bada, Windows, Linux, etc…

    If you want perfect performance and integration, develop using the native C/C++ (TAT isn’t a platform, Cascades is the GUI/animation API. QNX/BB10/PB2.0 is the platform)

    So a SuperApps API for Android, lets ignore the cost of pushing back other objectives for a moment. It only works on BB devices, and does not substitute for any existing Android APIs. So anyone using it is already developing specifically for BB. And the SuperApps Android API won’t be as good because it might lag the native API in updates if for no other reason than testing it with new Android builds as well, perhaps lack certain features due to security restrictions, maybe miss other features relating to background processes from a single android emulator, and carry a higher hardware overhead which results in slower performance. Maybe it makes it easier on you if you only know Java, and not very well presumably because you don’t know other languages. So is making it easier for a small number of developers, who are developing for a small set of use cases worth pushing back other milestones? Probably not. Any such support would come long after the release of BB10, because there is plenty of more important work for at least a couple years before the platform reaches maturity.

    There already exists a good path of least resistance if you have an application in mind. If it is too difficult, perhaps explain where you are personally coming from because there might be suggestions I could offer you individually instead of viewing this as a general problem.

  2. I think what’s missed in this article is that Cascades is built on top of Qt, and will be supporting Qt Quick. Devs won’t have to migrate to C++ to write Cascades apps, they can do it in JavaScript + QML with Qt Quick. I think that is quite a reasonable migration path with enough similarities to technologies devs already know.

    HTML5 shouldn’t be dismissed either. Using frameworks like Sencha Touch it’s possible to deliver quite nice UIs that are fluid and responsive. Users would be unlikely to ever suspect they’re not native apps.

    Trying to bring Java to BB10 would be yet another development platform to support. I’d much rather have quality over quantity there, I already question the Android player.

    I also think the technical difficulty of pulling off #3 has been understated. Making Cascades work nicely with Java is likely to be anything but simple, making it work with J2ME UI would be even more difficult. J2ME also isn’t a great UI toolkit to be working with. Forcing devs to re-write with Cascades may cause some pain, but the user experience will be much better.

    • I don’t think it would be too difficult to make any backend work with Cascades as I think they communicate via asynchronous messages, but yes, that would still mean rewriting some controllers.

  3. “cheap-looking web UI”
    Because BlackBerry apps usually look amazing? Most apps, including super apps look pretty basic on a BlackBerry, even the ones included by RIM. Nothing HTML5 can’t handle.

  4. Good points, Taylor and George. But you shouldn’t overestimate the effort and time that many BlackBerry devs are willing to invest to port their existing apps to BB10 though, especially in time for the launch.

    It’s a totally business argument really, and one of opportunity costs.

    If all we have in terms of options coming from RIM is a complete re-write of our existing apps for BB10 in C++(or Javascript or whatever), why not invest the time to re-write them in Objective C and be on iOS instead? It will take roughly the same time more or less. Or better yet, keep Java and be on Android? At least at the end of the day we will be on platforms with hundreds of millions of users. Current users on BB10 : 0.

    See what I mean?

    We app developers are also business owners and part of making a living from selling apps is making sure we invest our time where ROI makes sense. And spending months tinkering with new cool libraries and re-writing existing functionality, fun as it may be, is not the kind of thing that brings home the bacon.

    So many existing developers will silently shrug off, maybe grumble a bit then make a pass on the BB10 launch and adopt a wait-and-see attitude at best. And come BB10 launch time, everyone will be asking “but where are those apps that I had on my old BlackBerry??”

    And the media will have a field day with this. “Oh my, RIM can’t even convince _current_ developers to continue BlackBerry development”

  5. I don’t think there is a compelling app originally made for BB7 and earlier that is trapped in Java.

    Aiming for backwards compatibility adds significant costs and introduces sacrifices to the final product. (assuming legal licensing isn’t an issue, which it is for Google right now)

    C++ & Qt is really easy and nice to develop for, and probably the easiest programming-GUI combo for the last 5 years. I think Java works better for large teams, but that’s a bit beyond smartphone level apps.

    As for choosing which platforms to develop for…
    A lot of developers are multi-platform, and the most compelling apps definitely are.

    Why not iOS/Objective C?
    You must develop using XCode on a Mac. ObjC is similar to C++ so learning isn’t a big problem but there are quirks.

    Why not Android?
    They are the easiest platform to get into. However the Android ecosystem has a piracy problem where you need to sell ads or subscription content to find success.
    Also, Google will bring in GO and a new VM or something in the next few years. Sure there could be a compatibility bridge or translator, but you won’t be able to stick with Java forever.

    Why not WindowsPhone?
    C# ducks, it’s an annoying inferior imitation of Java. You have to use VisualStudio on Windows.

    Mostly the breakdown so far has been an argument against choosing a single platform. Convergence is happening, for most cases, there is no reason not to as the hardware and usages become standard for most cases as well.

    Why BB10?
    You can develop on whatever you want, with premier support for Eclipse and it’s plugins. A lot of people have worked with C++ and Qt. It will be the easiest migration for former Symbian developers. Anyone who has developed for KDE, Windows, Mac using Qt will find it easy. For now, until RIM releases SuperApps API and Cascades Framework, go on YouTube and look at Qt tutorials. One REALLY nice feature is the ability to specify the UI in a simple text file that a designer can manage, while leaving the programming separate to the programmers (who can be using Git or whatever versioning system they’re used to under Eclipse)

    I understand some fear or uncertainty, but I don’t see the big problem. That will last until time has passed and the tools are available to play with. What I don’t understand is this article… It’s a surreptitious call for RIM to make BB10 compatible with BB7, pretending to have some relevance to the platform/framework/api roadmap. I don’t think that issue can be revived anymore. Furthermore it is confusing those who have a loose understanding of what all these parts do.

  6. As for investing the time for an app that existed on BB5/6/7, if it’s not worth your time to port it then it might not be worth anyone else’s time either.

    If it’s a good app, with a lot of time behind it, you should want to focus on laying deep roots by trying to be #1 in every single market (country, OS, features, integration with other services) available instead of devoting a minimal amount to of time to a new app.

    If it’s a simple app without much time behind it, then they don’t need to worry about it. Port an existing Qt, Symbian, Android, HTML5 app. Build a new one, not even from scratch, just replicate or improve on what’s been done.

    Sorry, but I would rather see a no compromise release ASAP. I don’t see the BB5/6/7 installed apps as being the most important thing. That’s the new featurephone market, and HTML5 will be good enough for cross platform continuity. The full API may not be there yet, but neither is it for the native C++ either.

  7. George, don’t get me wrong. I am sure there will be some nice and shiny tools and ways to develop for C++/Qt/Cascades whenever those tools do get released. Every major platform has the requisite tools nowadays anyways.

    The point of is, RIM has a big hole in the Super Apps and BBM SDK roadmap. And let’s not kid ourselves here, HTML5 ain’t gonna fill it.

    What we have right now is a leaked powerpoint slide (that’s all it is now, a powerpoint slide) with no additional technical information or commitments.

    I stand by the point of this article: more is needed.

    For example, a legitimate developer question at this point is “how complete will the Super Apps api even be in C++/Cascades?”. Looks good on the power point, I’ll give it that. But so did WebWorks and it lagged behind the Java SuperApps API for years.

    (btw, if you are trying to tell me that C# sucks and C++ is the way to go, I am not buying what you are selling!!! 🙂

  8. Thanks for the replies Chris, I feel like we’re approaching a common understanding. Before going any further, I want to let you know I’m getting on board with BB as of the Playbook — I’m not losing anything missing the backwards compatibility, and there’s nothing I don’t think is better served by recreating instead of virtualizing a J2ME environment.

    I too am impatient for the SuperApps APIs. The native C++ ones. The ones being developed in tandem with core applications and in-house frameworks. Until those are done, there is no way to provide APIs for WebWorks, or any other mode like a BBOS7 Player. Including a BBOS7 Player would not speed anything up, and it would definitely slow something down. Including the SuperApps APIs just to support the BBOS7 player on new devices would slow the development of all APIs down.

    At best the support would come at the same time it were released for WebWorks, and at worst they would both be pushed back because two distinct APIs would have to be supported.

    That’s why I think your post was a false argument or a misconception

    I would be surprised if the APIs, even for c++, were complete at launch. I do hope and have some reason to anticipate that new releases will be more regular, and carry greater benefits.

    Continuing J2ME support onto the new devices would slow everything down. Speed is important, and they need to be able to focus to pull of their strategy. WebWorks = compatibility. C++/Qt/Cascades = Performance and Integration. Finish those ASAP, they’re about 1.5 years into a 4 year process of establishing a new platform.

    Right now RIM needs to clear what’s on their desks and get the core applications and APIs out there. There is enough important work to last at least two more years before they should be taking on side projects. WebWorks needn’t be captive to Java-/ECMAscript, maybe Python or maybe Google’s DART will be making inroads by then. And no matter what happens in the world economy, what passes for a flagship phone in the USA today will be dominant globally in maybe a few more years — those factories have to keep churning out product while they exist, at just about whatever price it takes to sell them all.

    As for C#? It’s not just me. It wouldn’t exist at all if Microsoft didn’t force it in some circumstances, and throw money at hiding its shortcomings in others.

    The C/C++ realm has a lot more work, an abundance of supporting ressources, and the talent pool is very rich. Java is important, but for the enterprise and that benefit doesn’t translate well to a personal mobile device. Meanwhile there are very real concerns about Java under Oracle’s stewardship among everyone outside of Oracle and its customers. C/C++ is the best way to go for now and the foreseeable future

  9. Finish those ASAP, they’re about 1.5 years into a 4 year process of establishing a new platform.

    Actually, I would like to change platform to ecosystem in that sentence. QNX before acquisition was very much a legitimate platform, the goal now is to make it an ecosystem whereby its easier to join it than to go around it.

  10. OK, point about building and establishing a new platform/ecosystem is taken. I mean, your entire argument makes perfect sense – but from a *RIM* standpoint. And I fully follow, logically speaking, every step of the reasoning.

    But I am presenting the point of view from the perspective and reality of an independent developer here. Not someone who is on the payroll of a BigCo somewhere but someone who owns or works in a small dev shop.

    And this is where things are not lining up.

    And by the way, dismissing the needs of independent developers would not be a smart move on RIM’s part – the majority of apps in App World are made by small indie/ISV shops. Without the indie guys forget about ever reaching the 1 – 200,000 app mark, let alone the million app mark.

    And Super Apps/BBM SDK was a core and continues to be a core attraction to many developers as it is a key differentiator of the platform. This is one place where BlackBerry is miles ahead of the competition. As it stands right now we have a number of partial migration paths, some guesswork as to if the full SuperApps feature set at launch is going to address the needs of our apps and a doze of implied “trust me, its going to be good. eventually.” Not an ideal scenario.

    What I ultimately don’t get is this. Given that RIM has the brainpower and engineering resources to came up with an Android player in relatively short time after the QNX acquisition and PB 1.0 launch, why isn’t something like a BB OS7 player for BB10 on the table? I mean, Android is an “external” code base and technology and not something developped and nurtured internally like BB OS7 was, so making a BB OS7 player should be way less costly to pull off, resource-wise.

    RIM doesn’t have to support the BB OS7 player indefinitely either. Just make it loud and clear that it is intended to be used as a crutch and a crutch only while developers digest, port to and get more experience with the richness and wonderfulness of the new BB 10 platform. No new API features in the BB OS7 player going forward are needed. And feel free to end-of-life it by the end of 2013 if you will.

    I think this would be smart, practical move. You have all the existing BlackBerry apps right at launch time, SuperApps and all. You get smooth transition, noone is displeased or grumbling at launch and people can focus on the positive aspects of BB10 and not on what’s missing.

    It won’t cost that much to make – you have the code and expertise internally. And there is plenty of time to make it happen. And hey, wasn’t QNX supposed to be great for “adding in” things that are player/plugin-architectured anyways? 😉

    Speaking of cost, If you count the PR/marketing and lost/defferred sales cost of explaining to everyone come BB10 launch time – potential consumers as well as the nosy media – why apps in BB6 and 7 are not in BB10, doing the player may well turn out to be a screaming bargain.

    Somehow I have a feeling that those people won’t buy the entire “but C++ is so much cooler!” argument…

    Anyways, just my two cents.

1 pingback on this post

BlackBerry© is a registered Trademark of BlackBerry Limited. BerryReview is in no way affiliated with BlackBerry Limited though sometimes their lawyers send us love letters...

Copyright © 2007-‘2018’ BerryReview LLC