Implementations

Eighteen event platforms assessed against the five criteria, in alphabetical order. There is no ranking and no overall verdict, because a platform that meets two criteria well may be a better choice than one that meets four badly.

How to read this

Unknown means unknown. Most platforms do not document their offline behaviour or their install behaviour at all. An unsourced guess would be worse than an admission, so a criterion that could not be verified from public evidence is recorded as unknown, for every platform equally.
Marketing copy is not evidence. A vendor describing its app as working “in low-connectivity environments” does not establish that it works with the network disabled. Claims of that shape were rejected, including one of the publisher's own.
Some of this was tested, and the rest was read. Most verdicts rest on documentation, app store listings and the products' own published code, because no vendor exposes a ticketed attendee experience to an assessor. Where a vendor publishes a working event app that needs no ticket, it was tested instead: the network was blocked below the service worker and the app reloaded, which is criterion 2's stated test rather than a proxy for it. Each verdict says which it is. Testing has moved verdicts in both directions, including withdrawing a pass this reference had granted on the strength of a vendor's own wording, which is the point of doing it.
Assessments go stale. A vendor can ship or withdraw a web experience between one check and the next. Every verdict carries the date it was checked.

The publisher's own product is in this table

Presso Events is built by the company that publishes this site. It is listed alphabetically like everything else, and it fails criterion 2, which both EventMobi and Sessionize pass. That finding came from reading Presso's own published service worker, which states in its own comments that it is not an offline data cache. It is recorded here in the same words that would be used for anyone else, and the same offline test that passed Sessionize was applied to Presso's install behaviour on criterion 5, where it passes.

What a pass on criterion 3 does and does not mean

Criterion 3 asks whether the attendee has to create an account. It does not ask whether anything at all stands between the link and their ticket, and those are different properties that this reference used to run together. Until 2026-09-10 the criterion's stated test banned only “creating a username and password” while its failure condition also caught “verify an email”, so the two halves disagreed about the same platforms. The failure condition has been aligned with the test and the change is recorded, with its previous wording, on the criteria page.

The practical consequence is that four platforms pass this criterion on a flow that still involves an emailed code: Bizzabo, Cvent, Eventact and Swapcard. A code sent to the address the attendee already gave at purchase creates no credential to remember, reset or delete, which is what this criterion measures. It is still a round trip through an inbox, possibly on venue wifi, and that is a real difference from a link that simply opens. Each of those four rows says so in its own words, and the publisher's own row records that its pass is the stronger kind, which is a claim a reader should check rather than take.

The other reading was available and was rejected. Tightening the test to match the old failure condition would have moved those four competitors from pass to fail while Presso Events, which issues a link that resolves without a code, kept its pass. A change that fails four competitors and spares the publisher needs a far higher bar than a change that does the reverse, and this one did not clear it: the criterion is named for accounts, its stated rationale is about a second registration barrier, and an emailed code is not a registration. Adding a sixth criterion for the round trip was also considered and rejected, because a new criterion whose main effect is to fail competitors and pass the publisher is the exact mistake that killed the original criterion 6.

Most of what is unknown here cannot be checked by anyone

Forty-two of the ninety cells in this table are recorded as unknown. As of the reachability sweep on 2026-09-09, not one of them is unknown for want of research. Each is blocked because the surface that would settle it cannot be opened by someone who is not already an attendee at a live event or a prospective customer in a sales process.

That count went up by nine on 2026-09-09, and it went up for good reasons. Four of the nine are simply a new platform: colada was assessed and added, and it enters with four cells unknown because it publishes no attendee surface anyone can open. The other five are the interesting ones. An audit re-examined every verdict already sitting in the table, asking of each one whether its evidence would be accepted if it were offered today for the first time. Five failures did not survive the question: three against vFairs and two against Eventbrite. All five had been reasoned from what a vendor's marketing page did not say rather than from anything it did say, and all five ran in the direction that flatters the publisher of this site. They have been withdrawn to unknown. One further failure, against vFairs on criterion 3, was found to be cited to a page that does not mention passwords or logging in at all; that verdict survives, but only because the vendor's own attendee instructions were found and now stand in place of the marketing page.

A further seven were added later the same day, and again for good reasons rather than bad ones. Two more platforms were assessed and added, ClearEvent and Converve, and between them they enter with seven cells unknown, because neither publishes an attendee surface an outsider can open. Both pass criterion 1 on the vendor's own statement and on the absence of any native application to lock a feature behind. Neither the two new rows nor the audit described below changed a single verdict already in the table.

One of the two Eventbrite withdrawals is worth stating separately, because it is a failure of method rather than of judgement. The verdict quoted a sentence that is no longer in the article it cites. That article still returns 200, so the monthly link check could never have caught it: a citation can rot while its URL stays perfectly healthy, and the only thing that finds it is re-reading the quotation against the page.

That finding was then run across the whole table on 2026-09-09. Every one of the forty-five passes and failures carrying a source was checked by fetching the page and searching it for the words the verdict puts in quotation marks. Ten were defective and none of the ten changed a verdict, but the two kinds they divide into are worth separating. Four were rot of the kind described above: in the worst case the article behind the URL had been rewritten in place and retitled, while the URL kept returning 200 and stayed listed in the vendor's own sitemap. The other six had never been right. They quoted words their own source does not use: a word inserted into a vendor's sentence, two numbered steps run together into a sentence that appears nowhere, a clause appended to a bullet that stops earlier, and a sentence attributed to a vendor that the vendor never wrote. No link check can find that class of error, and neither can re-reading the reasoning, because the reasoning stays internally consistent either way. Only reading the quoted words against the live page finds it.

What blocks it	Platforms	What was found instead
A ticket to a real event	Bizzabo, Brella, ClearEvent, Cvent, Eventbrite, Ticket Tailor, Whova	A login wall or a purchase. Cvent's attendee hub redirects to an attendee login and its hub identifiers are not the public registration-site identifiers, so they cannot be reached from the outside at all. Eventbrite and Ticket Tailor publish the box office and email the ticket. ClearEvent's attendee portal opens only from the link an organiser sends, so the personalised half of it cannot be reached from outside an event.
A sales process	Swapcard, Converve, Cvent, Eventact, vFairs, colada	A booking form. The published demos are personalised demonstrations, enrolment-gated guide sites, or marketing walkthroughs rather than live apps. vFairs documents an attendee web platform in its help centre but publishes no event that opens from a link, so what that platform does is described by the vendor and not observable. colada's demo domain resolves to a parked page, leaving "Book free demo" as the only route in. Converve publishes no open demo at all and documents nothing about how an attendee gets in.
A fact only the vendor's server holds	EventApp.pl, InvitePeople	Whether an identity created at one organiser's event is the same record at another's is not observable from a browser, however much of the app is public.

