Skip to content
OpenPWA

OpenPWA Evidence Layers 1.0 position paper

Published By Carey Gill · Editorial process

The OpenPWA Evidence Layers: support, capability and behaviour as separate claims about web platform features. Version 1.0, 2026-10-20 · OpenPWA Editorial Team · Licence: CC BY 4.0.

This is the full position paper behind the OpenPWA Evidence Layers, frozen with version 1.0. The condensed definition, with stable fragment ids for citation, is at /about/evidence/v1.0/. The Chinese edition is at /zh/about/evidence/v1.0/paper/. Markdown download: openpwa-evidence-layers-v1.0.md, SHA-256 f23b1e63109bae469707e0a6c98dc3ab4e26a80e04e76d258437d89d03869c2f.

Status: position paper, not peer reviewed. Drafted by AI agent sessions for the OpenPWA Editorial Team from the team’s own study materials; no per-entry human sign-off, as on the rest of openpwa.net. The worked example rests on device steps that an OpenPWA operator performed on a real iPhone.

Abstract

Section titled “Abstract”

Compatibility tables answer one question well: is a feature supported in a given browser, and since which version. Developers who build installable web apps also need answers to two further questions that a support table is not designed to answer: what can the feature actually do (show me), and how does it behave on a real device, in a specific OS build and launch context, when two settings conflict or a default applies. We propose the OpenPWA Evidence Layers, a framework that treats these as three layers of claim: Support, Capability and Behaviour. Each layer has a native evidence class (documented, demonstrated, measured), and every published claim carries both its layer and the class of evidence actually behind it. Behaviour claims are versioned by OS build and context, dated, reproducible from a published protocol and harness, and backed by raw data with hashes. Behaviour results flow back to the support layer as dated conditions attached to a support row (agrees, adds a condition, differs) without silently overwriting the upstream source. None of the ingredients is new on its own: compatibility data has notes and partial support, conformance suites run tests, demo sites show capabilities, and practitioners publish device notes. What the framework formalises and names is their separation into layers with explicit per-claim evidence grading, the treatment of installed-app and device context as a first-class layer with its own evidence class, the back-filling of support data with dated device conditions, and same-device before-and-after studies across OS upgrades. We define the layers and a decision procedure for assigning claims, set out twelve principles, and apply the framework claim by claim to a single-device study of Home Screen web apps on iOS 18.6.2.

1. The problem: “is it supported?” is not the question developers end up asking

Section titled “1. The problem: “is it supported?” is not the question developers end up asking”

A support table compresses a feature into a cell: yes, no, partial, a version number, sometimes a note. That compression is the table’s strength. It is also the reason a “yes” or a “no” can mislead someone who ships a web app to a phone. The 2026-10-20 OpenPWA study on an iPhone 16 Pro running iOS 18.6.2 (build 22G100) gives five concrete cases. Notebook entries are cited as N01 to N66 [S1].

A “no” that fires. MDN browser-compat-data (BCD) records api.ServiceWorkerGlobalScope.notificationclick_event as version_added: false for Safari on iOS [R1]. A BCD issue opened in April 2024 reports that the event does fire [R2]. On 18.6.2, in a web app added to the Home Screen, notificationclick fired on six of six taps, through both addEventListener and the onnotificationclick property, and focus() on the existing window succeeded (N35 to N40). Every tap had a live window; taps with no live page, which comment 35 on WebKit bug 268797 reports as failing, were not tested [R9]. The property check that a BCD contributor says the collector runs [R2], 'onnotificationclick' in self, was true in a worker controlled by the Home Screen app and false in the same worker controlled by a Safari tab (N03, N18, N34). One explanation, not established by the study, is that the collector read the check in a tab context. The support cell states one value for Safari on iOS as a whole, with no note that separates the two contexts.

Two “yes” cells that collide. BCD lists both <meta name="theme-color"> and the manifest theme_color member as supported in Safari on iOS since 15 [R3, R4]. Neither entry says what happens when a page sets one colour and its manifest another. On 18.6.2 the status-bar strip of a Home Screen app took the page’s theme-color meta over a different manifest theme_color, also inside an existing installed app, and took the manifest value only when the page had no meta (three purpose-built apps, N64 to N65-a). Precedence is a property of behaviour, not of support.

A transition with a moment. WebKit described in Safari 17.2 that cookies are copied from Safari into a web app when it is added to the Home Screen [R5]. On 18.6.2 a first-party cookie set in Safari appeared in a newly added app once and was independent afterwards, while localStorage and IndexedDB were never copied in either direction (N13, N16 to N22). A support table can say “partitioned storage: yes”. A bare support value does not say that one store is copied at one moment and the others are not.

