Platform capabilities

Fission

Product

▾

Setup

›

Platform capabilities

Platform capabilities are typed contracts between shared Fission app code and the active host shell. The app emits a request through ctx.effects, the shell provider performs the host work, and the runtime dispatches either the configured success action or the configured error action.

Use this page when you need the exact names. If you are adding a feature to an app for the first time, read Platform capabilities first because it explains the workflow step by step.

Concept model

Concept	Public API	What it does
Capability identity	CapabilityType<C>	Gives an operation a stable name and typed request/result contract.
Operation contract	OperationCapability	Associates Request, Ok, and Err payload types with one host operation.
Reducer entrypoint	ctx.effects.<group>()	Starts a typed request builder from a reducer.
Result binding	.on_ok(...) and .on_err(...)	Chooses which actions the runtime dispatches after the host finishes.
Provider registration	with_<name>_host(...) or AsyncRegistry::register_operation_capability(...)	Connects a shell implementation to the runtime.
CLI declaration	fission add-capability <name>	Records the capability and updates generated platform files where Fission can do that safely.

The API, provider, and packaging configuration are separate. The API lets app code express intent. The provider performs the host call. Packaging configuration is the native metadata that lets the platform permit the call in a packaged app. A complete production feature usually needs all three.

Large binary data crosses this boundary as FissionDataStream handles. File picking, camera capture, microphone capture, rich clipboard content, and barcode image decode requests use DataStreamId plus metadata instead of embedding Vec<u8> in reducer payloads. Reducers can store the handle or pass it to app-owned async work; jobs and services consume the stream with their runtime context.

Built-in groups

Group	Effect helper or entrypoint	Provider trait or host contract	Test provider or test entrypoint	Detailed reference
Notifications	effects.notifications()	NotificationHost	MemoryNotificationHost	Notifications
Deep links	inbound DeepLinkReceived	DeepLinkConfig and shell startup	startup deep-link tests	Deep links
NFC	effects.nfc()	NfcHost	MemoryNfcHost	NFC
Biometrics	effects.biometrics()	BiometricHost	MemoryBiometricHost	Biometrics
Passkeys	effects.passkeys()	PasskeyHost	MemoryPasskeyHost	Passkeys
Barcode scanner	effects.barcode_scanner()	BarcodeScannerHost	MemoryBarcodeScannerHost	Barcode scanner
Camera and flashlight	effects.camera()	CameraHost	MemoryCameraHost	Camera and flashlight
Clipboard	effects.clipboard()	ClipboardHost	MemoryClipboardHost	Clipboard
Geolocation	effects.geolocation()	GeolocationHost	MemoryGeolocationHost	Geolocation
Haptics	effects.haptics()	HapticHost	MemoryHapticHost	Haptics
Microphone	effects.microphone()	MicrophoneHost	MemoryMicrophoneHost	Microphone
Bluetooth	effects.bluetooth()	BluetoothHost	MemoryBluetoothHost	Bluetooth
Wi-Fi	effects.wifi()	WifiHost	MemoryWifiHost	Wi-Fi
Volume control	effects.volume()	VolumeHost	MemoryVolumeHost	Volume control

Use the Capability matrix to compare platform support across web, Windows, macOS, Linux, Android, and iOS.

CLI-supported platform config

CLI value	Android generated config	iOS generated config	Notes
nfc	android.permission.NFC, optional NFC feature	NFCReaderUsageDescription, NFC reader-session entitlement	Desktop generally needs a hardware-provider decision.
biometric	USE_BIOMETRIC, legacy USE_FINGERPRINT	NSFaceIDUsageDescription	Web sign-in should use passkeys, not raw biometric access.
passkeys	Recorded only; Digital Asset Links are product-domain-specific	Recorded only; associated domains are product-domain-specific	The relying-party domain must match production identity.
barcode-scanner	CAMERA, optional camera feature	NSCameraUsageDescription	Image-only decoding may not need camera access on every target.
camera	CAMERA, optional camera/front/flash features	NSCameraUsageDescription	Desktop packages may need camera metadata.
geolocation	ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION	NSLocationWhenInUseUsageDescription	Background location requires product-specific policy review.
haptics	VIBRATE	none	Desktop haptics are hardware/provider-specific.
microphone	RECORD_AUDIO	NSMicrophoneUsageDescription	Desktop packages may need microphone metadata.
bluetooth	Legacy and Android 12+ Bluetooth permissions, optional Bluetooth features	NSBluetoothAlwaysUsageDescription	Some operations need additional product policy review.
wifi	Wi-Fi/network permissions, nearby Wi-Fi, older fine-location permission, optional Wi-Fi features	Wi-Fi info/hotspot entitlements, location usage where needed	iOS and desktop Wi-Fi management is constrained.
volume-control	MODIFY_AUDIO_SETTINGS	none	iOS and web do not expose broad system-volume control.

Clipboard has no generated platform config in the built-in declaration. Notifications and deep links are shell setup because route names, notification categories, service workers, associated domains, push identifiers, and URL schemes are product-owned. Fission should not invent those values.

Generated files

File	Platform	Role
fission.toml	all	Stores the canonical capabilities = [...] list and product-level references.
platforms/android/AndroidManifest.xml	Android	Declares permissions, features, activities, services, and intent filters where generated.
platforms/ios/Info.plist	iOS	Declares user-facing usage descriptions for permission prompts.
platforms/ios/Entitlements.plist	iOS	Declares platform capabilities Apple gates through entitlements.
packaged app Contents/Info.plist	macOS	Declares usage descriptions for packaged desktop apps when a capability needs camera, microphone, location, Bluetooth, barcode camera access, associated domains, or other app services.
Windows package manifest	Windows	Declares package identity, protocol activation, capabilities, and store-facing metadata for packaged apps.
static/web host files	Web/site	Declares service workers, route handling, manifest metadata, icons, and secure-origin assumptions where needed.

Runtime behavior

A capability effect is queued from a reducer:

ctx.effects
    .microphone()
    .capture_audio(MicrophoneCaptureRequest::default())
    .on_ok(ctx.effects.bind(
        AudioCaptured(MicrophoneCapture::default()),
        reduce_with!(on_audio_captured),
    ))
    .on_err(ctx.effects.bind(
        AudioCaptureFailed(MicrophoneError::default()),
        reduce_with!(on_audio_failed),
    ));

The reducer returns. The shell provider handles the request. The runtime dispatches either AudioCaptured with the provider's success payload or AudioCaptureFailed with the provider's error payload.

Unsupported default providers return typed errors. They do not silently succeed. App code should treat errors as expected state transitions and render useful recovery UI.

Custom capabilities

Applications and libraries can define their own OperationCapability types without changing Fission core. Use reverse-DNS capability names for product-specific host work, register the provider in the shell, and keep platform config explicit in your own project files.

A good custom capability has:

Part	Requirement
Stable name	Use a product-owned name such as com.example.payments.authorize.
Typed request	Include only data the app is allowed to know and send to the host.
Typed success	Return the smallest portable result the reducer needs.
Typed error	Use stable code values plus human-readable message text.
Provider	Register the host implementation during shell startup.
Tests	Include success, unsupported, denied, cancelled, and malformed-request cases.