Apps/Architecture

Apps Program Software Architecture

Bill Walker

Program Goals

• 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
  • a well-documented API for installing and managing Apps
  • access to the same cloud-based services for App management that our Marketplace uses

Architectural Goals

• 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

Deliverables

Category	Description	Deliverable	Architect	Tech Lead
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
App Management	We will provide API's convering several different areas: (1) an installation API to allow Marketplaces 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	navigator.mozApps API	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	andreas	not sure
		App receipt specification	anant	not sure
		In-app payment specification	kumar	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
Runtime	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).	Web Runtime (WebRT) for Android	not sure	mfinkle
		Web Runtime (WebRT) for Mac OS, Windows, Linux	not sure	myk
		Apps support on Firefox OS	not sure	cjones

Problematic questions

• 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?