A default that depends on the OS build. A page with no manifest and no icon, added to the Home Screen on 18.6.2, opened in Safari, with Safari’s process, storage and service worker, navigator.standalone false and display-mode: browser (N23, N63). WebKit’s Safari 26.0 notes say that from iOS 26 every site added to the Home Screen opens as a web app by default [R6]. The same page and the same tap are therefore documented to behave differently across OS builds; our iOS 26-or-later run is still to come. A version number in a support row for “manifest” does not capture this; a dated, build-stamped observation does.

A lifecycle nobody tabulates. After the user swiped the app away in the app switcher, the document from the previous launch was still alive about six seconds later, clients.matchAll() found it, and the web-app process id survived a swipe in an earlier step (N16, N38, N40). Whether this is a guarantee, a race or an artefact of the debugging connection is a question for more runs. It is the kind of fact that decides whether a notification handler should call focus() or openWindow(), and none of the compatibility sources we read records it.

The pattern across the five cases: the support layer is mostly right about what it claims, and the risk comes from reading it as a claim about behaviour. The fix is not a bigger table. It is to keep the two kinds of claim apart, label each with the evidence behind it, and connect them explicitly.

2. The three layers

Section titled “2. The three layers”

A claim is a single statement about a web platform feature that a reader could act on. Each claim belongs to exactly one layer, decided by the question it answers, and carries one evidence class, decided by what actually backs it (section 3).

Layer 1, Support Layer 2, Capability Layer 3, Behaviour
Question Is it supported, and since which version? What can it do? Show me. What exactly happens on this device, OS build and context?
Typical form “Safari on iOS 16.4+ supports the Push API in Home Screen web apps.” “This page requests notification permission and shows a notification. Try it.” “On iOS 18.6.2 (22G100) a Home Screen app’s status-bar strip takes the page’s theme-color meta over the manifest theme_color.”
Allowed evidence classes documented demonstrated measured (native) or documented
Native sources Specifications, vendor documentation and release notes, BCD A runnable demo that exercises the feature A dated run of a published protocol on a named device
Unit feature × browser × version range feature × demo behaviour × device × OS build × context × date

2.1 Layer 1, Support

Section titled “2.1 Layer 1, Support”

Claims of presence, absence, partial presence, flag status or removal of a feature in a named browser and version range, as stated by a source. Availability conditions that the source states (“Home Screen web apps only”, “requires user activation”) are part of the layer 1 claim, because they bound where the “yes” applies. Layer 1 is documented by definition: OpenPWA does not author support statements, it relays and cross-checks them. When an OpenPWA measurement bears on a support statement, the measurement stays a layer 3 record and is attached to the support row as a relation (section 4).

2.2 Layer 2, Capability

Section titled “2.2 Layer 2, Capability”

Claims that a feature can accomplish a task, backed by a runnable page that attempts it: requesting permission, setting a badge, sharing a file, receiving a push. The claim is about possibility. Whatever the demo does on a given device is the observation of whoever ran it. A demo run recorded by OpenPWA under the protocol produces a layer 3 record, not a stronger layer 2 claim.

2.3 Layer 3, Behaviour

Section titled “2.3 Layer 3, Behaviour”