Stated plainly: for several of the largest platforms assessed here, an independent assessor cannot evaluate the attendee experience without buying a ticket to a stranger's event or entering a sales process. Three platforms in this table publish an attendee app that anyone can open, and those are the rows carrying tested verdicts rather than read ones.

None of that is a defect on the vendors' part, and it is not recorded here as one. An event app holds attendees' names, schedules and messages, and Bizzabo's own account of why its app has a login at all is that the app carries identity data and the organiser needs to know that whoever gets in registered for the event. That is a sound reason. The consequence is structural rather than anyone's fault: a category whose defining experience is only visible to people already inside it cannot be compared from the outside, and buyers making a choice are outside it.

This reference does not buy tickets to third-party events to get round it. Doing so would insert the publisher of a supposedly neutral assessment into another organiser's event, on a real attendee list, which costs more credibility than a resolved cell is worth. So those cells stay unknown, and the reason they are unknown is published alongside them. Any vendor here who would prefer a tested verdict can produce one by publishing a demo event that opens from a link, which is what Sessionize, LineUpr and EventApp.pl already do.

The table

Platform	1No installation required	2Offline-capable for core functions	3Personalised without a separate account	4Event-scoped lifetime	5Installable, but never install-gated
Bizzabo	Unknown	Unknown	Pass	Fail	Unknown
Brella	Unknown	Unknown	Fail	Fail	Unknown
ClearEvent	Pass	Unknown	Fail	Unknown	Unknown
colada	Pass	Unknown	Unknown	Unknown	Unknown
Converve	Pass	Unknown	Unknown	Unknown	Unknown
Cvent (Attendee Hub)	Unknown	Unknown	Pass	Unknown	Unknown
Eventact	Pass	Unknown	Pass	Unknown	Unknown
EventApp.pl	Pass	Fail	Unknown	Unknown	Pass
Eventbrite	Unknown	Unknown	Fail	Fail	Unknown
EventMobi	Pass	Pass	Fail	Fail	Pass
InvitePeople	Pass	Unknown	Unknown	Unknown	Unknown
LineUpr	Pass	Fail	Pass	Pass	Pass
Presso Events	Pass	Fail	Pass	Pass	Pass
Sessionize	Pass	Pass	Pass	Pass	Fail
Swapcard	Unknown	Unknown	Pass	Fail	Unknown
Ticket Tailor	Pass	Unknown	Pass	Pass	Unknown
vFairs	Unknown	Unknown	Fail	Fail	Unknown
Whova	Fail	Unknown	Fail	Fail	Fail

The evidence, platform by platform

Bizzabo

Enterprise event management platform with branded native apps and a web event experience.

Row last verified 2026-09-09.

Unknown · 1. No installation required: A web path exists and Bizzabo's own passwordless-login post distinguishes mobile and web clients, but no statement of feature parity was found. Source, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: Still unknown, but no longer for want of trying, and the evidence is now recorded so the next pass does not repeat the search. Bizzabo's public event site was tested on an iPhone viewport: it registers no service worker at all, holds no caches, reports zero bytes of storage in use, and with the network blocked at the proxy it returns a connection error rather than any content, having rendered 12,574 characters of agenda a moment earlier online. That would be a fail if the public event site were the attendee app. It is not: a log-in exists, and the surface behind it could not be reached without a ticket to a real event. Re-quoted on 2026-09-09: the vendor's only offline claim reads "Bizzabo's mobile app performs even in low-connectivity environments", and the record here had it as "built to perform even in low-connectivity environments", which is not what the page says. The correction matters beyond the wording, because the sentence the vendor actually wrote scopes the claim to the mobile app rather than to the attendee experience as a whole, and says nothing about the browser path this criterion is asking about. Recorded as unknown rather than fail because a fail here would flatter the publisher of this site, which fails the same criterion, and the surface that would settle it is the one that could not be opened. Source 1, Source 2, checked 2026-09-09.
Pass · 3. Personalised without a separate account: "Logging to the app no longer requires a password creation." The quotation was corrected on 2026-09-09 to the vendor's exact wording. An email confirmation step remains, so this is a pass of the weaker kind: no credential is created, but a round trip through an inbox stands between the attendee and their data. See what a pass on criterion 3 does and does not mean, below the table. Source, checked 2026-09-09.
Fail · 4. Event-scoped lifetime: A single Bizzabo-branded container app used across many organisers' events, installed once and persisting afterwards. Source, checked 2026-09-09.
Unknown · 5. Installable, but never install-gated: No page found stating features are identical with and without the native app.

Brella

Networking-focused event platform with native apps and a web app.

Row last verified 2026-09-09.

Unknown · 1. No installation required: Account creation happens exclusively through the web app, so the web path is not a stub, but no parity statement with the native app was found. Source, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: No documentation of offline caching. Only a connectivity-troubleshooting page, which addresses a bad connection rather than none. Source, checked 2026-09-09.
Fail · 3. Personalised without a separate account: The default path requires a password created at sign-up, or Google/Apple SSO. One-click authentication is documented as something the organiser must enable. Re-read at source on 2026-09-09 and unchanged: the vendor still states that on the Continue with Email route users "log in with their personal/corporate email address and use a password that is created during the sign-in process", and that an authentication email must be received before the account exists. Source, checked 2026-09-09.
Fail · 4. Event-scoped lifetime: A single container app on both stores, used across all Brella events via join codes. Re-checked at source on 2026-09-09: the listing is live, carries the bundle identifier com.brella.native, and describes itself as a networking application for business events and conferences generally rather than for any one event. Source, checked 2026-09-09.
Unknown · 5. Installable, but never install-gated: No evidence either way.

ClearEvent

Event management platform whose attendee surface is a browser-based Event Portal rather than a native app.

Row last verified 2026-09-09.

