From MozillaWiki
< Gaia‎ | System
Jump to: navigation, search

Status & Team

See: B2G - Project tracking spreadsheet



Apps can come from two sources:

  • Trusted
  • Untrusted


  • User can identify source URL
  • User can review app permissions
  • User can view app icon
  • User can view app author
  • User can initiate install
  • User can track installation progress

Design Spec

For the latest UX specifications, please visit and/or


. . .



  • User can organize installed apps
  • User can delete installed apps
  • User can reinstall apps
  • User can review & edit app permissions
  • User can review & edit app notification settings
  • User can review app power consumption
  • User can review app data consumption
  • User can edit app settings
  • User can specify default apps for actions (eg: Gallery is default app for adding image attachments)
  • User can differentiate between installed apps, and installed bookmarks.\
  • User can review app update history
  • User can rollback app updates
  • User can clear app cache data


Design Specs




In traditional mobile OS app paradigms, apps live on the device, and _may_ have a remote component. On B2G, it's reversed. Apps live on the web, and _may_ have local component. The only data they are _required_ to store locally are a manifest and icon. Taken to it's extreme, in this model the mobile device becomes a mere window on an external world, and icons are akin to bookmarks: pointers to an external location.

This new technological architecture presents opportunities to rethink existing mobile app paradigms. Updates are one example. What is "updating" when apps are inherently remote? Do we still require user authorization to update, or do we follow a more web-centric approach, and update the user's local cache without their explicit permission? How do we marry this web-centric approach with the mobile context (user sovereignty, app economic model, etc)?

Here are some models for application updates:

  • Require user to manually apply. Inform user that update is available, and make it easy to apply.
    • Force immediate update (eg: some modern video game systems require user to apply updates immediately before they can use device, and only allow user to "apply now" or "shutdown".
    • Update later. This is the approach most mobile OS take, wherein the user is informed of an available update in some fashion, and it is left to their own discretion when (if ever!) to update.
  • Auto update in background
    • The OS quietly pulls down an update in the background. Could be subjected to certain conditions (eg: only download over wifi,

The appopriate policy may vary depending on the type of app:

  • Offline-mode compatible?
  • Large or small file size?
  • A game, a utility, a media player?
  • Purchased, rented, subscribed to?
  • Frequently or rarely updated?
  • Requires permissions?



  • Apps can be kept up-to-date.
  • User can review app update history
  • User can rollback app updates

Potential models

The "manual update" model:

  • User is made aware of update
  • User can decline update ("Skip")
  • User can defer update ("Remind me later")
  • User can initiate update ("Update")
  • User can review new permissions before install
  • User can grant or deny new permissions on first run
  • User is prompted when their installed app is out of sync, no longer support, etc.
  • User can opt into "automatic updates"

The "automatic update" model:

  • User can review installed updates
  • User can specify conditions under which silent updates are allowed to occur:
    • Data connection
    • Battery conditions
    • Time of day
  • User can grant or deny new permissions on first run



  • User can uninstall apps
  • User can reinstall apps