The Cost of Building BlackBerry Apps

We have just finished two BlackBerry apps, one native and one using Rhodes Mobile. In the course of creating these apps, we have developed some processes to improve both the speed of development and the quality of the resulting product – especially when porting from Android.[1]

Despite the improvements, the BlackBerry platform and development environment have limitations that make BlackBerry development more expensive than a corresponding Android or iPhone app. Vision Mobile found that it takes twice as long for a developer to master the BlackBerry platform than it does to master the Android platform. In addition, they found that about 50% of BlackBerry developers reported that “Development is quirky or time-consuming” and that it is “Difficult to create great UIs.” In contrast, less than 20% of iPhone developers and less than 40% of Android developers expressed the same concerns. Furthermore, BlackBerry’s new tablet uses QNX instead of BlackBerry OS 6.0 which increases the time and effort needed to cover the BlackBerry market.

BlackBerry owners download much less than iPhone and Android owners. Ovum estimates that, despite its relatively small market share, 67% of all smartphone app downloads are for the iPhone. In contrast, they predict that by 2015 only 17% of all app downloads will be for BlackBerry. Nielson found that the average iPhone user has 40 apps installed, the average Android user has 25 apps installed, and the average BlackBerry user has only 14 apps installed.

This lower demand reflects both the lack of apps in BlackBerry’s App World and culture differences between BlackBerry and other smart phone users. In an interview with Digital Trends, research analyst and mobility expert Tim Doherty observes that “RIM’s heritage is in enterprise background, and the app phenomenon has come from consumer side … but this is changing.” In that same interview Carmi Levy said she “believes that the BlackBerry App World needs ‘a complete rethink’ to make it easier for users to find relevant software: ‘As it is, even the most basic search amounts to a needle in a haystack type of affair, and it often ends with the user leaving empty-handed – contrast this with Apple’s and Google’s online stores, which make it easy to find new and existing titles alike.’” The higher cost combined with the lower demand means that each development dollar spent on an BlackBerry app produces much less value than dollars spent on Android or iPhone development.

This document discusses the limitations of BlackBerry development and the potential benefits of developing a single mobile web site over developing three (or more) separate native apps.

Windows Only

First, the BlackBerry simulator runs on Windows only. This leaves those who develop best on other platforms two choices:

1. Use Windows for the BlackBerry project. Although we can use Windows efficiently, most of use are even more efficient when using Mac or Linux.
2. Write the code on the Mac, but run the simulator on Windows. Doing so requires us to push the .cod file to the Windows machine and restart the BlackBerry simulator after every compile. This takes tens of seconds, which add up to a non-trivial amount of money over the course of a project. (Vision Mobile reports that over 60% of BlackBerry developers are concerned about the start time of the simulator.)

Primitive API

The BlackBerry JVM is based on Java ME, which provides a very limited subset of the standard Java SE API. In addition, BlackBerry code must be compiled at the Java 1.3 level. This means that developers cannot utilize any of the improvements made to Java since 2002, including generics, autoboxing, reflection, and annotations. Common utilities such as java.util.ArrayList and java.util.HashMap are also not available.

The lack of autoboxing visually clutters the code and makes it more tedious and time consuming to write. The lack of generics requires developers to explicitly cast data retrieved from data structures such as Vector and Hashtable. As with autoboxing, these casts add visual clutter and are tedious to write. In addition, the resulting code is more prone to errors because incorrect casts can only be detected at run time.

The lack of annotations prevents us from using the Guice dependency injection framework. Although it is not difficult to create “factory” classes for object instantiation, they can be tedious and time-consuming to maintain. We prefer using Guice.

Clumsy API

The BlackBerry API has fewer, less sophisticated components than Android or iPhone. This lack of components leaves the customer two undesirable choices:

1. Accept an interface that looks less polished than the corresponding Android or iPhone application, or
2. spend extra money paying for the development of custom components.

The second option is particularly expensive because (in our opinion) the BlackBerry API is not as well documented as the Android and iPhone APIs. In our experience, many BlackBerry components did not behave as the documentation led us to believe they would. The BlackBerry Development Forum has many examples of developers who have solved problems by implementing subclasses of BlackBerry components. We strongly prefer composition-based design to inheritance-based design because inheritance-based designs can be fragile and difficult to test. In particular, inheritance-based designs are especially fragile when inheriting from poorly documented classes.[2]

The clumsy API requires more compile-execute cycles to get the app to look good. These extra cycles are particularly expensive given the need to restart the simulator.

Conclusion

The slower, more expensive development process combined with the lower “marketing” value of the completed app means that, in most cases, a BlackBerry app delivers less value per development dollar than a similarly featured iPhone or Android app.

We get the impression that, even though the value of a BlackBerry app is relatively low, businesses developing a mobile presence hesitate to alienate their BlackBerry using customers. We recommend that businesses seriously consider building a mobile web site instead of a set of native apps. The majority of apps we have built and used could have just effectively been developed as mobile web pages. Mobile web pages look just as good and are no more difficult to develop than a native app, but are more easily maintained and ported. Thus, instead of spending $85,000 on three mobile apps ($25,000 each for iPhone and Android, and $35,000 for BlackBerry), a company could spend $50,000 ($25,000 for the first mobile web page and $12,500 each to port it to the other two platforms). Consequently, the business covers all three major platforms, and saves money.

Our goal is not to simply do whatever the customer asks; but to help him or her discover the best and most cost effective solution. In most cases, we believe that a native BlackBerry app is not the best solution; however, in the rare case that it is, we are ready and well-prepared to help.

² We speculate that the BlackBerry API was originally designed for internal use only. As an internal library, the risks of inheritance-based design and the costs of minimal documentation can be more easily managed. (However, we still prefer composition-based design and good documentation – even for internal projects.)