Apps Program Software Architecture
- Provide Developers with:
- a consistent App runtime environment that makes their Apps feel like natives, not tourists, on every platform they care about
- a consistent payment infrastructure for Apps available at our Marketplace
- Provide Users with:
- an open Apps ecosystem that lets them shop at the App store of their choice
- a robust App runtime environment that makes Apps feel like natives, not tourists on every device
- a means to back up and manage their Apps from multiple Stores across multiple devices
- Provide App Stores with
- a well-documented API for installing and managing Apps
- access to the same cloud-based services for App management that our Marketplace uses
- Provide well-designed API's for App installation, App management, and App payments
- Conceal uninteresting platform dependencies while providing access to crucial platform-specific features
- Provide access to multiple payment providers through a single, unified API
|App Definition||An App is described by its Manifest. The manifest contains user-facing metadata, including descriptions and icons. The manifest also enumerates the protected API's to which the App requests access. This information is used by the App Security Model to control access to privileged API's at run time.||Apps security model||ladamski||sicking|
|App packaging specification||sicking||sicking|
|App manifest specification||anant||anant|
|Identity||Many services in the Apps ecosystem require user authentication (e.g., the Marketplace itself, many of the Apps, the Cloud-based services). We can offer our users a much better overall experience if we (1) build a coherent Identity solution into all our services and (2) encourage App developers to do the same.||navigator.id API||benadida||benadida|
|Marketplace||We will develop and operate a vibrant, open source Marketplace for Apps. Participating developers will receive timely and transparent review of Apps they submit; participating users will discover relevant Apps and install them quickly and easily. The Marketplace will operate equally well on laptops, tablets, and smartphones.||marketplace architecture||clouserw||clouserw|
|Payment||We will offer our developers (1) a centralized way to price and manage paid Apps, including integration with multiple billing providers, as needed; (2) a unified Javascipt DOM API to facilitate In-app payments from Users for digital goods within Apps. We will offer users (1) a unified, trustworthy experience of purchasing and seeking refunds for paid Apps; (2) a consistent, trustworthy experience of making In-App payments||navigator.mozPay API||benadida||not sure|
|App receipt specification||anant||anant|
|In-app payment specification||benadida||kumar|
|Cloud services||We will offer users a centralized way to backup and manage their Apps (1) across all the App Stores they patronize and (2) across all their devices. We will achieve this using a Cloud-based service distinct from our Marketplace that will be integrated with our Web Runtime such that any App installation can be captured by the service if the user opts in.||Apps in the Cloud design||anant||anant|
We will provide a Web Runtime for Apps that makes HTML5-based Apps feel exactly like native applications on every device. This includes access to privileged device API's (i. e., geolocation, contacts, SMS) and native OS features (menus, drag-and-drop).
We will provide Apps-specific API's convering several different areas: (1) an installation API to allow App Store Apps to install packaged and web-hosted Apps; (2) a runtime API to allow running Apps access to their install metadata (i. e., their own App receipts); (3) a management API to allow Cloud-based services or management Apps access to the set of Apps installed on the current device
|Web Runtime (WebRT) for Android||bwalker||mfinkle|
|Web Runtime (WebRT) for Mac OS, Windows, Linux||bwalker||myk|
|Apps support on Firefox OS||sicking||fabrice|
- How can we help developers cope with the one-app-per-origin restriction?
- How can achieve a consistent Identity sol'n in the face of Firefox OS carrier and operator constraints?
- How can achieve a consistent payments API in the face of Firefox OS carrier and operator constraints?