Pass · 1. No installation required: The vendor makes the claim itself, on its attendee app page: "ClearEvent's mobile event app works as a browser-based event app for attendees, meaning participants simply open a link and access everything instantly on any browser and any device, no app store download required." Corroborated structurally rather than on the vendor's word: an Apple search API check on the GB storefront on 2026-09-09 returns no ClearEvent application of any kind, so there is no native app for a feature to be locked behind and none for the browser version to be a cut-down preview of. The vendor's own help centre describes the attendee Event Portal as reachable "from any mobile or desktop browser", either by the link the organiser sends or by signing in at app.clearevent.com. Source 1, Source 2, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: No attendee surface is reachable without an organiser's event link, so this could not be tested, and the vendor makes no offline claim about the Event Portal that could be checked. The check-in app the vendor does describe as working offline is the organiser's scanner, not the attendee portal, and reading one as evidence for the other would be the mistake this table exists to avoid.
Fail · 3. Personalised without a separate account: Documented by the vendor rather than inferred. The attendee-facing Event Portal overview lists the personalised half of the product behind a sign-in: "Receive a personalized experience when you sign in. See personalized schedules, messages, jobs & task assignments", and the itinerary feature likewise. The sign-in path is a ClearEvent Account, offered with a "Need an account? SIGN UP" link and served by a Forgot Password article, so it is a username and password in the criterion's terms. Unauthenticated visitors can still open the portal link and read event information, which is why criterion 1 passes; what they cannot reach without an account is anything that belongs to them. Source 1, Source 2, checked 2026-09-09.
Unknown · 4. Event-scoped lifetime: The ClearEvent Account looks cross-event, in that signing in produces "a list of all the events you are attending", but that sentence is in an article filed under Event Manager: Getting Started, so reading it as the attendee's experience is an inference rather than a finding. No attendee-facing statement of account persistence or deletion was found either way. Recorded as unknown because a fail here would run in the publisher's favour on evidence that would not be accepted if it were offered for the first time today.
Unknown · 5. Installable, but never install-gated: The vendor documents saving the portal to the device home screen, which implies a manifest, but no attendee surface is reachable without an organiser's event link, so neither the manifest nor the presence of an install gate could be checked. No statement of feature parity between the saved and browser paths was found.

colada

Swiss event management suite whose attendee experience is assembled from browser-delivered modules rather than a single named app.

Row last verified 2026-09-09.

Pass · 1. No installation required: Both stated fail conditions are cleared structurally rather than on the vendor's word, which is what carries this verdict. An Apple search API check on the GB storefront on 2026-09-09 returns no colada event app of any kind: the thirteen results carrying the string are a point-of-sale system, a laundry service, sticker packs and salon loyalty apps, none of them published by colada. There is therefore no native application for a feature to be locked behind, and none for the browser version to be a cut-down preview of. The attendee-facing modules are browser-delivered by construction: colada.pages builds the attendee portal as an event website, and colada.agenda gives attendees "jederzeit einen aktuellen, mobilen und dynamischen Überblick" over the programme, on a surface the vendor describes as "Optimiert für Smartphones und Tablets, ohne App-Download, direkt im Browser" and as working "auf jedem Gerät, ohne Installation oder technische Hürden". Re-sourced on 2026-09-09: those words are on the colada.agenda page rather than the colada.match page cited before, and the earlier record transliterated the German umlauts. Not tested, because no colada attendee surface is reachable without a sales process. Source, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: No statement about offline behaviour was found on any of the eighteen application pages, and the attendee surface could not be opened to test it. colada publishes no demo event: coladademo.com resolves to a parked domain, and the only route the site offers is "Book free demo", which is a sales process. Recorded as unknown rather than fail for the same reason as the eight other platforms whose attendee surface could not be reached. Source, checked 2026-09-09.
Unknown · 3. Personalised without a separate account: What an attendee has to do to get in is the organiser's choice and is not stated. colada.pages documents access control across "Public, Protected & Private" areas, offering "offene Infos, passwortgeschützte Bereiche oder personalisierte Dashboards", open information, password-protected areas or personalised dashboards, as configuration options rather than as a described default. The platform's "ONE login" slogan refers to the organiser's back office, not to the attendee. No attendee login flow is documented anywhere found, and none could be observed. Source, checked 2026-09-09.
Unknown · 4. Event-scoped lifetime: The installed-application half is cleared: the Apple search API check on 2026-09-09 found no colada app, so nothing is installed to persist. The account half is not, and there is evidence pointing the other way that is recorded here rather than resolved. colada.match sells persistence as a benefit: contacts and profiles "bleiben auch nach dem Event aktiv und können weiter gepflegt werden", remain active after the event and can go on being maintained. Whether that is a general-purpose account an attendee must later find and delete, or a per-event profile that merely stays readable, is not stated. Unknown rather than fail, because a fail here would flatter the publisher of this site, which passes this criterion, and the sentence does not say what a fail would require it to say. Source, checked 2026-09-09.
Unknown · 5. Installable, but never install-gated: No manifest could be fetched and no install behaviour observed, because no colada attendee surface opens from a link. No statement of feature parity between an installed and a browser path was found either, which is unresolvable in a different way from the others: with no native application in existence, there may be no second path for a parity statement to be about. That is a plausible reading and not an evidenced one, so it is not scored. Source, checked 2026-09-09.

Converve

German B2B matchmaking platform whose attendee event app is delivered as a browser web app alongside the event website.

Row last verified 2026-09-09.

Pass · 1. No installation required: The vendor makes the claim itself, twice on its own platform page: the attendee app is "a web app for the smartphone that runs right in the browser, with no app-store download", and "At Converve it is a web app that runs right in the browser, with no install from the app store." Its feature list names the module "Event App (PWA)" and describes it as "the entire event from your smartphone: no download". Corroborated structurally: an Apple search API check on the GB storefront on 2026-09-09 returns no Converve application, the fifteen results carrying the string being translation apps by other publishers, so there is no native app for a feature to be locked behind. Source 1, Source 2, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: No offline claim was found, and no attendee surface is reachable to test: Converve publishes no open demo and the route offered is a sales process. Silence in the vendor's marketing is a fact about the marketing, not about the product.
Unknown · 3. Personalised without a separate account: The vendor documents attendee profiles, a personal agenda and one-to-one meeting scheduling, all of which imply identity, but nothing found states what an attendee has to do to get in. No public help centre for attendees was located and no demo is reachable.
Unknown · 4. Event-scoped lifetime: The app is described as created together with the event website "from a single source", which points at a per-event build rather than a multi-event container, and there is no native container app in the stores. Neither of those establishes what happens to an attendee identity after the event, and no statement about it was found.
Unknown · 5. Installable, but never install-gated: The vendor calls the module a PWA, which implies a manifest, but no attendee surface is reachable to check whether one is served, whether an install gate exists, or whether features differ between the installed and browser paths.

Cvent (Attendee Hub)

Enterprise event management suite. The attendee surface is offered as both a website and a native app. Evidence here is weaker than for other rows: Cvent's support pages could not be read directly and these verdicts rest on cached copies.

Row last verified 2026-09-09.

