Cross-browser architecture report

HTML that survives the network.

A researched guide to offline-first pages on Safari for iPhone, Android browsers, and desktop. It distinguishes portable documents from installed web applications, then defines a durable architecture for both.

Version 1.0 Verified July 21, 2026 Mobile-first No external assets Print-ready

01 · Orientation

Offline is a durability problem.

“Works without service” can mean surviving a temporary network loss, launching after a reboot, retaining edits for months, or remaining accessible after the origin disappears. These are different guarantees.

Conclusion

A browser PWA is a local replica whose storage can be removed. A self-contained HTML file is a portable archive with weaker application semantics. Durable delivery needs both.

1

Content continuity

Core prose, diagrams, citations, and navigation must render without remote fonts, scripts, images, or APIs.

2

Runtime continuity

An installed version must precache its complete application shell and verify that the offline entry point exists.

3

Data continuity

User-created notes and pending actions need durable local storage, export, conflict handling, and recovery.

Current protocol Unknown
Network hint Unknown
Service workers Unknown
Storage estimate Unknown

02 · Survival model

Define the failure you must withstand.

Offline architecture should be selected against explicit failure conditions. “Airplane Mode after first use” is much easier than “first-ever launch with no network” or “retain critical records after browser eviction.”

Behavior under common failure conditions. “Strong” still assumes the artifact or application was provisioned correctly.
Failure condition Hosted PWA Downloaded HTML Native web wrapper
Network disappears after initial load Strong Strong Strong
Origin is temporarily unavailable Strong if fully cached Strong Strong
First launch occurs offline Fails unless preinstalled and provisioned Works if file already exists Works when bundled
Browser evicts site data Can lose cache and database Usually unaffected Usually unaffected
User clears browser data Local replica removed Usually unaffected Application-dependent
Controlled updates Strong Manual replacement Strong
Long-term archival Medium Strong Medium
Reliable background execution Browser-specific Not applicable Strongest

The correct mental model is a layered guarantee. The document layer preserves meaning. The PWA layer preserves interaction. A native layer is reserved for operational guarantees the browser cannot make.

03 · Safari on iPhone

Capable, but lifecycle-sensitive.

Modern Safari supports service workers, Cache Storage, IndexedDB, OPFS, persistent-storage requests, and Home Screen web apps. The main risks are storage lifecycle, installation sequencing, and absent background-sync primitives.

Home Screen behavior

On iOS 26, websites added to the Home Screen open as web apps by default. This improves launch behavior, but installation alone does not create an offline package. A service worker and completed cache population are still required.S1

Storage capacity

WebKit’s modern policy allows browser origins to use a substantial fraction of disk capacity, subject to per-origin and aggregate limits. These are ceilings, not guarantees; every write must handle quota failure.S2S5

Storage isolation after installation

Safari can copy cookies into a newly installed Home Screen app, but it does not copy IndexedDB, Cache Storage, or local storage. The installed app must provision its own offline package after installation.S3

Eviction and persistence

Browser storage is best-effort unless persistence is granted. WebKit evaluates navigator.storage.persist() through heuristics. Home Screen usage improves the durability posture, and Home Screen app domains are exempt from WebKit’s ITP seven-day script-storage cap.S2S4

No portable background-sync guarantee

Background Sync and Periodic Background Sync are not cross-browser baseline features. Safari-compatible designs must replay a local outbox during foreground opportunities rather than depend on a worker running after the app closes.S7S8

Private browsing

Treat private sessions as ephemeral. Stored state is not a durable offline repository and can disappear when the private session ends.S4

1

Install while connected

Add the site to the Home Screen before relying on installed-app storage.

2

Launch the installed instance

The Home Screen app is a distinct storage context from Safari.

3

Provision and verify

Download every required asset, validate package completeness, and show “Available offline.”

4

Test in Airplane Mode

Close the app, disable connectivity, reopen from the Home Screen, and exercise critical flows.

04 · Browser comparison

Build to the portable baseline.

Service workers, Cache Storage, IndexedDB, and foreground retry form the dependable cross-browser core. Chromium-only background capabilities should improve freshness, never determine correctness.

