What is an app, and how does it get onto a display?

An app is a domain-specific extension of the platform: a manifest, at most one widget, and, if needed, a backend. This page follows its lifecycle from the manifest to the widget in the scene — and says which parts are open to whom today.

An app does not start a process of its own. It is a package that the platform loads, and it shows up in four parts. The first is the manifest with identity, widgets, permissions, data access, and signing policy. The second is an optional backend with resolver, fetcher, and jobs. The third is the runtime bundle that the player loads, and the fourth is the authoring bundle with the configuration form for the scene editor. The manifest is the one binding description: what is not stated there does not exist for the catalog, portal, and device. Each app has at most one widget. The app is the unit that an organization installs, evaluates, and removes, and a widget handles several presentations through its preview variants and a configuration field.

How much machinery an app carries falls into three levels. Some of the bundled apps render solely from their configuration and have no backend (clock, webpage, notice-board, countdown, countup, world-clock, word-clock, ticker, qr-code, youtube, stream, embed). weather, rss, tagesschau, and calendar pull from external sources with a fetcher, and the brand apps bbc, bild, deutschlandfunk, ndr, and spiegel inherit the backend and widget from tagesschau. pharmacies-on-duty, with a fetcher and a recurring job, and menu-board, without any outbound retrieval, keep their own resources in an app database of their own. opening-hours gets by with a backend that only reads the location, without a fetcher, resources, or a database. In addition there are the gate apps without a visual surface, onedrive and video-wall: they bring no widget but unlock a feature of the portal. The complete list is the apps/ folder.

An app gets onto the display in four stages. Platform operations creates a release from the manifest and bundle. It freezes the version, manifest, and bundle reference and starts in the canary channel, from which it is promoted step by step through beta to stable. An organization installs the app from the catalog. The installation has three states: active, Update waiting (when a new version in stable demands more permissions, data access, or changed terms, or when the installed one expires), and uninstalled. The device reads from the scene snapshot, for each app, the one version that the display plays: the installed one, because scenes of the same major version follow it. If a scene of the display deliberately holds an older major version, the display plays that version for all of its scenes, and the scene carries a notice until someone raises it. The device fetches the missing bundle through GET /v1/apps/{appId}/{version}/bundle.zip and checks the sha256 value and the Ed25519 signature before it unpacks. The renderer first checks whether the version fits it: the manifest states in apiCompatibility.rendererHost the host contract that the bundle needs, and the renderer loads only what its own contract version covers. Then it loads the runtime bundle and has it register its widget. A bundle that does not fit is not loaded in the first place. One that brings no widget, registers a widget that is not its own, or fails while loading is reported (widget.bundle.no-exports, …foreign-widget, …load-failed) instead of tearing down the scene. The scene editor loads the runtime and authoring bundles the same way from the installed version and shows their widgets and forms.

What follows#

• Platform operations creates releases. The catalog has no submission and no review queue. Creating, promoting, demoting, and retiring are operator work.
• Apps are built in the platform’s source tree today. The @szenera/apps-sdk SDK is a package of this source tree and is not published to npm. It does not travel with the services’ release train but has its own cadence.
• New versions stay compatible. Fields of a widget configuration are only added with a default and never disappear, because a version must read the configurations of its predecessors. An app’s backend runs in exactly one version and serves every version that a display still plays, so its routes, outputs, and responses change only additively, and every route keeps accepting what an earlier version sends. A test in every app holds both against a fixed baseline.
• There is no submission path for third-party apps. The following pages describe the contract that the bundled apps are written against, not a procedure that you could go through today.
• The user’s view is in the handbook. Installing, permissions, and terms from the organization’s point of view: Apps in the handbook.

Related#

• The manifest — every field with whether it is required, its format, and its effect.
• Signing and the path into the catalog — bundle, signature, channels.
• Apps in the handbook — the organization’s view.