Unknown · 1. No installation required: A community answer states the website and app are "essentially the same thing", but that is a forum post rather than Cvent's own compatibility documentation, which could not be read. Source, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: The only offline evidence found covers OnArrival, a separate staff-facing check-in tool, not the attendee's agenda or ticket.
Pass · 3. Personalised without a separate account: Login is by emailed one-time code rather than password creation, which is a pass of the weaker kind: no credential is created, but a round trip through an inbox still stands between the attendee and their data. See what a pass on criterion 3 does and does not mean, below the table. Re-read at source on 2026-09-09 and unchanged: an attendee enters first name, last name and email, then "receive an email and text message containing a verification code, or just an email", and enters that code. The same flow is documented for the Attendee Website as for the Event App, so this verdict does not depend on which surface an attendee uses. Source, checked 2026-09-09.
Unknown · 4. Event-scoped lifetime: No documentation found on whether an attendee identity persists across events. The native app is a permanent container install, but the website path is unresolved. Source, checked 2026-09-09.
Unknown · 5. Installable, but never install-gated: Nothing found on installability or gating for the Attendee Hub website.

Eventact

Israeli vendor whose attendee app is a PWA by design, marketed on the same three properties this reference is about: no app store, no download, no password. Added 2026-09-09 from an entrant scan. No attendee surface is reachable: the published demos are marketing walkthroughs rather than live apps, and the only other route is a sales demo, so nothing in this row is tested.

Row last verified 2026-09-09.

Pass · 1. No installation required: "No app store. No download. No password. Just a link", and "the app opens immediately in the browser on phone, tablet, or computer", with programme, people, content, meetings and live sessions all named as available from that same app. Corroborated independently rather than taken on the claim alone: the Apple search API, GB storefront, returns no Eventact app of any kind, so there is no fuller native version for the browser one to be a cut-down preview of, which is this criterion's second fail condition. Not tested, because no live attendee app is reachable. Source, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: The vendor's event app page does not mention offline behaviour at all, in either direction, and no reachable attendee surface exists to test one. Being a PWA is not evidence of offline capability: the two platforms in this table shown by testing to cache no event data are both PWAs. Source, checked 2026-09-09.
Pass · 3. Personalised without a separate account: "Attendees enter using a personalized link, one-time code, or event code - no password", and "no password to create, remember, or reset". A personalised link resolving without a password is the pattern this criterion is written to permit, and it is the same basis on which Swapcard passes. Qualified twice: the one-time-code route does mean fetching a code from an email, and an "event code" is shared rather than personal, so which route an attendee actually gets is the organiser's choice and is not stated. Source, checked 2026-09-09.
Unknown · 4. Event-scoped lifetime: The installed-application limb is clear: there is no Eventact app in the Apple store, so nothing persists as an install. The rest is unmeasured. No statement covers what the app leaves on the device or how long an identity lasts, and with no reachable attendee surface it cannot be measured the way Sessionize and LineUpr were. Not scored pass on the absence of an account claim: "no password" is not "no account". Source, checked 2026-09-09.
Unknown · 5. Installable, but never install-gated: "Attendees can add the app to their device if they choose, without going through an app store", which states that installation is optional but says nothing about the two things this criterion fails on: whether any feature is unlocked by installing, and whether the prompt blocks use before it is dismissed. That second one is only ever settled by opening the app, which failed Sessionize and passed EventApp.pl, and it cannot be opened here. Source, checked 2026-09-09.

EventApp.pl

Polish vendor selling a browser-based event app positioned explicitly against app stores. The closest architectural comparison in this set. The vendor publishes a public demo at demo.eventapp.pl that needs no registration, so most of this row is now tested rather than read; where a verdict still rests on the vendor's own marketing, the cell says so.

Row last verified 2026-09-09.

Pass · 1. No installation required: Tested on the vendor's public demo rather than taken from the vendor's claim. On a 390x664 iPhone viewport, About the event, Agenda, Speakers, Directions map and FAQ all render from a URL with nothing installed. The independent Apple search API check on 2026-09-09 found no EventApp.pl app of any kind, so there is no fuller native version for the browser one to be a cut-down preview of, which is the criterion's second fail condition. The personalised surfaces are gated, but behind a sign-in rather than behind a download, so that is criterion 3's problem and not this one. Source, checked 2026-09-09.
Fail · 2. Offline-capable for core functions: Tested rather than read, which resolves the contradiction in the vendor's own copy: one passage said agenda and venue details require connectivity, another said both are saved for offline. Retested on 2026-09-09 because the first test's warming method understated what the service worker keeps. The source serves page navigations network-first and does put each successful page document into the shell cache, so a page the attendee has loaded is afterwards available offline as a document. That changes nothing, because the same source declares NEVER_CACHE = ["/api/", "/trpc/"], which is every data request those pages make. Warmed by loading the event home, agenda and map online as full page loads, then relaunched with the network blocked at the proxy below the service worker, each cached document rendered and then reported its own failure: the agenda returned "Nie udało się załadować agendy" ("could not load the agenda"), the map and the event home the same. A page never loaded online falls through to the single offline document. Offline the attendee gets a connection error instead of the agenda, which is the stated fail condition. For anyone retesting: the shell cache holds one entry on a cold profile and grows with every full page load, so its size measures how much has been browsed, not how much works offline. Tested on the vendor's demo, so a customer deployment configured differently could differ. Source, checked 2026-09-09.
Unknown · 3. Personalised without a separate account: Withdrawn from pass on 2026-09-09. The pass rested on one passage of vendor marketing, which the row already recorded as materially weakened by its own "sometimes". Re-quoted on 2026-09-09: the vendor writes "A traditional store app requires downloading, phone storage, and sometimes creating an account. PWA eliminates all of these steps", and the record here had compressed that into a single sentence the vendor never wrote, and a verdict on this site is not settled by marketing copy. The vendor's public demo points the other way on exactly the surfaces this criterion is about: "Sign in to see your table" and "Sign in to join networking and message other attendees", behind a page reading "Enter your email address and we'll send you a sign-in code. If you don't have an account yet, we'll create one for you." Submitting an address does fire the account request and return a code prompt. General event information, the agenda, speakers, map and FAQ, needs no sign-in. Not recorded as a fail, because the criterion is about the link an attendee actually receives and a demo with no ticketing has no such link to test: a customer deployment could issue a per-attendee link that resolves without the attendee verifying anything. That is the fact that would settle this, and it is not reachable from outside. Source 1, Source 2, checked 2026-09-09.
Unknown · 4. Event-scoped lifetime: Tested on 2026-09-09 rather than inferred from the per-event pricing. The installed-application half of the fail condition is clear: the Apple search API returns no EventApp.pl app of any kind, and what the demo leaves on the device is confined to the event's own origin and is negligible, one localStorage key counting visits for the install banner, one session-storage key, no IndexedDB, a single locale cookie and one service worker scoped to that origin. The account half does not clear. An account exists, it is created automatically on first sign-in rather than chosen, and its endpoint sits on the event's own host, which is consistent with event scoping but does not establish it: whether one address signing in at two different customers' events yields one record or two is a server-side fact with no external test, and there is no reachable way to delete it without completing the emailed code. Held at unknown on that limb alone. Sessionize, LineUpr and Ticket Tailor were raised to pass on this criterion under the same standard, and all three have no account at all. Source, checked 2026-09-09.
Pass · 5. Installable, but never install-gated: Previously the only pass on this criterion resting on documentation alone. Now tested, and it holds. The demo serves a manifest with display: standalone, and the install affordance is a fixed banner 370x180 at the bottom of a 390x664 iPhone viewport, roughly a quarter of the screen. It does not disable page scrolling, and a tap at the centre of the screen lands on the app's own content rather than on the banner, so nothing has to be dismissed before the app can be used. That is the distinction that failed Sessionize, whose prompt covers the whole viewport, locks scrolling and intercepts the centre tap. Qualified: the banner is persistent rather than dismissed after a first view, it was still present on a fifth visit in the same profile, so it is a standing invitation rather than a one-time prompt. It is recorded as a pass because the stated fail condition is nagging that blocks use, and this does not block use. Source, checked 2026-09-09.

