# Web + desktop: the future Arcade platform

Planning decision · October 26, 2026. This is a proposal, not an available download or a delivery
promise. Arcade currently serves browser games and the browser Creator Studio. No Arcade desktop
runtime, installer, native game distribution, cloud-save service or PWA offline library is shipped.

## Recommendation

Keep the website as the instant-play entry point. Add installation as an upgrade for people who
already want to return, create larger projects or keep a library. Build one platform across web,
installed web and desktop, with the same games, creators, projects, identity and review history.

The strongest early desktop advantage is likely **creator productivity**: a selected local project
folder, file watching, large asset libraries, local previews and eventual engine-export workflows.
For players, make installation worthwhile through downloaded games, dependable update management,
controller-friendly navigation and a persistent library. Measure those hypotheses with a small
creator/player cohort before funding a broad client launch.

A launcher alone does not create the network effect. We also need games worth returning to,
creator earnings, discovery, friends, reliable multiplayer, useful tools and safe updates. Steam's
[feature catalogue](https://partner.steamgames.com/doc/features) is useful as a service map: cloud
saves, controller integration, communities and creator content are separate products to build.
They are not delivered automatically by packaging a website.

## Where downloading is a real unlock

| Capability | Browser / installed web | Purpose-built desktop client |
| --- | --- | --- |
| Instant discovery and sharing | Open a game link with no installation | Open the same link in the app when installed, with a web fallback |
| Rich browser games | Existing WebGL/WASM/worker-based games can grow here | Same web runtime initially; no promised FPS gain from a wrapper |
| Offline games and assets | Can cache eligible content; quotas, eviction and background behavior vary | An explicit managed library with disk budgets, resumable downloads, verification and uninstall |
| Larger creator projects | Import/export and permission-based file access depend on browser support | Selected workspace folders, file watching, local asset tools and optional local build services |
| Native engine releases | Browser exports work; arbitrary desktop executables do not run in a page | Separately reviewed Windows/macOS/Linux builds can eventually be downloaded and launched |
| Controllers and OS integration | Gamepad, fullscreen and permissions already cover many needs | Plan consistent library navigation, shortcuts, notifications and opt-in presence integration |
| Accounts, saves, friends, matchmaking | Can be shared online services | Use those same services; installation does not supply them |
| Competitive integrity and money | Requires trustworthy rules and server/chain verification | Still requires those controls; a modified desktop client is not an authoritative result |

PWAs can install and support cached/offline experiences. They are a useful middle stage, not
identical to a native download manager: browsers control storage and service-worker lifetimes.
See [installability](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Making_PWAs_installable),
[offline/background operation](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Offline_and_background_operation),
and [storage behavior](https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria).
Persistent-storage requests can help eligible web apps, but do not promise unlimited permanent storage.

## One platform, three surfaces

1. **Arcade Web:** discovery, instant play, sharing, phones, browser creation and existing wallet flows.
2. **Arcade Desktop:** an optional player library, downloaded web games, game updates, controller UI
   and later curated native builds. First-time players can always try the web-compatible version.
3. **Arcade Studio:** the same three creation modes on web, with an optional desktop workspace for
   bigger projects. Initially this can be a Studio view within the desktop client; split into a
   separate product only if creator/player requirements justify the maintenance cost.

Share content IDs, revision IDs, project ownership, purchases, review states and device support.
Separate the **library/account identity** from the **wallet signer**. A wallet may be linked, but
never require entering a seed phrase or make installing the client silently authorize spending.
Online account linking, device sessions, logout and recovery must be designed before cross-device
saves or ownership claims. Today the studio's wallet login and browser-local game saves do not
provide a complete platform account/cloud-save system.

## How the three creator modes grow

| Mode | Web foundation today | Desktop opportunity | Release requirement |
| --- | --- | --- | --- |
| Prompt | Brief, AI revisions, preview, restore and review | Bigger local asset workspace, longer projects and richer diagnostics | Generated games stay isolated; provider calls/credit charging remain server-side |
| Build together | Editable files plus AI and a copied module bank | File watching, source diffs, map/content tools, external editor interoperability | Detect disk/AI conflicts; show changes and preserve a recoverable revision |
| Code | Browser-source import/edit/export and existing engine upload | Local workspace, engine-export import, package/asset tools and optional CLI | Explicit folder scope; reproducible exports; no arbitrary build execution by default |

A local build process, creator plugin or package install can execute arbitrary code. Treat that as
a different capability from editing a text file. A future trusted build runner needs explicit
approval, bounded permissions and isolation; do not expose shell execution to generated games.

## Shared architecture to plan before building a shell

**Content:** create a versioned release manifest, asset index and immutable content hashes. Model
runtime requirements separately from input methods and device support: web, desktop-web and
reviewed native builds; OS/architecture; minimum runtime/SDK; assets; storage budget; permissions;
offline eligibility; save schema; and optional server dependency. These fields are proposed, not
accepted upload APIs. Existing SDK modules and games continue to work through a compatibility layer.
Keep mobile/desktop input declarations separate from runtime availability: a desktop browser game
and a Windows executable are different targets. Native-only titles must be labeled accordingly;
offer an instant web demo only when one exists. Do not promise that one engine export runs everywhere.

**Delivery:** keep review approval separate from publication and download. Add verified downloads,
quota checks, interruption/resume, atomic activation and a last-known-good version. Pinned hashes
prove integrity only when rooted in a trusted signed manifest. Signing does not prove code is safe.
Design revocation and rollback of a compromised release; do not allow downgrade to a revoked build.
The app updater and a game's content updater are separate release channels.

**Saves:** define per-game namespaces, schema versions, migrations, backups and conflict handling
before adding cloud sync. Offline play may create multiple valid divergent saves; do not silently
overwrite one with the newest timestamp. Server-owned balances, entitlements and competitive scores
remain separate from editable local game state. A desktop game and its web demo can share saves
only if their schema and actual gameplay are compatible.

**Runtime:** run community web games in isolated game renderers without native APIs or platform
credentials. A small trusted host brokers only approved capabilities. The existing iframe-only
boundary is not, by itself, a finished desktop security design. Isolate storage between games,
validate the initiating game/version and every host message, constrain navigation/network access,
and require platform-owned consent for sensitive actions. Do not grant a whole remote origin
filesystem or shell access. Native executables form a separate, higher-trust distribution lane;
launching a process is not a guarantee that it is sandboxed.

**Wallets and AI:** keep API keys, credit accounting, receipts and transaction authorization outside
creator code. Validate an external-browser/wallet connection path; do not assume an embedded runtime
contains the user's Phantom extension. Bind sign-in callbacks to short-lived, single-use requests,
validate origins/return destinations and handle cancellation, replay and wrong-wallet responses.
Offline game play never queues automatic trades, purchases, wagers or payouts. Native hosting does
not resolve wallet safety warnings or authorize unsupported token mechanics.

**Multiplayer:** reuse platform accounts and reviewed server adapters across surfaces. Make rules,
latency, reconnects, content versions and input classes explicit. Persistent worlds require hosted
simulation, state storage, moderation and resource budgets; a desktop client is not a game server.
Keep staging open-join experiments and simulated prize systems private until separately approved.

## Runtime candidates: decide with a prototype

| Candidate | Why test it | What must be proven |
| --- | --- | --- |
| Installable web app / PWA | Lowest divergence from the website; useful installation/offline experiment | Browser/OS installation, cache updates, private-data exclusions, eviction, recovery, offline eligibility |
| Electron | Bundled Chromium may reduce engine differences for our existing browser games | Memory/startup/download footprint; sensor/audio/controller behavior; secure host bridge; runtime patch operations |
| Tauri | System-webview architecture and explicit native capability scopes | Cross-engine compatibility, especially macOS WebKit; recording/voice/camera/game APIs; embedded-content privilege boundaries |
| Custom game runtime / native engine | Potential long-term answer for demanding 3D worlds or engine-specific workflows | A real workload proves web/embedded engines inadequate; portability and creator ecosystem justify a new runtime |

Electron is a **first prototype candidate**, not an approved production dependency. It ships
Chromium/Node/Electron components that must be maintained; remote game content must not have Node
integration. Isolation and sandboxing are baseline requirements, not a substitute for an audit.
See [Electron security](https://www.electronjs.org/docs/latest/tutorial/security).
Tauri uses different [system webviews](https://v2.tauri.app/reference/webview-versions/); its
[capability model](https://v2.tauri.app/security/capabilities/) needs careful review before hosting
untrusted frames. Compare both with representative games and the actual trust boundary, not only
installer size. Avoid promising camera/speech/extension parity with a user's Chrome installation.

## Phased release and explicit exit gates

### A. Web foundations and a small installable-web experiment

Plan capability/release/save manifests, account linking and asset budgets; instrument time to
play and returning-player behavior with appropriate consent. Implement PWA installation and an
opt-in offline library only for reviewed offline-capable games. Cache public static assets;
exclude wallet/auth/session responses, AI jobs, receipts, private previews and reviewer data.
An update must not replace a running game or strand an old client with incompatible assets.

Exit: a defined browser/device matrix passes install, offline launch, storage-full/eviction,
update, logout/shared-device cleanup and recovery. No unsupported game is advertised as offline.
No service-worker or offline changes are included in this planning release.

### B. Private desktop feasibility test

Prototype the trusted shell, an isolated web game and a selected-folder Studio workflow. Test
Windows and macOS first; Linux/handheld support requires its own matrix. Use invited creators and
repeat players. No real-money flows in automated tests; no silent native program execution.

Exit: current action, idle, sensor, SDK, uploaded-engine and multiplayer samples pass. Prove that a
malicious game cannot reach host credentials, arbitrary local files or process execution. Test
loss of connection, crash/restart, permissions, low disk space and signed update/rollback paths.
Record cold start, time to first input, memory, frame times, download/update failures and support
cost. Publish measured tradeoffs before selecting Electron, Tauri or another runtime.

### C. Creator desktop beta and player-library beta

Ship a signed/notarized client through our own controlled distribution, with supported OS targets,
an updater, crash recovery and a clear uninstall path. Add local workspace/asset handling, safe
source synchronization, offline-eligible game downloads and a shared library/account service.
Use staged rollouts and opt-in diagnostics. Follow platform signing requirements at build time.

Exit: a suggested initial cohort is 10 active creators and 50 repeat players over four weeks;
these are proposed planning targets, not a forecast. Pre-register reliability/retention targets
from the web baseline and support budget. Continue only if installed users show repeat use of the
unique tools and no material loss in crash-free sessions, update success or save recovery.
Keep web gameplay and browser creation fully supported; never force installation to open a share link.

### D. Curated native builds and a broader ecosystem

Only after reliable delivery and operations, add reviewed native game releases, permission-aware
creator plugins, controller-first living-room UI, community content packs and richer social tools.
A public executable/plugin marketplace needs its own review, abuse reporting, rollback, signing
and incident response. Purchases, durable ownership, developer payouts and real-token competition
remain separately verified services. Do not enable wagering just because the game runs natively.

## Distribution and business decisions

An Arcade-owned desktop platform and a release on Steam are different plans. Steam's current
[onboarding rules](https://partner.steamgames.com/doc/gettingstarted/onboarding) disallow applications
built on blockchain technology that issue or allow exchange of cryptocurrencies or NFTs. Do not
assume today's token-enabled client can ship there unchanged. Re-check the rules before any store
submission; a web demo or separate compliant release needs its own product/policy assessment.
Native mobile stores are also a separate decision. Keep the mobile web/PWA route while validating
desktop value; do not promise identical payments, token features or content permissions everywhere.

Budget ongoing signing, distribution/CDN, security updates, OS support, download hosting, crash
triage, moderation and customer support. Avoid treating the installer as a one-time wrapper task.
Use one backend/SDK where practical, with capability-gated native features and graceful web fallbacks.

## Work that should come next

1. Design versioned content/runtime/capability and save contracts with legacy-game fallback.
2. Define shared identity/library and cloud-save conflict behavior, independent of the signer.
3. Measure representative web workloads and returning-player/creator needs.
4. Run the small PWA experiment, then a private desktop workspace/runtime spike if warranted.
5. Select the runtime and ship a beta only after security, compatibility, update and product gates pass.

This extends [the creator platform roadmap](studio-roadmap.md). The immediate shipped studio and
module bank remain browser-based. Nothing in this document installs software, changes production
caching or enables native game execution.