Effective October 1, 2012, QUALCOMM Incorporated completed a corporate reorganization in which the assets of certain of its businesses and groups, as well as the stock of certain of its direct and indirect subsidiaries, were contributed to Qualcomm Technologies, Inc. (QTI), a wholly-owned subsidiary of QUALCOMM Incorporated. Learn more about these changes

Show Me The (Web App Store) Money

By now, most of us are used to the idea of an application store, providing applications that make our mobile devices more useful. Typically, entire ecosystems spring up around a platform, and there are multiple examples : Apple’s App Store, the Android Market, the Palm® App Catalog for webOS, RIM’s BlackBerry App World™, and Brew™ storefronts.

The common thread among all of these is that they serve a single platform and enforce unique packaging, provisioning and security. More importantly, each provides a way for app developers to be paid for their work. The driving force behind ecosystem growth is always developer participation.

To date, web applications haven’t enjoyed the same kind of distribution and monetization opportunities as native apps, but that’s changing. The most high profile example is Google’s Chrome Web Store, focused on the nascent Chrome OS platform and Google’s Chrome browser. While I’d like to see Google’s store support more than just Chrome browsers and Chrome OS devices, it does include support for what I consider to be ecosystem must-haves:

* Packaging & Provisioning: Web applications that are delivered from a server in the same way traditional web pages are, via http, are known as hosted apps. Web apps can also have all of their content bundled together in a single package so that the application can continue to function when there’s no network connection. This is known as a packaged app.

The techniques for packaging web apps vary, but in general there needs to be at least application metadata, and manifest information. The metadata describes the app by pointing to its manifest, listing supported platforms, icons and app store requirements. This data is often curated by an app store manager entity and not generated or maintained by an app developer. The manifest contains information like the app name, version, description, URLs to launch and requested permissions. Packaging web apps enables better discoverability and matching of platform to app assets – keys to seamless device tailored user experience.

* Security and Privacy: Web sites and applications have greater potential access to personal information, local data storage and device APIs than in the past. Packaged apps can signal their need for access to features like these by listing their required permissions in the app’s manifest file.

The process of installing a packaged app will include copying application assets to the device (perhaps to a secure location) and presenting the list of requested permissions to the user. If the user agrees to all of the requested permissions, the browser and platform are then responsible for allowing access to only those APIs and data that are allowed.

We’ve seen just a taste of user granted permissions in current browsers for location access, but this grants access to all pages from a given domain, and doesn’t fit the packaged app model of requesting all needed permissions at installation. In my opinion, browsers and platforms will need fine grained permissions and will need to enforce security within an application’s logical container, between applications, and to sensitive user data and device APIs.

* Paid and Free Apps: The key to a thriving ecosystem, as Steve Ballmer, CEO of Microsoft Corp, once famously intoned, is developer participation. App stores can get off the ground and build interest with free apps, but until developers can get paid for their work, critical mass and compelling offerings don’t usually happen. The requirements to enable paid apps for web app stores are similar to those for traditional, native app stores.

First, a payment infrastructure is needed that can register customers and their payment credentials, store and access them securely, and route payments to app developers. Next, a mechanism is needed to provide user and identity verification between an application on device and the app store. As well, runtime verification is needed between the app store and running applications to provide persistent proof of purchase.

Finally, since packaged apps install resources persistently on device and can run without a network connection, some means of providing secure offline verification is needed, such as cryptographically securing application access tokens in HTML5 local storage.

While Google has just recently introduced the Chrome Web Store, and no other significant alternatives yet exist for comparison, all the important elements are there to propel web apps to distribution levels previously achievable only by native apps. Google claims that all modern browsers are supported, which bodes well for mobile platforms such as iOS and Android, both of which leverage WebKit.

For developers, the potential to reach a wide variety of mobile platforms with a single code base, while making money doing it, has been a long sought after goal. Look for competing web app stores to spring up, leveraging the momentum and emerging standards being developed today.

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries ("Qualcomm"). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.