Eventbrite

Consumer ticketing and discovery marketplace rather than an event app. There is no agenda or venue-map product for attendees, so criterion 2 has little to test against.

Row last verified 2026-09-09.

Unknown · 1. No installation required: Withdrawn from fail on 2026-09-09 by the same audit, and the reason is worth recording as a method note. The fail quoted an attendee as needing to "create an account on the app to access their ticket". That sentence is not in the cited article, which was re-read at source on 2026-09-09, and the article now states the opposite about the surface: attendees access tickets "on the website or mobile app", and are told to "log in to the Eventbrite app or website using the email on their order". The URL still returns 200, so a link-rot sweep could never have caught this. Only re-reading the quotation against the page does. Eventbrite's barrier is the account, which criterion 3 already fails it for, and not the download. No statement of feature parity between the website and the app was found either, so this is unknown rather than a pass, on the same basis as Bizzabo. Source, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: No agenda or venue map exists to test. Apple Wallet passes render offline because Wallet renders offline, which is not evidence about Eventbrite. Source, checked 2026-09-09.
Fail · 3. Personalised without a separate account: A persistent account is created at checkout and required to view the ticket later. Source, checked 2026-09-09.
Fail · 4. Event-scoped lifetime: A standing consumer marketplace identity, with the app persisting across events by design. Source, checked 2026-09-09.
Unknown · 5. Installable, but never install-gated: Withdrawn from fail on 2026-09-09 by the same audit. The recorded reasoning conceded the point against itself: "the gate is account creation rather than installation, but functionality is withheld before use either way." Account creation is neither of this criterion's fail conditions. Adding to the home screen was never shown to unlock functionality, and the app was never observed to nag for installation before allowing use, and the cited article now documents the website as an equal path to the ticket. Gating by sign-in belongs to criterion 3, which is how it is treated for EventApp.pl, whose personalised surfaces sit behind a sign-in rather than behind a download. The same rule is applied here. Source, checked 2026-09-09.

EventMobi

Event app platform offering a no-download web app alongside a native container app. On documented evidence, the strongest incumbent assessed, and it beats Presso Events on criterion 2.

Row last verified 2026-09-07.

Pass · 1. No installation required: The clearest parity statement from any vendor: web attendees get "the same content and interactive options available through the EventMobi Universal App". The documented exception is push notifications, a delivery channel rather than a feature. Source, checked 2026-09-07.
Pass · 2. Offline-capable for core functions: The only vendor page found anywhere in this assessment that enumerates what caches: "the Home Page, Agenda, Companies and Maps will be cached to the device and will continue to be accessible even once the device goes offline", down to map images and pin drops. The attendee ticket is not named. Source, checked 2026-09-07.
Fail · 3. Personalised without a separate account: Re-sourced on 2026-09-09, verdict unchanged. The sentence quoted here was cited to an article on logging into the Event Space. That URL still returns 200 and still appears in the vendor's sitemap, but the article behind it has been rewritten in place as "Creating Your Login Page" and no longer contains the sentence. The wording survives verbatim in the vendor's attendee-access article: "The first time that a user logs into the Event App, they will be asked to input their email address and to create a personal password that is a minimum of 8 characters, 1 letter, 1 number and a special character." Qualified by what the rewritten article adds, which runs against this verdict: an organiser can now turn off "Require people to log in to view the Event Space" to make the app publicly viewable. That is a setting the organiser chooses rather than the attendee path as documented, and in public mode the vendor states that private chat, session chat, live polls and Q&A remain unavailable without logging in. Source 1, Source 2, checked 2026-09-07.
Fail · 4. Event-scoped lifetime: The Universal App is a permanent container spanning all EventMobi events, entered by event code. Source, checked 2026-09-07.
Pass · 5. Installable, but never install-gated: The parity statement establishes that content and interactive options are not withheld pending installation, with push notifications the documented carve-out. Source, checked 2026-09-07.

InvitePeople

Swedish event management platform whose attendee app was replaced by a per-event PWA. Added 2026-09-09 from an entrant scan. The announcement is dated 2023-05-10, which is old enough that it evidences the architecture rather than the current behaviour, and no attendee surface is reachable to check the difference.

Row last verified 2026-09-09.

Pass · 1. No installation required: "The PWA is designed for the individual event and does not require attendees to download an app from the AppStore or Google Play", with content updated centrally so attendees are not asked to fetch a new version. Corroborated independently: the Apple search API, GB storefront, returns two InvitePeople apps and both are staff tools, "InvitePeople Entrance" (com.invitepeople.entrance-app.ios) and "InvitePeople Leads" (com.invitepeople.lead-scanner). There is no attendee app for the browser version to be a cut-down preview of. Vendor statement dated 2023-05-10; not tested. Source, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: The announcement says "PWAs can work offline or with a poor internet connection". Re-quoted on 2026-09-09: the record here had this as "in general, PWAs can work offline...", which welds together two separate sentences on the page. Either way it is a statement about the technology rather than about this product, and this site does not accept that class of claim: the same reasoning rejected a rival vendor's low-connectivity claim once already. Nothing else addresses offline behaviour and no reachable surface exists to test it. Source, checked 2026-09-09.
Unknown · 3. Personalised without a separate account: Nothing found on how an attendee gets in, in either direction. Source, checked 2026-09-09.
Unknown · 4. Event-scoped lifetime: The installed-application limb is clear: no attendee app exists in the Apple store, only two staff tools. "The PWA is designed for the individual event", and it carries the event's own icon rather than the vendor's, which is consistent with event scoping but describes branding rather than lifetime. Nothing states what is left on the device afterwards or whether an identity outlives the event. Source, checked 2026-09-09.
Unknown · 5. Installable, but never install-gated: Add-to-home-screen is implied by the event-specific icon, but nothing states whether any feature depends on adding it, or whether the prompt blocks use. Untestable without a reachable attendee app. Source, checked 2026-09-09.

