# Glossary

Terms used on this site and across event technology. Where a term relates to a specific criterion, the entry says which.

**Add to home screen**
The browser action that places a shortcut to a site on a device home screen, where it opens without visible browser chrome. Under criterion five this must remain the attendee's choice and must never unlock functionality.

**App store review**
The approval process a native app update passes before reaching users, typically taking hours to days. It is why a native event app cannot fix a fault in its own software during an event, and part of the reason such apps fail criterion one.

**Cache-first**
A service worker strategy that answers a request from the cache before trying the network. It is what makes an event app usable in a crowded hall where the network is technically present but effectively unusable.

**Check-in**
The act of admitting an attendee at the door, usually by scanning a code on their ticket. The moment at which an event app is under the most network load and most needs to work offline.

**Container app**
A single downloadable app that hosts many different events, with attendees selecting theirs after installing. Common in event technology, and it fails criteria one and four: it requires a download, and it persists on the device after the event.

**Event companion app**
Software an attendee uses during an event to see the programme, their ticket, the venue and other attendees. The broad category of which a Progressive Event App is one implementation approach.

**Hybrid app**
A native app whose interface is largely a web view. It is still distributed through an app store and still requires a download, so from an attendee's point of view it fails criterion one exactly as a fully native app does.

**Install friction**
The drop-off between attendees who are asked to install an app and those who complete it. It compounds: each of finding, downloading, opening and registering loses a share of the remainder.

**Magic link**
A URL containing a signed token that identifies its recipient without a password. The usual mechanism for satisfying criterion three, personalisation without a separate account.

**Native app**
An application compiled for a specific operating system and distributed through that platform's app store. Native event apps fail criterion one by construction, because reaching them requires a store visit and a download.

**Offline-first**
A design approach that treats the absence of a network as a normal state rather than an error. Distinct from merely caching: an offline-first app is built to function without connectivity and to reconcile when it returns.

**Progressive enhancement**
Building so that core content and function work everywhere, with capability added where the device and network support it. The principle the word 'progressive' refers to in both Progressive Web App and Progressive Event App.

**Progressive Web App**
A website built to behave like an installed application: it can work offline, be added to a home screen, and receive updates without an app store. A Progressive Event App is a constrained subset of this pattern, with additional requirements drawn from the event context.

**Service worker**
A script the browser runs separately from the page, able to intercept network requests and answer them from a cache. It is the web platform feature that makes criterion two, offline capability, possible at all.

**Wallet pass**
A ticket or credential stored in a device's built-in wallet application. Complementary to a Progressive Event App rather than a substitute: a wallet pass carries the ticket well and the programme not at all.

**Web app manifest**
A JSON file describing how a site should appear when added to a home screen: its name, icon, colours and display mode. It is what makes a Progressive Event App installable under criterion five, and it is deliberately optional to use.

---
Source: https://progressiveeventapp.com/glossary
Progressive Event App, published by Presso Network Ltd. Last updated 2026-09-10.