# Develop your own app

An app brings a manifest, a widget, a form, and optionally a platform-side part of its own. It is created from a template, and the whole way through to release is described on the developer site at `https://developer.szenera.com/apps-sdk/template-to-release`. The reference with example apps is at `https://developer.szenera.com/apps-sdk`, organized by manifest, widget and preview, data access, and signing.

> **Type:** reference
> **For:** Teams that want to build an app of their own for Szenera instead of using an existing one.
> **Prerequisite:** Familiarity with web technology. If you only want to use an app, you do not need this page.
> **Where in the portal:** **Apps › Discover apps** — that is where the finished app ends up.

## What an app declares in the manifest

The manifest is the one binding statement an app makes about itself. What is not in it does not exist: a view without an entry does not appear in the store, and a permission without an entry is never requested.

| Entry | What it is for |
|---|---|
| Identifier and version | Make the app unique on the platform and on the display. |
| Listing data | Name, one-liner, and description: the text that readers see in the store. |
| Category | Sorts the app into one of the store’s categories and at the same time determines its section in the widget palette of the scene editor. |
| Class | The base class with no badge, **Pro**, or **Add-on**. It decides which packages include the app. |
| Texts per language | The texts are written in German in the manifest, and every further language is a block of its own. Today all apps carry German and English, and the store shows the language of the portal. |
| Widget with views | Each view with a name, a sentence of explanation, and its position on the display. They produce the **Views** in the app’s listing in the store. They are not painted promotional images but the same display software that runs on the display. |
| Compatibility | Which device types the app runs on, in which orientation, and what it shows without a network. The store lists it under **Runs on**. |
| Permissions | Who on the team may operate the app. On installation, they are added to the organization’s permission catalog. |
| Data access | What the app reads, what it transmits to the outside and why, and what happens to its data on uninstall. |
| Legal notice | The notice with the terms that an organization agrees to before installation, if the app carries one. |
| Signature requirement | Whether the bundle of this app must be signed. |

The app declares its class itself. The class is in the manifest and not in the price catalog: the app knows what it does, and the catalog knows items and quantities.

## The four building blocks

| Building block | What it does |
|---|---|
| Manifest | The declarative statement from above. Every app has one. |
| Widget for the display | What people see on site. An app carries at most one widget. It provides several views through templates of this one widget. |
| Form in the scene editor | What editors use to configure the widget. |
| Platform-side part of its own | Optional: fetches data from a third-party source, runs on a schedule, and keeps records of its own that the organization maintains itself. |

An app does not have to carry a widget at all. Two of the bundled apps bring no display area with them: one unlocks a function of the portal, and the other additionally provides the place where a third-party storage account is signed in.

Three of the bundled apps show the three stages of expansion: **Clock** gets by with a manifest, a widget, and a form and needs no data source. **Weather** adds fetching from a third-party source. **Pharmacies on duty** carries everything: fetching, a schedule, and records of its own that are maintained in the portal.

The bundled apps are the best models: for every form of build there is one among them, and all of them are in the store, sorted under [All apps at a glance](/docs/apps/all-apps).

## What users see before installation

Three details decide whether an organization installs an app, and the app itself provides all three:

- **Roles & permissions** in the **Setup** tab of the store listing and in the consent dialog: who on the team may operate the app.
- **Data & access** in the tab of the same name in the listing: what the app creates for the organization, what it reads from existing records, what it contributes, which third-party service it talks to and what it transmits in the process, and what remains on uninstall. The section is there even when the answer is “nothing”.
- **Important note**: the legal notice, if the app carries one. It is agreed to explicitly in the consent dialog.

An app that stays vague here does not get installed: these three details answer the question that really counts before every installation. The key facts on the action card, such as **Own data**, **External**, and **Runs on**, are generated from the same details in the manifest.

## Sign and submit

An app is delivered as a bundle and fetched by the device at runtime. If the bundle is signed, the device verifies the signature before it unpacks it. For apps with sensitive content this is mandatory, for the others optional. Anything that fails the check does not even start.

The way into the store leads through review and release by us: a new version is first placed in a pre-release channel, and only after confirmation by a second person does it reach all organizations. How this works in detail is described at `https://developer.szenera.com/apps-sdk/template-to-release`. We do not accept apps from outside yet. Submitting will come when we open the platform to publishers.

## Related

- [What is an app, and what does it do with your data?](/docs/apps/about-apps)
- [Discover apps: overview, listing, and data and access](/docs/apps/discover-apps)
- [What can your own programs do with Szenera?](/docs/developers/about-integrations)