LineUpr

German vendor selling a browser-only event app with no native client, positioned explicitly against app stores. Architecturally the closest comparison in this set alongside EventApp.pl. Criterion 2 was tested rather than read, and the result contradicts the vendor's own published claim.

Row last verified 2026-09-09.

Pass · 1. No installation required: "It is a web app! Your guests just need to open the URL in their browser and get direct access to your app without the hassle of installing it." Corroborated in the app itself: no link to either app store appears anywhere in the attendee experience, and the "Get Mobile App" menu item resolves to an instruction to open the same URL on a phone, not to a store listing. There is therefore no native version for the web one to be a cut-down preview of. Source 1, Source 2, checked 2026-09-09.
Fail · 2. Offline-capable for core functions: The vendor claims offline capability, in these words: "The event app also works when there is no internet access available. The web app saves all of the data after the first load and updates as soon as a connection is available again." Re-quoted and re-sourced on 2026-09-09: the sentence recorded here before, that content is cached locally once the app has loaded once, is not the vendor's wording and was cited to the demo app rather than to the page that carries the claim. Tested against the vendor's published demo app at event-app-demos.lineupr.com, the claim does not hold. After opening the app online and visiting Schedule, Lineup, Locations, Information and Sponsors, each of which rendered content, the service worker's data caches were still empty: only the 67-file application shell was stored. Relaunched with the network blocked at the proxy, the shell loaded and the page title appeared, but the body rendered zero characters. Offline the attendee gets an empty frame, which is the same failure recorded against the publisher's own product. Tested on the vendor's published demo app, so a customer deployment with different settings could differ. Source, checked 2026-09-09.
Pass · 3. Personalised without a separate account: No account, password or email is required to open the app or to mark favourites. An anonymous per-device identifier is generated on first open and stored locally, and no login prompt appears when favouriting. A login exists, but it gates only the networking features, messages and contacts. Qualified: LineUpr sells no tickets, so as with Sessionize only the schedule half of the criterion is exercised. Source, checked 2026-09-09.
Pass · 4. Event-scoped lifetime: Resolved by measurement, on the same basis as Sessionize. No permanent installed application: an Apple App Store search returns no LineUpr app, checked 2026-09-09, corroborating the vendor's own "Get Mobile App" menu item resolving to an instruction to open the same URL rather than to a store listing. No account: criterion 3 is a pass, tested. Device-side residue was measured on the vendor's demo app on an iPhone viewport and is scoped to the event by construction: every one of the four localStorage keys is namespaced with the event's own identifier (5fdb27282530ad000739848d), totalling 228 bytes, with a service worker scoped to that event's path and no cookies or IndexedDB. Qualified in the same terms as Sessionize and Presso Events: the residue is left to ordinary browser eviction rather than purged, so this passes on the stated fail conditions rather than on the criterion's fuller wording. Source, checked 2026-09-09.
Pass · 5. Installable, but never install-gated: A manifest is served and the vendor states the icon "can be placed on the home screen without an installation". Re-sourced on 2026-09-09: that sentence is on the vendor's product page, not on the demo app it was cited to. Tested on the demo app at event-app-demos.lineupr.com on an iPhone viewport with the same method used to fail Sessionize: no install overlay, no scroll lock, and a tap at the centre of the screen lands on the app rather than on a prompt. Qualified: no vendor statement of feature parity between the installed and browser paths was found, so this rests on the absence of a gate rather than on a claim of parity. Source, checked 2026-09-09.

Presso Events

UK ticketing and event-app platform built by Presso Network Ltd, which publishes this site. Assessed on the same evidence bar as every other row, and it fails a criterion that EventMobi passes.

Row last verified 2026-09-07.

Pass · 1. No installation required: Vendor: "It is a web app on a link... with nothing to install and nothing to log into at the door." Independently corroborated: an Apple App Store search returns no Presso Events attendee app, so there is no native version for the web one to be a cut-down preview of. Qualified on 2026-09-09 by the audit of existing verdicts: the parity half of this rests on the publisher's own marketing sentence rather than on a test, and no live attendee ticket was opened, which is the same limit already recorded against Presso on criterion 5. What is independently established is only the narrower half, that the App Store check rules out a fuller native version for the web one to be a cut-down preview of. Source, checked 2026-09-07.
Fail · 2. Offline-capable for core functions: The attendee app registers a service worker, but its own source states it is "lightweight by intent... NOT an offline data cache". It is network-first, caches only the static app shell, and explicitly never caches the per-attendee data read. Offline, an attendee gets a working frame with no ticket, no agenda and no map, which is the exact scenario this criterion exists for. Source, checked 2026-09-07.
Pass · 3. Personalised without a separate account: Help centre: the buyer receives "an email with their ticket, a QR code, a six-character check-in code, and a link to your event app... there is no account for them to create." No password and no email round-trip, which is stronger than the Cvent and Bizzabo passes. Source, checked 2026-09-07.
Pass · 4. Event-scoped lifetime: No app store presence, verified independently against Apple's search API, so nothing is installed to persist, and no account exists to find and delete. Qualified: Presso's help centre states the attendee link "does not expire", so this passes on the stated fail conditions while doing less work than the criterion's wording implies. Source, checked 2026-09-07.
Pass · 5. Installable, but never install-gated: A manifest is served with display: standalone and a service worker is registered, so add to home screen is offered. Tested on the same iPhone viewport used to fail Sessionize on this criterion: the install affordance is a static card in the normal page flow, 350x79, with no full-screen overlay, no scroll lock and nothing intercepting taps, and it is hidden outright once the app is running standalone. Qualified: the attendee surface needs a real ticket, so this was tested on the app shell rather than on a live ticket. Source, checked 2026-09-07.

Sessionize

Conference speaker-management platform whose attendee schedule app is web-first. It is a schedule app rather than a ticketing platform, so the ticket half of criterion 3 does not apply. Criteria 2 and 5 were resolved by testing a live customer event app rather than from documentation, and they went in opposite directions.