Practical support posture for offline-first application design. Exact API details remain version-dependent.
Capability Safari / iPhone Chrome / Android Firefox / Android Desktop browsers
Service worker + Cache API Supported Supported Supported Supported across majors
IndexedDB Supported Supported Supported Supported
Origin Private File System Supported Supported Supported in current engines Broad modern support
Persistent-storage request Heuristic grant Heuristic grant Browser policy / permission Implementation-specific
One-off Background Sync Do not rely on it Available in Chromium Do not rely on it Mostly Chromium
Periodic Background Sync Unavailable Experimental and heuristic Unavailable Chromium-specific
Large background downloads No portable guarantee Background Fetch in Chromium No portable guarantee Limited availability
Install as application Home Screen web app Strong PWA install flow Install flow available Strongest in Chromium and Safari

Portable baseline

Service worker + Cache Storage + IndexedDB + explicit provisioning + foreground synchronization. Add Chromium background features only as optional accelerators.S6S7S8

05 · Distribution models

Choose an artifact, an app, or both.

The distribution model determines first-offline launch, update control, storage semantics, and archival strength. No single model dominates every requirement.

Model A — Self-contained HTML

Portable archive

A single file contains its HTML, CSS, JavaScript, SVG, content, and essential media. It can be saved, transferred, and opened without the original server.

Best qualities
  • First opening can occur offline.
  • Independent of origin availability.
  • Strong for research reports and archival.
  • Simple sharing through Files or AirDrop.
Material limitations
  • file: is not a portable service-worker deployment.
  • iPhone may use a preview surface with reduced interactivity.
  • Updates require replacing the file.
  • Local-file storage behavior is not a durable contract.

Model B — HTTPS offline PWA

Daily-use application

A hosted application uses a manifest, service worker, versioned caches, and a structured local database. It is installed and then explicitly provisioned for offline use.

Best qualities
  • Controlled caching and updates.
  • Home Screen launch and application identity.
  • Offline search, preferences, notes, and outbox.
  • Same-origin modules and asset loading.
Material limitations
  • Requires a successful provisioning cycle.
  • Browser data can be evicted or cleared.
  • Authentication can block offline startup.
  • Background execution varies by engine.

Model C — Native shell with bundled web content

Operational guarantee

A Swift, Capacitor, or Android wrapper bundles the HTML application and uses native storage, distribution, lifecycle, and background facilities where needed.

Best qualities
  • Guaranteed bundled first launch.
  • Stronger OS-managed persistence and tasks.
  • MDM and enterprise distribution options.
  • Better fit for regulated field workflows.
Material limitations
  • Signing and release overhead.
  • Platform-specific packaging.
  • WebView behavior differs from full browsers.
  • Higher long-term operational cost.

06 · Recommended architecture

One knowledge model. Two delivery forms.

Maintain content separately from presentation. Render the same structured report into a single-file edition and an installable PWA edition, avoiding divergent documents.

Dual-output offline artifact architecture A structured content model flows through a renderer into a self-contained HTML archive and an HTTPS PWA, with optional local state and native wrapping. Structured content model claims · evidence · diagrams metadata · navigation · code Build renderer validate · bundle · version Portable HTML edition single file · archival · shareable core content works without JS Installed PWA edition HTTPS · service worker · IndexedDB verified cache · controlled update

Content contract

Every essential claim, diagram, table, and citation is present in the HTML and does not require a network request to be understood.

Runtime contract

The PWA advertises offline readiness only after all required resources are cached and validated against a versioned package manifest.

Recovery contract

Valuable user state can be exported. Cache loss, quota rejection, and failed upgrades have explicit recovery paths.

Suggested build outputtext
offline-research/
├── offline-first-research.html      # portable, self-contained edition
└── web/
    ├── index.html                   # installed application shell
    ├── manifest.webmanifest
    ├── sw.js
    ├── package-manifest.json        # asset URLs, versions, hashes
    ├── assets/
    │   ├── application.css
    │   ├── application.js
    │   ├── icons/
    │   └── diagrams/
    └── content/
        ├── report-v1.json
        └── search-v1.json

07 · Implementation

Provision explicitly. Update atomically.

Service-worker registration is not proof of offline readiness. The application must download, validate, record, and expose the exact state of its offline package.

Service worker — immutable report strategyJavaScript
const CACHE_VERSION = "offline-report-v1";
const REQUIRED_ASSETS = [
  "/",
  "/index.html",
  "/assets/application.css",
  "/assets/application.js",
  "/content/report-v1.json",
  "/content/search-v1.json",
  "/icons/icon-192.png",
  "/icons/icon-512.png"
];

