The question of apps vs the mobile web is still often poised. This contraposition blurs much more important distinctions that will determine the future of mobile content, applications and the mobile web itself.
The ability to use web technologies to create mobile apps has led to a much broader base of developers, and as such, apps now available to end-users. The use of web technologies also makes it easier to leverage and repackage existing data and content from the web. Powered by better performing underlying mobile browsers, a thriving mobile app and mobile web ecosystem has emerged. However, it should not be a foregone conclusion that “apps” will necessarily simply become rich mobile web sites. To the developer, in the near future, apps will essentially be rich mobile web sites (thanks to HTML5) packaged for distribution in a vending environment such as the App Store. To the end-user, the concept of buying things from online stores and the simplicity of having “icons” associated with content and / or functionality – even if they end up merely being links – will remain meaningful for the foreseeable future.
In addition to the power of mobility (personal, localized, always-on and ever-present), the mobile ecosystem has brought a robust economic engine to complement the ad-supported Internet: micro-payments and premium apps & content. The “app store” (and its predecessors such as AT&T’s malls, Sprints vending machine, Verizon’s “software store in your hand”, aka Get It Now) provides a way to package and distribute content in a format in which users are willing to pay.
Five years ago, “native” apps clearly provided a better, more responsive interface and were able to provide more optimal performance (e.g., minimize network latencies, cache data, preload content) and UI capabilities that led to an overall better user experience. Now, only very niche apps require the type of access to on-phone capabilities not accessible by the browser.
For example, a great number of iPhone apps are actually browser-based “sites” that have been packaged as an app that can be distributed via the Apple App Store. Arguably, two important factors have contributed to the success of the App Store are the frictionless distribution and by providing ease of development.
Frictionless Distribution: Apple removed the friction of getting apps in front of end-users by accelerating and automating the submission process, offering favorable economic terms for developers and providing great on-phone and PC-based app discovery.
Ease of Development: Initially there were some hurdles in developing iPhone apps including (i) the fact that most early developers for the iPhone were new to mobile, (ii) they had to contend with a new operating system, and (iii) had to learn an unfamiliar programming language (Objective-C), However, unlike mobile network operators (MNOs), Apple has a long history of knowing how to create a strong set of APIs, provide robust development environments and support developers in general. Further, by enabling access to the browser capabilities (e.g., Javascript, CSS, HTML) on the iPhone, Apple has made it easier to develop apps and significantly increase the number of possible “app” developers, i.e., there are many more “web developers” than programmers (C/C++, Java).
Of course, if the iPhone didn’t provide a good overall experience and the Apple didn’t take full control of the total experience (i.e., vertically integrate the entire supply chain), the wide development ecosystem would not matter. Clearly, Apple also did a much better job educating consumers than MNOs had so far about the value of apps, e.g., what apps are, what users can do with them, the fact that most are free and how easy it is to get them.
Although Apple’s App Store has created the app store frenzy, it is not due to the fact that it is an open, off-deck distribution vehicle. As Jack Seid noted, “The most cynical in the industry may actually say the iPhone App Store is not truly “off-deck,” it’s just a different deck. As such, it is worth going through the current MNO responses to the App Store. The various approaches of providers are starting to become more apparent.
Sprint
Sprint’s approach consists of a two-pronged offering:
- For feature phones, consumers will continue to get apps from the “carrier deck” albeit significantly augmented by the GetJar catalog. (accessible via search from the Sprint deck). GetJar is a large off-deck app store with over 50,000 apps. The deck itself will likely be run by a 3rd party given the RFP that was announced at Sprint’s developer conference.
- For smartphones, the user will have access to each respective smartphone app store, e.g., Android Market, Blackberry App World, Windows Marketplace, etc. Sprint will be phasing out Windows and Blackberry apps from their catalog / deck.
Russ McGuire summarized Sprint’s approach in his blog by starting that Sprint’s goal is to enable innovation to happen more rapidly and, as such removing any bottlenecks between developers and customers. They basically want to get out of the way and will not try to dictate how innovation will happen.
What is apparent is that importance of the 1-click interface and phone top services (e.g., enabled by uiONE) are being diminished. As with the other MNOs, the category of messaging centric devices that have querty keyboards is a rapidly growing segment. The question is whether these consumers will (1) want apps, and (2) which OS will win for this category. If it is Android, then users will get apps from the Android Market. If it is BREW, then users will get Java apps (running on BREW as they do today on Sprint) via the Sprint deck.
AT&T
AT&T received a lot of press from their announcements during a developer event at CES in January. AT&T’s app strategy is being touted as an apps to all approach and consists of the following offerings:
- For smartphones, you will be able to buy apps from the Android Market, Palm, Windows, and Nokia’s Ovi and have the billing go directly on your phone, i.e., off-deck content discovery with on-deck billing.
- For their mid-range, integrated devices called “quick messaging devices” (messaging devices with at minimum a full querty keyboard and a web browser), they have announced that they will be support BREW. This likely means that Qualcomm’s Plaza will be the app store for quick messaging devices (QMDs) and other BREW-based devices.
- For feature phones, it remains a bit unclear what will ultimately happen. For the foreseeable future, the Media Mall will clearly continue to offer Java apps. And, the AT&T SDK is reported to continue to support Java – whether this will ultimately be running on BREW or on other proprietary operating systems remains to be seen. And, whether Qualcomm will be serving both BREW and Java apps on AT&T will be an interesting development to watch.
AT&T clearly sees QMDs as an important, rapidly growing category. Chris Golvin from Forrester estimated that “nearly one in every three US adult mobile phone subscribers now has either a smartphone or a QMD, up from one in five less than a year earlier.” As noted above, it is yet to be seen whether quick-messaging device users will buy apps. In some sense, the pieces are in place: the devices are plenty capable and the users will be required to have data plans.
Verizon
Verizon seems to have been the first to announce their smartphone app strategy, with an initial focus on quality not quantity.
- For smartphones, Verizon will ship the Vcast app store starting with the Blackberry, likely followed by Windows Mobile. Originally, the goal was to have a store launched in Q4 2009.
- For non-smartphones such as their 3G multimedia phones, the roadmap for the Vcast app store is less apparent. For years, Verizon via its Get It Now BREW-based store has been the dominant provider of games and apps in the U.S. How and when Verizon supports Java and whether it is a replacement or in addition to BREW has not been announced.
Verizon is also part of JIL (also includes Softbank, China Mobile and Vodafone – jointly representing one billion mobile consumers worldwide), whose aim is to provide standards for app and content development to make it easier for developers to create and distribute apps on their respective networks.
Final Notes
While the competition between Apple and Google in mobile has received a fair amount of press, there is an emerging battle between Qualcomm and Google to be the predominant operating system for messaging devices (e.g., QMD, 3G multimedia phones). Arguably, this could be a much larger market worldwide than the smartphone segment.
A likely factor in AT&T’s adoption of BREW was that it is now available for free and ships on the Qualcomm chipsets. BREW has always been more than a middleware runtime environment and in fact can be thought of as a full operating system.
Clearly, both operating systems have rich development environments and are fully capable of supporting apps. The question is whether non-smartphone users will purchase and / or download and use apps on their phones in a meaningful way.
I would also be remiss in not acknowledging the announcement this week of the Wholesale Applications Community. Clearly MNOs got the message: it is hard and difficult to build and distribute apps that will run on a majority of the mobile phones. I view the announcement as more of an aspiration than a coherent ecosystem. If their vision is realized, there will essentially be a common set of methods for developing apps in which the operator will commit to supporting (likely to ultimately be based on web technologies like Javascript, CSS, etc.). And, the result will likely be a big catalog that all the operators can draw upon and market within their own branded app stores, ala Sprints approach with GetJar.