Row last verified 2026-09-09.

Pass · 1. No installation required: The playbook lists "Doesn't require Google Play Store/Apple App Store certification" among the app's properties, and states that it "requires no Google Play Store or Apple App Store certification, and all of your updates are instantly live". Attendees reach it by URL. Re-quoted on 2026-09-09: the record previously appended "to be published or used" to the bullet, which the page does not say. Source, checked 2026-09-09.
Pass · 2. Offline-capable for core functions: Tested rather than documented. A profile was warmed by opening the app once online and browsing the schedule, then the browser was relaunched with all network access blocked at the proxy. The full three-day agenda still rendered, with session titles, times, rooms and speakers, and the app displayed its own "cannot save favorites to server" notice, so it knew it was offline. The schedule is held in localStorage, 588 KB on the event tested, and a service worker serves the document shell. Qualified three ways: the app must have been opened once online first, so a cold first open offline still fails; Sessionize has no ticket and no venue map, so only the agenda part of the test is exercised; and the block must be applied below the service worker, which is why page-level offline emulation reports the opposite result. Source, checked 2026-09-09.
Pass · 3. Personalised without a separate account: "The app doesn't require your attendees to log in with a username and password", and attendees can build a personal schedule. There is no ticket concept, so only half the criterion is exercised. Source, checked 2026-09-09.
Pass · 4. Event-scoped lifetime: Resolved by measurement rather than by documentation, because the absence of a vendor statement was what held it at unknown. Both stated fail conditions are cleared. There is no permanent installed application: an Apple App Store search returns no Sessionize app of any kind, attendee or organiser, checked 2026-09-09 against the same search API used on Presso Events. There is no account: criterion 3 is a pass on the vendor's own statement that no username and password is required. What the app does leave device-side was measured on a live customer event on an iPhone viewport, and all of it is confined to that one event's own origin: 590 KB of localStorage under kcdc2026.sessionize.com, a service worker scoped to that host, three cache entries and no cookies or IndexedDB. Qualified: per-event browser storage is not actively purged when the event ends, it is left to ordinary browser eviction, so this passes on the stated fail conditions while doing less work than the criterion's wording implies. That is the same qualification recorded against Presso Events, and it is recorded here for the same reason. Source, checked 2026-09-09.
Fail · 5. Installable, but never install-gated: Installable, but install-gated on first open. A manifest is served with display: standalone, and the vendor suppresses the browser's own install banner with preventDefault, then shows its own instead. On an iPhone viewport the first open renders a fixed overlay across the whole 390x664 viewport with an "Add to Home screen" sheet above it, sets body scrolling to disabled, and intercepts a tap at the centre of the screen. The attendee must dismiss it before using the app, which is the stated fail condition. Same behaviour on the vendor's demo app and on a live customer event app. Source, checked 2026-09-09.

Swapcard

Event networking and matchmaking platform with a native app and a full browser web app. The most passwordless-first platform assessed.

Row last verified 2026-09-09.

Unknown · 1. No installation required: The attendee help centre treats web as a first-class path with a maintained web-app section, but no explicit parity statement was found in either direction. Recorded as unknown rather than pass, for consistency with how Bizzabo and Brella were scored on the same absence of evidence. Source, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: The only offline documentation covers SwapAccess, a separate staff badge-scanning tool. Nothing found on the attendee's own agenda or ticket. Source, checked 2026-09-09.
Pass · 3. Personalised without a separate account: "Upon registering for an event, an account is automatically created for you", with magic-link or one-time-code login. A password is optional, so no credential is created for the attendee to set or remember. A pass of the weaker kind: where the route used is an emailed code, a round trip through an inbox stands between the attendee and their data. See what a pass on criterion 3 does and does not mean, below the table. The account itself is why this platform fails criterion 4. Source, checked 2026-09-09.
Fail · 4. Event-scoped lifetime: Re-sourced on 2026-09-09, verdict unchanged. Two things previously recorded here are gone from the cited article, which has been rewritten: the words "Participants have one set of login credentials across all events", and the claim that an account is deleted only after three consecutive years of inactivity. The verdict rests on what the article says now. An account is created for the attendee by the act of registering, "whether you created the account yourself or it was made for you during event registration", and it is scoped to the platform rather than to the event, so deleting it means "you will no longer have access to any events or saved data on Swapcard". Deletion is now self-serve and immediate, which is better for the attendee than the inactivity window previously recorded, but the account still outlives the event unless the attendee goes and removes it. Source, checked 2026-09-09.
Unknown · 5. Installable, but never install-gated: No documentation found on add-to-home-screen behaviour or gating for the web app.

Ticket Tailor

Organiser-side ticketing platform that explicitly does not require buyers to hold accounts. Not an event app: no agenda and no venue map, so it scores narrowly rather than badly.

Row last verified 2026-09-09.

Pass · 1. No installation required: Re-sourced on 2026-09-09, verdict unchanged. The sentence previously quoted here, that you do not need an account to buy a ticket from an organiser, is not present on the FAQ collection it was cited to, which is organiser-facing throughout. The vendor's buyer-facing article carries the substance instead: a ticket buyer is told to "Get a secure email link to log into self-serve where you can manage your tickets", which is a browser URL with no account to create and no application to install. The Ticket Tailor app in the stores is the organiser's check-in scanner, "Built for Event Creators", not an attendee app. Source 1, Source 2, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: The documented offline capability belongs to the organiser's check-in app. Wallet passes carry the same caveat as Eventbrite: that is Apple's offline behaviour.
Pass · 3. Personalised without a separate account: No account or password is required. The ticket arrives by email and is managed through a self-serve link. Source, checked 2026-09-09.
Pass · 4. Event-scoped lifetime: Both stated fail conditions are cleared on evidence, where previously only one was. The account half was already sourced: no buyer account or password is required, and the ticket is managed through a self-serve link. The installed-application half is now corroborated independently rather than asserted: Ticket Tailor publishes one app, which carries the bundle identifier com.tickettailor.checkinapp and describes itself as the check-in app "Built for Event Creators", checked 2026-09-09. There is no attendee app to persist. Qualified more heavily than the other passes on this criterion: the attendee surface is an emailed ticket link that could not be reached without buying a stranger's ticket, so what that page leaves device-side is untested. This rests on the two fail conditions being cleared, not on a measurement. Source, checked 2026-09-09.
Unknown · 5. Installable, but never install-gated: Nothing found on add-to-home-screen for the attendee ticket page.

vFairs

Virtual, hybrid and in-person platform offering a shared container app and a white-labelled per-event app. Notable for openly documenting the per-event app as a premium add-on rather than the default.

