Capability matrix
Use this page when you need to answer a practical question: can this feature work on the platform I am targeting, and what extra work is required before it behaves like a production feature?
A Fission capability has three separate pieces:
1.
The typed API is what shared app code calls. For example, ctx.effects.camera().capture_photo(...) records a camera request without importing Android, iOS, web, or desktop camera APIs into your reducer.
2.
The provider is the shell-side Rust implementation. It receives the typed request and maps it to the current host: an operating-system API, browser API, hardware SDK, service worker, device manager, or a typed unsupported error.
3.
Packaging configuration is the native metadata that lets the platform allow the feature in an installed app. Examples include Android permissions, iOS usage strings, entitlements, URL schemes, associated domains, service-worker files, Windows package capabilities, macOS bundle keys, Linux portal dependencies, or store-side setup.
When a cell says Provider, the Fission API is present and the platform has a realistic implementation route, but the app or shell still needs the concrete provider and the package metadata for that product. For example, a desktop camera app needs a CameraHost implementation and, on packaged macOS builds, camera usage text in the app bundle. Without the provider the call returns unsupported; without the package metadata the operating system may deny access.
A cell marked Yes means there is a normal product path for the feature on that target. Limited means support depends heavily on browser, hardware, distribution, policy, or optional platform services. No general API means the platform does not expose a normal app-level API for that feature.
Capability | Reference | Web | Windows | macOS | Linux | Android | iOS | CLI config |
|---|---|---|---|---|---|---|---|---|
Provider | Provider | Provider | Limited | Yes | Yes | Shell setup | ||
Yes | Provider | Provider | Limited | Yes | Yes | Shell setup | ||
Limited mobile | Hardware provider | Hardware provider | Hardware provider | Yes | Yes | Yes | ||
Use passkeys | Provider | Provider | Limited | Yes | Yes | Yes | ||
Yes | Provider | Provider | Limited | Yes | Yes | Yes | ||
Provider | Provider | Provider | Limited | Yes | Yes | Yes | ||
Yes | Provider | Provider | Limited | Yes | Yes | Yes | ||
Yes | Yes | Yes | Yes | Yes | Yes | No extra CLI value | ||
Yes | Provider | Provider | Limited | Yes | Yes | Yes | ||
Limited | Hardware provider | Hardware provider | Hardware provider | Yes | Yes | Yes | ||
Yes | Provider | Provider | Limited | Yes | Yes | Yes | ||
Limited | Provider | Provider | Limited | Yes | Yes | Yes | ||
No general API | Provider | Provider | Provider | Yes | Constrained | Yes | ||
No system API | Provider | Provider | Provider | Yes | Limited | Yes |
Desktop support deserves a careful reading. Windows and macOS increasingly expose camera, microphone, notifications, Bluetooth, local authentication, clipboard, location, and volume APIs that a Fission host can connect to. Linux often has an equivalent route, but it may depend on portals, desktop services, BlueZ, NetworkManager, PulseAudio or PipeWire, and distribution packaging. For that reason Linux cells are more often marked limited or provider-driven.
Web biometrics deserve a separate note. When a site appears to authenticate with a fingerprint, it is usually using a passkey or WebAuthn credential. The browser or password manager may use fingerprint or face recognition to unlock the credential, but the web app receives a credential assertion rather than direct biometric access. Fission models that as the separate Passkeys credential capability, not as raw biometric scanning.
For conceptual guidance, read Platform capabilities. For lower-level request, provider, and configuration details, start with Platform capabilities reference.
Finished capability flow
A complete Capability matrix integration has all of these pieces in place:
Piece | What should exist |
|---|---|
Configuration | fission.toml declares the capability and generated platform files contain the permission text, manifest entry, entitlement, domain, or protocol metadata the target needs. |
State | App state records the in-flight flag, the successful value, and the user-facing error separately. |
Reducers | One reducer starts the host request, one handles success, and one handles denial, unsupported hosts, cancellation, or provider errors. |
Provider | The shell registers a real provider for production and a memory provider for tests. |
Tests | At least one test covers success and one covers permission denial or unsupported host behavior. |
Diagnose capability failures
Capability failures should be safe to retry and easy to explain. Start by checking fission.toml, then run fission doctor, then inspect the generated target files. If the provider is missing, the request should return an unsupported error. If the provider exists but the platform configuration is wrong, the OS or browser will usually deny the request before the provider can complete it. Keep those cases distinct in the UI so users know whether they can retry, change settings, connect hardware, or choose another path.
Fission
A cross-platform, GPU-accelerated user interface framework for Rust. MIT licensed.
Copyright (c) 2026 Fission
Ready to use today. Widget APIs are expected to remain stable; some runtime and shell APIs may change before 1.0.0.
Fission 0.7.0