Claims about what a feature does under stated conditions:

  • precedence when inputs conflict (page meta over manifest);
  • defaults when an input is missing (a letter tile when there is no icon);
  • context differences (Home Screen app versus Safari tab; a worker controlled by an app versus by a tab);
  • timing and lifecycle (cookie copy at add; a page alive after swipe-away; a permission promise pending until answered);
  • geometry and rendering (viewport 402 × 812, top inset 62 px, strip #161616);
  • pitfalls (a subpath-scoped worker’s push subscription not returned by window.pushManager).

A measured layer 3 claim always names a device, an OS version and build, a context and a date; a documented one carries whatever conditions its source states, often only a version. It is measured when OpenPWA ran it, and documented when a source describes it (WebKit’s Safari 17.2 description of the cookie copy is a documented layer 3 claim until someone measures it).

2.4 Boundary cases

Section titled “2.4 Boundary cases”
  • Feature detection. A presence check such as 'onnotificationclick' in self reported by a source without context is layer 1. The same check run by OpenPWA in a stated context is a layer 3 record; here its result depended on context (true in the app’s worker, false in the tab’s), and that is exactly what the support row lacked.
  • A version number from a run (“works on 18.6.2”) is a layer 3 claim about one build. It does not establish version_added, which needs a source or a run on the earlier build.
  • Limits and performance (quota sizes, timing budgets): layer 1 when a vendor publishes the limit, layer 3 when measured.
  • A demo that fails on the reader’s device is the reader’s observation. It becomes an OpenPWA claim only when reproduced under the protocol.
  • Mixed statements (“supported since 16.4, and fires only in Home Screen apps”) are split into one claim per layer.

2.5 Decision procedure

Section titled “2.5 Decision procedure”

Apply in order; the first “yes” decides.

  1. Does the claim say what happens when the feature is used, or how its result depends on device, OS build, launch context or state: values, precedence, defaults, timing, lifecycle, rendering, prompts? Layer 3. Then: did OpenPWA run it under the protocol (measured), or does a source state it (documented)?
  2. Does it say that the feature can do a task and point to a runnable page, with no recorded run? Layer 2, demonstrated.
  3. Does it say whether, where or since when the feature is available (presence, version, flag, partial, a source-stated availability condition)? Layer 1, documented. If the claim came from an OpenPWA run rather than a source, go back to step 1: it is a layer 3 record attached to the row.
  4. Otherwise it is not a platform claim (advice, history, opinion). Label it as such or remove it.

3. Evidence classes and grading

Section titled “3. Evidence classes and grading”

This section defines what can back a claim and how measured results are graded.

3.1 The three classes

Section titled “3.1 The three classes”

Documented. A source outside OpenPWA states the claim: a specification, vendor documentation, release notes, a vendor engineering post, a vendor bug tracker, or BCD. Shown with the source and the date it was checked. BCD rows are documented even where BCD’s own data came from automated collection, because OpenPWA did not observe them. Third-party notes (practitioner blogs, forums) are documented with lower confidence, under the site’s existing high, medium and low rule [S2]. A documented layer 3 claim is shown as Documented by <source>; not measured by OpenPWA, so it is never read as a measurement.

Demonstrated. A runnable OpenPWA demo exercises the capability. Shown with the demo link and wording that invites the reader to try it on their own device (“Try it”). A demonstrated label asserts that the demo exists and is designed to exercise the feature. It never asserts that the feature works on any particular device.

Measured. An OpenPWA run of a published protocol on a named real device recorded the result. To qualify, a run needs all of the following:

  • Environment block: device marketing name and model identifier, OS version and build, release channel, browser version, language and region, non-default feature flags, content blockers or VPN state, and the inspecting host if one was used.
  • Date and time with time zone, for the run and for each read.
  • Context: tab, Home Screen app, or both; fresh state or not; first launch or relaunch.
  • Protocol and harness: the test id, the published steps, and the harness version with a SHA-256 hash for each file the run loaded.
  • Expectation in advance: the expected result and its source, recorded before the step (in a checklist or the notebook; not in a public registry).
  • Raw data: the instrumented reads as files, screenshots and recordings, each listed with a hash.
  • Verdict: as-expected, differs, inconclusive or could-not-run.
  • Confidence label (3.2).

These are the requirements for v1.0. The 18.6.2 study ran before they were written and does not meet all of them. Its gaps [S1]: raw reads carry tool-hash sidecars only from N15 onwards; run-time snapshots of the served harness exist for lab.js, sw.js and the T7 files but not for every page, so the other files are identified by their repository version at the deployed revision; and the environment record lacks feature flags, VPN and iCloud Private Relay state, the identity of an installed Safari Web Extension, and the Settings language and region.

3.2 Confidence labels within measured

Section titled “3.2 Confidence labels within measured”
Label Meaning Published as measured?
A, instrumented read (agent-measured) An instrumented read of page state: a published probe script’s output, captured over a debugging protocol (for example the WebKit remote inspector) and stored verbatim as JSON. “Agent” names who ran the probe; the value is the probe’s output, not a model’s interpretation Yes
S, screenshot or recording A capture analysed afterwards (pixel values, video frames, capture times) Yes
O, observer report The operator’s verbal report only No. Kept in the notebook; may support an A or S result, never stand alone

Labels combine: “A+S” means an instrumented read and a capture agree; “S+O” means a capture with the operator’s report as context. A result is published with its weakest essential component named; for example, the 18.6.2 status-bar colour source is S+O, because the pixel evidence is S and the identification of which app was on screen rests partly on the operator.

3.3 Dating and reproducibility

Section titled “3.3 Dating and reproducibility”

A measured claim is true of one build on one device on one date. It is never generalised across builds by wording (“iOS 18 does X”). It is reproducible when another person with the same device class and OS build can follow the protocol, load the same harness bytes (checked by hash), and compare against the raw data. Same-device reruns after an OS upgrade compare like with like: same hardware, same installed apps, same harness files, with the upgrade as the intervention.

Reproduction has a limit: the study’s report notes that once the test phone is upgraded to iOS 27, its iOS 18.6.2 results can be re-measured only on another device still on that build. This is why the raw data matters more than the prose. When nobody can repeat the run, the published reads, captures and hashes are the only way to audit it.

4. How the layers relate

Section titled “4. How the layers relate”

The layers stay separate and are linked by explicit relations.

4.1 Layer 3 conditions layer 1

Section titled “4.1 Layer 3 conditions layer 1”

A behaviour result is attached to the support row it bears on, with one of three relations:

  • agrees: the measurement matches the row (badge shown on the Home Screen icon after setAppBadge(3); BCD says Badging is supported).
  • adds-condition: the row holds under a condition the source does not state (Declarative Web Push: window.pushManager also exists in a Safari tab, and in two Home Screen apps whose subpath-scoped worker held a push subscription, window.pushManager.getSubscription() returned null).
  • differs: the measurement contradicts the source (notificationclick fires in Home Screen apps where BCD says unsupported).

The row keeps its source, status, version and confidence. The relation and its condition are shown in the row, dated and linked to the run. This is what “back-filling” means in this framework: support data gains dated device conditions; it is not rewritten by them.

4.2 Resolving and displaying conflicts

Section titled “4.2 Resolving and displaying conflicts”

A differs relation is a finding, not an error to be hidden. It is shown in the row as Differs from <source>, with the condition and the run date. It goes on a discrepancy list, where it becomes a candidate for an upstream report (a BCD issue, a WebKit bug). The row’s status changes only if an upstream source changes, or if OpenPWA publishes a rule under which a measurement may set status (not in v1.0; see P8). When a later run differs from an earlier one, both stay visible, each with its build; the newer run does not erase the older.

4.3 Layer 2 connects the other two

Section titled “4.3 Layer 2 connects the other two”

A demo is where a reader can turn a support claim into a personal check, and where a behaviour test often starts. It does not settle either. The framework keeps it in its own layer so that “it ran on my phone” is never mistaken for “OpenPWA measured it” or “the vendor supports it”.

5. Principles

Section titled “5. Principles”

P1. Every claim has a layer and an evidence class. Readers can see both, in text, not only by colour.

P2. Classes are never upgraded by wording. “Tested”, “verified on device”, “in practice” and their Chinese equivalents are reserved for published measured runs.

P3. Behaviour is versioned per OS build and context. A behaviour claim names device, OS version and build, context and date. Different builds give different rows.

P4. Measurements are dated, reproducible and come with raw data. Protocol, harness version and file hashes, environment block, raw reads and captures, all published in sanitised form.

P5. Expectations are written before the step. The expected result and its source are recorded first. “Differs from expected” is a finding.

P6. Records beat reports. When an operator’s report conflicts with a read or a capture, the record is preferred and the conflict is logged as an anomaly. Observer-only results are never published as measured.

P7. Corrections are append-only. A wrong entry is corrected by a new dated entry that cites the old one. Retracted readings are listed as “do not cite” next to the result they were retracted from.

P8. Layer 3 conditions layer 1; it does not silently overwrite it. In v1.0 a measurement never changes a support row’s status, version or confidence. Any future rule that lets it do so is published as a new version of this framework before it is applied.

P9. Scope is stated. Sample size (devices, builds, runs), what was not tested and known threats to validity are part of every result.

P10. Novelty is checked, replication is labelled. A result that confirms a published description is labelled a replication and cites the description. Only results with no prior description found are called new, and the search is described.

P11. The observer protocol protects the record. When a person operates the device and an instrument reads it, the protocol rules are part of the method. Define every term before using it (for example, “the status bar” means the strip with the time and battery). Ask one question per message. Confirm a step was done before asking for its result. Leave the screen untouched for 20 to 30 seconds while an instrumented read runs. Do not write test markers through browser automation: in the 18.6.2 study the safaridriver automation window had its own website data, separate from the owner’s Safari profile, so a marker written there would not be where the test looks (N06).

P12. Harness bytes and installed apps are frozen between comparable runs. A harness version is never moved, redirected or edited once a run has used it, except to fix a privacy or security defect, which is published as a dated erratum with the old and new hashes; new versions get new, non-overlapping scopes. The test apps installed for a before-and-after study keep their scope and start URL until the after run is done.

6. Application to openpwa.net

Section titled “6. Application to openpwa.net”

The framework is being built into the structure of the site’s evidence. The definition page, its frozen version pages and change history, the Device Lab with its behaviour pages, and the study with its data package [S1] are published with v1.0. The compatibility-table badges and the reference-page evidence strip are planned; each will be listed in the site changelog when it ships.

  • Definition page. /about/evidence/ (and /zh/about/evidence/) publishes this framework in site voice, with frozen version pages and a change history.
  • Compatibility tables (planned). The matrix keeps its shape. Rows with measured evidence will carry a “Device-tested” badge and a numbered, dated footnote with the relation (“Measured 2026-10-20, iPhone 16 Pro, iOS 18.6.2 (22G100): fires in Home Screen apps through both registration paths. Differs from BCD.”). The caption will carry a legend naming the three layers and their classes.
  • Reference pages (planned). An evidence strip under the availability banner: Documented (sources and last verified date) · Demonstrated (demo link) · Measured (latest run). Each item appears only when it exists.
  • Behaviour reference pages. One page per behaviour topic (/lab/behaviour/<topic>/) with the question, the steps, per-build results with anchors, what the documentation says, the data, what it backs and its limits.
  • The Device Lab. The public section that produces layer 3: protocol index, run guides, harness versions and hashes, a test roadmap, methodology and threats to validity, and the studies.
  • Studies. Dated papers with data packages, such as the iOS 18.6.2 study [S1], each stating which layer its conclusions belong to.

7. Worked example: the iOS 18.6.2 study, claim by claim

Section titled “7. Worked example: the iOS 18.6.2 study, claim by claim”

Study: OpenPWA device test, 2026-10-20, iPhone 16 Pro, iOS 18.6.2 (22G100) [S1]. Every row is a layer 3 claim except where marked. “L1 relation” is the relation the result would carry on the matching support row. “Prior” says whether a published description existed (P10).

# Claim (18.6.2, Home Screen app unless stated) Layer Class, label Notebook L1 relation Prior
1 A page with no manifest and no icon, added to the Home Screen, opens in Safari with Safari’s storage and worker; display-mode: browser 3 measured, A+S N23, N63 adds-condition (before iOS 26, standalone launch needs the apple-mobile-web-app-capable meta tag or a manifest display value) documented (WebKit 16.4 [R38]; WebKit 26.0 for the change [R6])
2 A manifest app opens standalone in a 402 × 812 viewport; only display-mode: standalone matches 3 measured, A+S N13 agrees (display standalone) documented (confirmation; values added)
3 Icon precedence: 180 px apple-touch-icon over manifest icons; manifest any 192 otherwise; letter tile without icons 3 measured, S N11, N63 adds-condition (manifest icons) documented (firt.dev [R8])
4 localStorage and IndexedDB are never copied between Safari and the app, in either direction 3 measured, A N13, N16 to N20 adds-condition (storage partitioning) documented (WebKit 17.2)
5 A first-party cookie is copied once into the new app, then independent; each app has its own cookie store 3 measured, A (copy timing moderate) N18 to N22 adds-condition replication of WebKit 17.2 [R5]
6 notificationclick fires through both registration paths, 6 of 6 taps, each with a live window; focus() succeeds. No-window case not tested 3 measured, A N35 to N40 differs (BCD version_added: false) developer reports in BCD issue #22959 [R2]; confirmation with new detail
7 'onnotificationclick' in self true in an app-controlled worker, false in a tab-controlled worker 3 measured, A N03, N18, N34 adds-condition; explains the collector result new as far as we found
8 The permission prompt appears after a tap; requestPermission() stays pending until answered (2068 ms) 3 measured, A+S N53, N54, N58, N59 agrees documented
9 One grant covers both push managers; with a subpath-scoped worker, window.pushManager.getSubscription() returns null. Root-scoped worker not tested 3 measured, A N32, N33, N41 adds-condition (DWP row) consistent with WebKit’s DWP post [R7]
9b window.pushManager exists in a plain Safari tab, where PushManager and Notification do not (exposure only) 3 measured, A N03, N41 adds-condition new as far as we found
10 Default status-bar style: viewport starts 62 px below the top, strip solid #161616, no blur; viewport-fit=cover adds only a 34 px bottom inset 3 measured, A (geometry) + S (pixels) N25 to N29, N62 adds-condition behaviour documented; no public 18.x values found
10c Strip colour: page theme-color meta over manifest theme_color; manifest as fallback 3 measured, S+O N64 to N65-a adds-condition (both theme rows) precedence not stated in the sources we read; not claimed as new
11 black-translucent + viewport-fit=cover puts the page under the status bar: viewport 402 × 874, inset 62 px 3 measured, A (+O appearance) N55 agrees documented
12 setAppBadge(3) shows “3” on the icon; clearing reported only by the operator 3 measured, S (clear: O, not published) N60 agrees documented
13 After a swipe-away, the previous document was alive about 6 s later and found by clients.matchAll() 3 measured, A N16, N38, N40 none (no support row) not checked; needs more runs before any general claim
14 BeforeInstallPromptEvent and navigator.install are absent on this build 3 measured, A study report §T9 agrees (BCD: not supported) documented
15 BCD: Safari iOS notificationclick_event unsupported 1 documented (BCD) n/a (row source) n/a
15b WebKit: cookies are copied into a web app when it is added (Safari 17.2) 3 documented (WebKit [R5]) n/a n/a n/a
16 Push permission demo on /demo/push/ 2 demonstrated n/a n/a n/a
X1 “The status bar was blue / followed the page’s top colour” n/a retracted (N46) N46 do not cite n/a
X2 “theme-color has no effect” and “the app uses the manifest theme_color” n/a refuted (N65, N65-a) N65 do not cite n/a

Three things the table shows. First, every result of the study is a layer 3 record, and only two of them are new as far as we found (7 and 9b). The value of the rest is that they are dated, measured on a named build and reusable as conditions on support rows. Second, the retractions are part of the record: the colour-source question went through two wrong readings before the three-app test settled it, and the framework keeps those readings visible as “do not cite” instead of deleting them. Third, the same feature can sit in all three layers at once (rows 6, 15 and 16), and the same behaviour can be both documented and measured (rows 5 and 15b), each labelled for what it is.

8. Research agenda

Section titled “8. Research agenda”
  • Per-release measurement. Rerun the core tests on each iOS and Safari point release, about one hour per release, and add a dated row per behaviour. Bug-fix releases rerun only tests whose subject the release notes mention.
  • iOS 27 same-device rerun. The second study: the same iPhone, upgraded from 18.6.2, with the same installed Home Screen apps and the same harness v1 bytes. Each behaviour gets a before-and-after comparison across one intervention, the upgrade (time and other device state also change, and the study will record what it can of them). Questions it can settle that a fresh device cannot: whether existing apps keep their storage, cookies, permission and push subscription across the upgrade; whether the manifest-less launch default changes for an icon added before the upgrade; whether the status-bar precedence holds.
  • Gaps from 18.6.2. The clients.openWindow() path when no window exists; cookie copy timing (at add versus at first launch); badge clearing (O only in the 18.6.2 study); Declarative Web Push with a root-scoped worker, which needs a separate origin.
  • Other platforms. Android Chrome and Samsung Internet (install prompts, navigator.install, share target), desktop Chromium (file handling, launch handler), Firefox where Mozilla documents install surfaces, iPadOS (multitasking windows, add sheet).
  • Independent replication. A results format that lets other people submit runs, labelled as community results and kept apart from operator runs.
  • Framework evaluation. Measure how often support rows gain adds-condition or differs relations over a year, and how often a later build reverses an earlier measurement. If the relations stay rare, the framework is overhead; if they are common, the support layer alone is misleading at that rate.

9. Relationship to existing work

Section titled “9. Relationship to existing work”

Every ingredient of this framework already exists somewhere. Sources were read on 2026-10-20; where a page renders only with JavaScript, its repository or data files were read instead.

9.1 Prior work by area

Section titled “9.1 Prior work by area”

Compatibility data. caniuse gives each browser version one value (y, a for partial, n, u, p, x, d) with numbered notes and known bugs; its contribution guide lists a link to test cases among the marks of a good new-feature pull request [R10], and its test suite checks “basic support”, warning that a “test may pass but support is actually buggy” [R11]. BCD support statements carry version_added (a version, false, "preview" or a ranged "≤" value), flags, prefix, partial_implementation and notes [R12, R13]. BCD also allows behavioural subfeatures for “a contextual support condition that is not readily feature detectable”, and it already records installed-context differences: Screen Wake Lock on Safari iOS is partial_implementation from 16.4 up to, not including, 18.4 with the note “Does not work in standalone Home Screen Web Apps” [R14]. BCD updates are assisted by mdn-bcd-collector, which generates feature-detection tests from Web IDL and CSS definitions and runs them as pages in browsers, optionally through Selenium on cloud browser services [R15]. The support layer therefore already carries context, as notes and subfeatures on a version range. It does not carry a test date, an OS build, a device, raw data or a re-test schedule for those notes.

Conformance and interoperability testing. web-platform-tests and wpt.fyi run specification test suites in the major desktop browsers, and Interop scores selected focus areas each year; in Interop 2026, mobile testing is an investigation area, not a scored one, and Mozilla’s announcement notes that a browser can score well “while having inconsistent behavior” [R16, R17]. None of these descriptions covers Home Screen launch, the status bar, icons or permission prompts. The testing literature draws the same line. ISO/IEC 9646 defines conformance testing against a standard’s requirements [R31]; ETSI separates it from interoperability testing and notes that “items passing conformance testing may still not interoperate” [R32]. The W3C QA Framework names the reason a third kind of evidence is needed: specifications contain “discretionary items”, behaviour left to the user agent [R33]. Most of what layer 3 records on iOS (status-bar colour, icon choice, cookie copy, launch default) is of that kind.

Summaries and launch tracking. Baseline (W3C WebDX Community Group, web-features) labels features Limited, Newly or Widely available from BCD, excluding partial implementations [R18]. webstatus.dev combines BCD, WPT and web-features [R19]. Chrome Platform Status tracks Blink launches [R20]. WebKit’s feature status page is retired; Safari release notes remain the vendor record and have “Home Screen Web Apps” sections [R21]. All are layer 1 sources here.

Demonstrations and practitioner notes. whatpwacando.today offers over 40 live demos and shows what the visitor’s device supports [R22]; it is the clearest layer 2 resource and publishes no dated results. Maximiliano Firtman’s iOS PWA notes are the closest content analog to layer 3: they separate installed apps from Safari tabs per feature and record precedence rules such as “apple-touch-icon overrides manifest icons” [R8]. Their evidence is the author’s private testing; methods, devices and raw data are not published.

Context and dated real-client tests. caniwebview (W3C WebView Community Group) adds WebView as a compatibility context, from BCD and hand-written quirk notes [R34]. Steiner (2018) compared PWA feature exposure in WebViews and browsers [R28]. caniemail is the strongest methodological precedent: each feature records a last_test_date, a test_url and a test_results_url, with support split per client and platform, each entry keyed by a client version (Apple Mail 12.4) or a test month (Gmail 2019-02) [R35]. It tests email clients, not browsers, and in the files we read it does not record OS builds or hashes.

Research and measurement at scale. WebDiff, CrossCheck and X-PERT detect rendering and behaviour differences between desktop browsers [R25, R27, R26], as does the work of Mesbah and Prasad [R24]. Early PWA papers assessed the approach for cross-platform development [R29, R30]; the Web Almanac measures how sites use PWA features [R23]; studies of feature use on the web exist [R39]. We found no published empirical study of Home Screen web-app behaviour on iOS with released data. Grading claims by evidence strength is standard elsewhere, as GRADE in medicine [R36] and in software-engineering reviews [R37]; we adapt the idea.

9.2 What is new, and what is not

Section titled “9.2 What is new, and what is not”
Element Closest prior art Our assessment
Recording that support differs by context (installed app vs tab, WebView vs browser) BCD notes and contextual subfeatures [R13, R14]; caniuse notes; caniwebview [R34]; firt.dev [R8]; Steiner [R28] Exists. Not claimed.
(a) Installed-app and device-context behaviour as a first-class layer with its own evidence class, rather than a note on a support statement The same sources, where behaviour appears as notes, subfeatures or unaudited tables Partly new. The content exists; making it a separate layer with its own evidence requirements is, as far as we found, new.
(b) An explicit documented / demonstrated / measured grade on every claim GRADE [R36]; SE evidence grading [R37]; caniuse u and test links [R10] New in web compatibility, adapted from other fields.
(c) Back-filling support rows with dated, OS-build-level, hashed device results as relations (agrees, adds-condition, differs) caniemail dated tests [R35]; mdn-bcd-results raw collector output [R15]; BCD notes linking bugs Partly new. Dated real-client testing exists in caniemail; build-level resolution, device and install context, hashed raw data and the three relations on a browser support table did not appear in the sources we read.
(d) Same-device before-and-after studies across OS upgrades Pre/post repeated measures and regression testing generally; scattered forum reports of upgrade regressions Partly new. The design is textbook; a published, reproducible before-and-after dataset for web-app behaviour was not found. “First published, to our knowledge”, not a new method.
Separating conformance from behaviour in context ISO/IEC 9646 [R31], ETSI [R32], W3C QA Framework discretionary items [R33] Exists. We rely on it.

In short, OpenPWA formalises and names a structure that the field already uses informally. The contribution is that the structure is explicit, graded per claim, context-aware at OS-build level, and auditable from published data. We would welcome a pointer to any earlier source that does all four, and will cite it in the next version.

10. How to adopt and cite

Section titled “10. How to adopt and cite”

Licence. This text is published under Creative Commons Attribution 4.0 International (CC BY 4.0): anyone may copy, translate, adapt or extend it, including commercially, with attribution. Using the framework as a method needs no licence at all; we ask that adopters cite it.

Citation.

OpenPWA Editorial Team. The OpenPWA Evidence Layers: support, capability and behaviour as separate claims about web platform features. Version 1.0, 2026-10-20. openpwa.net. https://openpwa.net/about/evidence/v1.0/

Short form in running text: “OpenPWA Evidence Layers v1.0”. When citing a single definition, add the fragment (for example #p8 or #decision-procedure).

Adopting it. A site or dataset adopts the framework by labelling each claim with its layer and evidence class, publishing the requirements for “measured” that it applies (at least those of 3.1), and naming the version it follows. It need not use OpenPWA’s labels, data model or harness.

Version policy. Major versions change or remove a layer, an evidence class or a principle. Minor versions add principles, boundary cases or display rules. Patch versions fix wording. Every published version keeps a frozen URL (/about/evidence/v<major>.<minor>/), and the change history is append-only.

11. Glossary

Section titled “11. Glossary”
  • Claim: one statement about a web platform feature that a reader could act on.
  • Layer: the kind of question a claim answers: Support (1), Capability (2), Behaviour (3).
  • Evidence class: what backs a claim: documented, demonstrated or measured.
  • Context: the conditions of a behaviour claim: device, OS build, launch context (tab, Home Screen app), state (fresh, after add, after relaunch, after swipe-away).
  • Run: one execution of a protocol on one device and build, on one date.
  • Harness: the set of test pages and apps a run loads, versioned and hashed.
  • Protocol: the published steps, recording fields and environment block for a test.
  • Confidence label: A (instrumented read), S (screenshot or recording), O (observer report).
  • Relation: how a measured result bears on a support row: agrees, adds-condition, differs.
  • Back-fill: attaching a dated measured result to a support row as a relation and condition.
  • Replication: a measured result that confirms a published description.
  • Same-device study: a before-and-after comparison on one physical device across an OS upgrade, with the same installed apps and harness bytes.

References

Section titled “References”

All URLs accessed 2026-10-20. “Repository read” means the page renders with JavaScript and its source data was read instead.

Study and site

Vendor documentation and compatibility data

Research and standards

Appendix: naming

Section titled “Appendix: naming”

Three candidate names were checked on 2026-10-20 by web search for the phrase with web, browser and PWA context.

Candidate Collision check Verdict
OpenPWA Three-Layer Model No use in web compatibility found. “Three-layer” and “three-tier” are standard names for the presentation / application / data architecture, so the bare phrase is generic and hard to search. Usable descriptively (“the three-layer model”), weak as a name
Support–Capability–Behaviour (SCB) model No exact use of the phrase in either spelling. Nearby wording: Australia’s NDIS “Positive Behaviour Support Capability Framework” and the COM-B behaviour-change model. The acronym SCB is heavily taken: Siam Commercial Bank, Standard Chartered Bank, Statistics Sweden, a privileged-access product (“Shell Control Box”) and an IEEE paper titled “Secure Cloud Browser”. Keep the three words as the subtitle; never use the bare acronym
OpenPWA Evidence Layers No use found. “Evidence layers” appears in a 2026 safety-assurance blog post about design, implementation and performance evidence, which is an analogous idea in another field rather than a conflict. Recommended

Recommendation: “OpenPWA Evidence Layers”, subtitle “Support, Capability, Behaviour”. It carries the platform name, so it is attributable and searchable. It names what the framework is about (evidence) rather than a count, so a later version can change the number of layers without renaming. It matches the /about/evidence/ URL. “The three-layer model” stays available as an informal description in prose.

Short labels:

Element EN ZH
Framework OpenPWA Evidence Layers OpenPWA 证据分层
Layer 1 Support 支持
Layer 2 Capability 能力
Layer 3 Behaviour 行为
Class documented 文档记载
Class demonstrated 演示可见
Class measured 真机实测
Row badge Device-tested 真机实测
Confidence A instrumented read · S screenshot or recording · O observer report A 仪器读数 · S 截图或录屏 · O 观察者口述
Relation agrees · adds a condition · differs 一致 · 补充条件 · 不符

Device steps performed by an OpenPWA operator on an iPhone 16 Pro. AI agent sessions read page state over USB, kept the notebook and drafted this text; automated gates and an AI fact-check checked it. No person reviews each entry.

Last verified

Sources

  • github.comhttps://github.com/mdn/browser-compat-data/blob/main/api/ServiceWorkerGlobalScope.json
  • github.comhttps://github.com/mdn/browser-compat-data/issues/22959
  • webkit.orghttps://webkit.org/blog/14787/webkit-features-in-safari-17-2/
  • webkit.orghttps://webkit.org/blog/17333/webkit-features-in-safari-26-0/
  • github.comhttps://github.com/Fyrd/caniuse/blob/main/CONTRIBUTING.md
  • caniemail.comhttps://www.caniemail.com/
  • caniemail.comhttps://www.caniemail.com/features/css-display-flex/
  • github.comhttps://github.com/openwebdocs/mdn-bcd-collector
  • bugs.webkit.orghttps://bugs.webkit.org/show_bug.cgi?id=268797
  • webkit.orghttps://webkit.org/blog/13966/webkit-features-in-safari-16-4/
  • openpwa.nethttps://openpwa.net/research/2026-10-ios18-home-screen-web-apps/data/REPORT.md
  • openpwa.nethttps://openpwa.net/research/2026-10-ios18-home-screen-web-apps/data/

Report a problem · Changelog

© 2026 OpenPWA · Text CC BY-SA 4.0 · Data CC BY 4.0Privacy · RSS · Changelog feed