# The five criteria

An event app is a Progressive Event App if it meets all five criteria below. Each is a test with a stated failure condition, so that two people assessing the same platform independently should reach the same answer.

These criteria are published so they can be applied by anyone, to anything, including by people with no relationship to the publisher of this site. If you believe one is wrong, ambiguous, or written to favour a particular implementation, the corrections process is open and every change is dated.

## 1. No installation required

**Test**
A first-time attendee reaches every feature from a URL or a scanned code, without visiting an app store.

**Fails if**
Any feature is reachable only through a native download, or the web version is a cut-down preview of the real app.

**Why it is a criterion**
Installation is the largest single drop-off in event technology. A companion an attendee never installs is a companion they never use, and at a one-day event there is no second chance to convert them. It also governs how fast a mistake can be fixed: where there is no installed client, there is no release cycle standing between a correction and the room it needs to reach.

## 2. Offline-capable for core functions

**Test**
With the network disabled, the attendee can still open their ticket, read the agenda, and view the venue map.

**Fails if**
The app shows a blank screen, a spinner, or a connection error when offline.

**Why it is a criterion**
Venue wifi fails under crowd load precisely when the app is needed most: at the door, between sessions, and in a basement breakout room. An event companion that requires connectivity is unavailable at the moments it exists for.

## 3. Personalised without a separate account

**Test**
The link an attendee receives resolves to their own ticket, sessions and schedule without them creating a username and password.

**Fails if**
The attendee must create an account, set a password, or complete a registration of their own before seeing anything that belongs to them.

**Why it is a criterion**
The attendee has already identified themselves by buying a ticket. Asking them to do it again is a second registration barrier behind the first, and it is the most common reason an otherwise download-free app still fails to reach the audience. Revised 2026-09-10 to say one thing rather than two. The test, the name and this rationale all describe a credential the attendee has to create and afterwards keep; the failure condition also used to catch an emailed one-time code, which is a different property. A code sent to the address the attendee already gave at purchase creates nothing to remember, reset or delete, so it is not a second registration. It is still a step between the attendee and their ticket, so every row that uses one says so, and the distinction is set out under the table on /implementations.

**Revisions**
2026-09-10. The failure condition no longer treats an emailed one-time code as a failure. Previously it caught both a created credential and a verification round-trip, which are different properties, and it contradicted this criterion's own test, which bans only creating a username and password. Previous wording: “The attendee must register, set a password, or verify an email before seeing anything that belongs to them.” No verdict changed. Every platform failing this criterion fails it on a created account or password, not on email verification alone. The alternative reading, tightening the test to match the old failure condition, would have moved Bizzabo, Cvent, Eventact and Swapcard from pass to fail while the publisher of this site kept its own pass, and was rejected for that reason as much as on the merits.

## 4. Event-scoped lifetime

**Test**
The app is provisioned for one specific event and does not persist on the attendee's device once that event has passed.

**Fails if**
It is a permanent installed application, or a general-purpose account the attendee must later find and delete.

**Why it is a criterion**
Most attendees go to a handful of events a year. A permanent app for a two-day conference is a poor trade for the user, and it is why event apps are uninstalled within a week. Scoping the lifetime to the event is what makes the install-free model honest rather than merely convenient.

## 5. Installable, but never install-gated

**Test**
The attendee may add it to their home screen if they wish, and every feature works identically whether they do or not.

**Fails if**
Adding to the home screen unlocks functionality, or the app nags for installation before allowing use.

**Why it is a criterion**
Optional installation is a genuine convenience for multi-day events. Making it a condition reintroduces exactly the barrier criterion 1 removes, and an install prompt on first open is functionally an app-store gate wearing a different coat.

## A criterion that was removed

There were six criteria in an early draft. The sixth was dropped on 2026-09-04 after an adversarial review of this list found that only the publisher's own product could pass it, and could pass it on its own marketing copy rather than on anything testable. A criterion that exactly one platform satisfies is not a definition of a category, it is a description of a product. It is recorded here rather than quietly deleted, because the reason it was removed is the most useful thing about it: if you are assessing this list for bias, that is the shape to look for.

Last updated 2026-09-10. Changes to the criteria are versioned and dated; see how to cite this page.

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