self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(CACHE_VERSION)
      .then((cache) => cache.addAll(REQUIRED_ASSETS))
  );
});

self.addEventListener("activate", (event) => {
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(
        keys
          .filter((key) => key !== CACHE_VERSION)
          .map((key) => caches.delete(key))
      )
    )
  );
});

self.addEventListener("fetch", (event) => {
  const request = event.request;

  if (request.mode === "navigate") {
    event.respondWith(
      caches.match("/index.html")
        .then((cached) => cached ?? fetch(request))
    );
    return;
  }

  event.respondWith(
    caches.match(request)
      .then((cached) => cached ?? fetch(request))
  );
});

Do not force activation blindly

Unconditional skipWaiting() can combine an old page, a new worker, a changed content schema, and an old database. That mixed-version state is difficult to reproduce and recover.

Install and validate the next package first. Notify the user that an update is ready. Reload into the new page-worker-content set as one controlled transition.

Treat cache creation as a transaction

A package is either complete or unavailable. Record the expected version, required URLs, optional hashes, validation result, and activation status.

A partially downloaded report should not display a misleading “Available offline” badge.

Explicit offline provisioningTypeScript
async function provisionOfflinePackage(
  version: string,
  requiredAssets: readonly string[]
): Promise<{
  persistent: boolean;
  usage?: number;
  quota?: number;
}> {
  const persistent =
    "storage" in navigator &&
    "persist" in navigator.storage
      ? await navigator.storage.persist()
      : false;

  const cache = await caches.open(version);
  await cache.addAll(requiredAssets);

  const missing: string[] = [];
  for (const url of requiredAssets) {
    if (!(await cache.match(url))) {
      missing.push(url);
    }
  }

  if (missing.length > 0) {
    await caches.delete(version);
    throw new Error(
      `Offline package incomplete: ${missing.join(", ")}`
    );
  }

  const estimate = await navigator.storage?.estimate();

  return {
    persistent,
    usage: estimate?.usage,
    quota: estimate?.quota
  };
}
Use each browser storage mechanism for a narrowly defined responsibility.
Mechanism Use it for Do not use it as
Cache Storage Application shell, HTML responses, images, fonts, immutable content packages A queryable domain database
IndexedDB Notes, outbox, content index, package records, structured local state A simple synchronous preference store
OPFS Large binaries, SQLite/WASM files, generated archives, local processing A user-visible file system without export
localStorage Small, non-critical display preferences Large data, transactional data, or important records
Cookies Session hints and HTTP authentication context Offline content or an authoritative data store

08 · Security and synchronization

Local-first must still be rights-aware.

Offline access changes the enforcement boundary. Authentication expiry, logout, device sharing, and cached sensitive content require explicit policy rather than incidental browser behavior.

Offline authentication pattern

  1. Load the local shell before contacting the identity provider.
  2. Read locally retained authorization metadata.
  3. Permit only the offline scope previously authorized by policy.
  4. Disable server-dependent actions.
  5. Revalidate identity when connectivity returns.
  6. Provide a reliable “Remove downloaded data” action.

Security decisions to make explicitly

  • Maximum offline authorization duration.
  • Whether cached content is encrypted at the application layer.
  • Behavior after logout while offline.
  • Protection on shared or unmanaged devices.
  • Remote revocation limitations.
  • Audit and provenance retained locally.
Portable outbox recordTypeScript
interface PendingOperation {
  id: string;                 // idempotency key
  entityId: string;
  baseVersion: string;        // conflict detection
  operation: "create" | "update" | "delete";
  payload: unknown;
  createdAt: string;
  attempts: number;
  state:
    | "pending"
    | "sending"
    | "conflict"
    | "acknowledged";
}

Foreground-first synchronization

Persist operations locally before updating the UI. Retry on application launch, focus, an online transition, or another successful request. Chromium Background Sync can accelerate delivery, but it must not be the only path.S7S9

09 · Validation

Test real failure, not a green icon.

DevTools simulation is useful but incomplete. Validation must cover physical network loss, lifecycle termination, cache corruption, quota pressure, version transitions, and user recovery.

Provisioning
  • First visit while online.
  • Install before package download.
  • Download in Safari, then install, to expose storage isolation.
  • Interrupt download halfway and retry.
  • Validate every required asset before declaring readiness.
Connectivity
  • Airplane Mode.
  • Wi-Fi connected without internet access.
  • Captive portal.
  • DNS failure and TLS failure.
  • Origin timeout and HTTP error responses.