Row last verified 2026-09-09.

Unknown · 1. No installation required: Withdrawn from fail on 2026-09-09 by an audit of verdicts that were already in the table rather than being proposed. The fail rested on the vFairs mobile event app page presenting the native app as the feature-complete surface with no web equivalent claimed. The second half of that is wrong. vFairs documents an attendee-facing web platform throughout its help centre: a leaderboard quiz is "accessible both in the mobile app and on the web platform", and seat reservation controls are described as shown on, and hideable from, the web platform's sessions listing. What is not documented anywhere found is whether that web platform reaches every feature the Unified App does, which is the question this criterion actually asks. That is the same evidentiary position as Bizzabo, recorded there as unknown, so it is recorded as unknown here. The previous verdict was an inference from what a marketing page did not say, which is the class of evidence this table rejects everywhere else, and it ran in the direction that favours the publisher of this site. Source, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: Withdrawn from fail on 2026-09-09 by the same audit. vFairs does document offline access, but only as a capability of the installed native app: "vFairs' mobile event app supports offline access to key features like agendas, maps, and saved session data." The previous fail converted that into a fail of this criterion by way of the criterion 1 fail, and that criterion 1 fail has now itself been withdrawn, because an attendee-facing web platform is documented. What the web platform does with the network off is not stated by the vendor and could not be tested, because vFairs publishes no attendee app that opens from a link. Unknown rather than fail, on the same basis as every other platform here whose attendee surface could not be reached. Source, checked 2026-09-09.
Fail · 3. Personalised without a separate account: Re-sourced on 2026-09-09, verdict unchanged. The evidence previously recorded for this fail, that registration creates email-and-password credentials and the sign-in page requires them, was cited to the mobile event app marketing page, which does not mention a password, a sign-in or a login anywhere. The verdict survives on the vendor's own attendee instructions instead: to get into the Unified App an attendee is told to "enter the email address associated with your event registration", then "enter your password", then log in. Qualified twice, and both qualifications were checked against their own articles on 2026-09-09 rather than the page linked here, which does not contain them: the vendor documents a per-attendee magic link that lets a user "bypass the standard login process", in "How to generate a magic link", and a "Require Attendees to Set Password on First Login" setting, in the article of that name, which is a toggle the organiser enables rather than the default. Both are routes the organiser has to choose, which is the same shape as Brella, where one-click authentication exists but is documented as something the organiser must turn on, and it is recorded the same way here. Source 1, Source 2, Source 3, checked 2026-09-09.
Fail · 4. Event-scoped lifetime: The container app is a permanent multi-event install. The white-label option is a per-event native build, closer in spirit, but still a persisted install the attendee must delete. Corroborated 2026-09-09 by the vendor's own attendee instructions, which give the Unified App a documented path for the case where one email address is registered for several events, so the install is expressly not scoped to one. Source, checked 2026-09-09.
Unknown · 5. Installable, but never install-gated: Withdrawn from fail on 2026-09-09 by the same audit. The fail rested entirely on the full feature set being marketed as mobile-app capability with no stated web equivalent, from which installing was read as effectively required. vFairs does document an attendee web platform, so that premise is wrong. Neither stated fail condition has been shown to hold: adding to the home screen unlocking functionality was never tested, and nagging for installation before allowing use was never observed, because no vFairs attendee surface can be opened without being registered for a real event. Whether the Unified App unlocks anything the web platform withholds is not stated either way, which is unknown, and is exactly how Bizzabo is recorded on identical evidence. Source, checked 2026-09-09.

Whova

Conference engagement app with a native mobile app and a browser-based Web Portal. Its offline mode is a genuine strength, and it sits behind a mandatory persistent account.

Row last verified 2026-09-09.

Fail · 1. No installation required: Tested 09/09/2026: on a phone no feature is reachable from the URL at all. A phone user agent is redirected out of the Web Portal to a page telling the attendee to open the link on a desktop or laptop, or to download the native app. Whova's FAQ scopes the Web Portal to "tablet, laptop, or desktop". This supersedes the earlier rationale for the same verdict, which rested on business card scanning being presented as a download-only feature; the portal being unavailable on phones is the stronger and more directly testable ground. Source, checked 2026-09-09.
Unknown · 2. Offline-capable for core functions: Downgraded from pass on 09/09/2026 for consistency with vFairs, which fails this criterion on the same fact pattern. The evidence for the pass was a vendor page titled "Can Attendees Use the App without Internet Connection?", and Whova's "app" is the native one: the Web Portal does not run on a phone at all, as recorded on criteria 1 and 5, so that page cannot be describing the browser path. Tested what could be tested: across three separate events the desktop Web Portal redirects to a sign-in wall that registers no service worker, no CacheStorage and no manifest, and a page with no service worker cannot serve anything offline. That is pre-login, and the authenticated app could register one, which is why this is unknown rather than fail. Completing the test needs a Whova account on a live third-party event, which is not something this assessment will create. Recorded as unknown rather than fail deliberately: fail is the reading that would favour the publisher, and it is not the reading the evidence supports. Source, checked 2026-09-09.
Fail · 3. Personalised without a separate account: Explicit account creation. The vendor's web portal instructions tell the attendee to click "Sign Up Here", then to "Enter your name, email address and create a password". Re-quoted on 2026-09-09: the record previously ran those two steps together as a single quoted sentence that does not appear on the page in that form. Source, checked 2026-09-09.
Fail · 4. Event-scoped lifetime: The account is platform-wide and persists until the attendee emails support to request deletion. The app is a single container listed permanently in the App Store. Source, checked 2026-09-09.
Fail · 5. Installable, but never install-gated: Tested 09/09/2026 against three separate events. On a phone the Web Portal does not open at all: Whova redirects /portal/webapp/ back to the event landing page and states "You tried to open the web portal on your mobile device. Open the link from your desktop or laptop to access the platform", directly above native app download buttons. The gate is user-agent based, not viewport based, so it cannot be read as responsive layout: iPhone and Android user agents are redirected at any window width, while a desktop user agent loads the portal at 390px wide. Whova's own FAQ scopes the Web Portal to "tablet, laptop, or desktop" and does not list phones. On a phone the attendee therefore cannot reach the product without installing the native app, which is the stated fail condition of nagging for installation before allowing use. Source, checked 2026-09-09.

Page last updated 2026-09-10. Rows are re-verified a few at a time, so each row carries its own date above and the oldest here is 2026-09-07: a single page-level date would claim checking that did not happen. If a verdict here is wrong, including one that is wrong in the publisher's favour, thecorrections process takes evidence and applies it.