It's useful to think about what an app actually is — what is the actual "product" or "deliverable"?

An app starts with a manifest that defines various properties of an app such as:

• The name of the app, the version, the author, etc
• The targets — where the app should render to. A target is basically just "where to render an iframe" in the overall Deskpro interface.
• Storage requirements — E.g. our API already supports storing arbitrary key-value pairs. An app needs to declare what keys it uses, and permissions, data format, etc.
• Settings — Apps may declare settings that get set during install. For example, API keys, API endpoint URL, enable/disable certain features, set defaults, etc.
• Custom fields — Apps may create custom fields automatically that are connected to the app. Most often these fields are used for linking data to existing objects such as tickets. (E.g. to store the relationship between a ticket in Deskpro and an external resource).
• external APIs — An app may proxy API requests to external services. Any external services must be explicitly whitelisted in the app config.

Along with a manifest you have at least three files:

• index.html — which represents the file that gets rendered in the frame. This will often be empty except with script tags to load the bundle.
• index.ts — The main source file that boots the app
• README.md — A markdown file describing the app

The app package

So these files (manifest.json, index.html, index.ts, README.md) are collectively known as the "app package". We ship apps as a .zip which is just all these files in a zip.

The app instance

Once you have a package, an admin may install it on a helpdesk. This is the act of actually enabling the app. This is when an app actually has a value inserted in the database.