Lifecycle
  • Force-close the browser or Home Screen app.
  • Reboot the phone.
  • Reopen after inactivity.
  • Open while offline from both browser history and Home Screen.
  • Upgrade while the old version remains open.
Storage and recovery
  • Quota request denied.
  • QuotaExceededError during package write.
  • Low-device-storage condition.
  • Website data cleared by the user.
  • Private browsing termination.
  • Export and restore of valuable local state.
Content integrity
  • Remote images, fonts, and analytics blocked.
  • JavaScript disabled or unavailable.
  • Search index absent.
  • Diagram runtime absent.
  • Citation target unavailable.
  • Old and new cache versions coexist.
Success criteria
  • Critical content opens after a reboot in Airplane Mode.
  • No essential request leaves the device during offline use.
  • Pending writes survive process termination.
  • Version transitions do not mix incompatible schemas.
  • Loss of browser data has a documented recovery path.

10 · Artifact standard

A default for future generated reports.

This standard is appropriate for research reports, explainers, documentation, travel plans, reference guides, and presentations that may be used in low-connectivity environments.

A

Portable content core

Single-file HTML. No essential external dependencies. Semantic HTML. Inline SVG. Print support. Core readability without JavaScript.

B

Installable runtime

HTTPS origin. Manifest. Versioned service worker. Explicit package provisioning. Storage diagnostics. Atomic updates.

C

Durability controls

Persistent-storage request. Export. Recovery. Offline authorization policy. Foreground sync. Real-device validation.

Proposed acceptance criteria for generated offline-capable HTML artifacts.
Requirement Portable HTML PWA edition Validation
No essential external dependencies Required Required for cached core Block network requests and review
First launch with no service Required after file transfer Required after provisioning Cold launch in Airplane Mode
Visible readiness state Artifact metadata Verified offline badge Delete one asset and confirm failure
Version and provenance Embedded Embedded and locally recorded Inspect document metadata and package record
Responsive containment Required Required No page-level horizontal scroll at 320px
Recovery from local-data loss Redownload file Reprovision and restore export Clear site data and recover

Final decision rule

Use the browser-only dual-output architecture for documents and non-critical applications. Add a native wrapper or managed local database when offline availability, unsynchronized records, or security controls are operationally mandatory.

11 · Evidence

Sources and provenance.

Sources prioritize WebKit, Mozilla/MDN, and Chrome platform documentation. Browser behavior remains version-sensitive; revalidate before adopting the report as a production compatibility contract.

  1. WebKit Features in Safari 26.0 WebKit · Home Screen web-app behavior on iOS 26 and related Safari capabilities.
  2. Updates to Storage Policy WebKit · Origin quotas, aggregate quotas, standalone web apps, eviction, and persistence heuristics.
  3. WebKit Features in Safari 17.2 WebKit · Cookie transfer and separation of other local storage when a web app is added to the Home Screen.
  4. Tracking Prevention in WebKit WebKit · ITP storage treatment, Home Screen application exemption, and ephemeral private sessions.
  5. Storage quotas and eviction criteria MDN Web Docs · Cross-browser storage quotas, persistence, and eviction behavior.
  6. Service Worker API MDN Web Docs · Secure-context requirements, lifecycle, fetch interception, and offline caching.
  7. Background Synchronization API MDN Web Docs · Limited availability and service-worker synchronization model.
  8. Periodic Background Synchronization API MDN Web Docs · Experimental, non-Baseline periodic background synchronization.
  9. Workbox Background Sync Chrome for Developers · Background Sync integration and fallback behavior for unsupported browsers.
  10. Richer offline experiences with Periodic Background Sync Chrome for Developers · Chromium-specific periodic synchronization constraints and use cases.
  11. Introducing Background Fetch Chrome for Developers · Large, user-visible background download behavior on supporting platforms.
  12. Use Web Apps with Firefox for Android Mozilla Support · Installation workflow for web apps on Firefox for Android.
  13. The File System API with Origin Private File System WebKit · OPFS behavior and storage management in Safari.

Methodology

This report separates observed platform behavior from architectural recommendations. Official engine and platform documentation was preferred. Cross-browser recommendations were constrained to primitives broadly implemented by major browser engines. Chromium-only capabilities were classified as progressive enhancements.

Generated July 21, 2026. The document is intentionally self-contained and uses no remote fonts, scripts, images, or stylesheets.