Application Lifecycle

The Web Packaging document describes use cases for a new package format for web sites and applications and outlines such a format.

Applications running on mobile devices can go through different application states, from running to being idle, paused, stopped, discarded, or terminated. Transitions between these states are triggered by the underlying operating system, and hidden from web applications. The Page Lifecycle proposal seeks to expose application state transitions to applications so that these applications can persist/restore state, enable/disable use of network, etc.

The User Idle Detection document proposes an API for applications to detect when a user becomes idle or when the screen is locked. Applications may use that information to notify other users that the current user is unreachable (e.g. in chat applications), show timely alerts or pause media to save bandwidth when the user is not present.

Various sites embed content from a third party origin (e.g. news content) within their own user interface, or load third party content into an iframe to provide a faster, reliable loading experience, which is particularly crucial on mobile devices. One main drawback of this approach is that the third party's origin is not preserved: only the first party's origin appears in the address bar, which makes it difficult for users to identify the provenance and trustworthiness of the content they are browsing. Another drawback is that the third party page cannot leverage client-side resources and permissions that are attached to their origin. Portals is a proposal for enabling seamless navigations between sites or pages. In particular, it enables a page to show another page as an inset and perform a seamless transition between an inset state and a navigated state, thus solving the origin issues mentioned above.

The Web Background Synchronization specification builds on top of Service Workers to enable Web applications to keep their user data up to date seamlessly, by running network operations in the background, adjusting to possibly unreliable connections that users often experience on mobile devices.

Background Fetch defines a similar service worker based download and upload mechanism in the background, but allows the background operation to continue, with user visibility, even if the user closes all windows and workers. The specification is specifically tailored to enable downloads/uploads of large assets (podcasts, movies, textures).

An application may run multiple workers at once, and multiple instances of an application may be running concurrently in separate windows. The Web Locks API allows such an application to acquire locks and coordinate usage of shared resources, such as storage, across instances.

MiniApps are applications that run in a hosting application with hybrid native/web capabilities. MiniApps use Web technologies (CSS, JavaScript) although a few common Web technologies are not available for performance or security reasons (e.g. MiniApps usually cannot access the DOM). The runtime also features additional APIs that are more traditionally found in native applications (e.g. contacts API, maps) or application frameworks (e.g. views, router). The trust model of MiniApps also differs from regular Web applications as MiniApps usually need to be reviewed and approved by the hosting platform before users can access them. The MiniApp Standardization White Paper reviews potential standardization areas for MiniApps. The MiniApp Community Group incubates more specific proposals (URI Scheme, Lifecycle, Manifest, Packaging).