Phone and tablet

The same operations work on a phone, but the path to the core is built differently. The ready-made SumSheet apps for iPhone, iPad, and Android are released, and a view kit for embedding is built from the same build. Below are four approaches at different levels of readiness: the right-hand column says what already exists for each one and what doesn’t yet.

Approach	Where the interface is	Where the core is	Readiness
Mobile browser	A page in the phone’s browser.	WebAssembly in the browser or a background thread.	Technically possible; needs a separate touch-tailored interface.
WebView inside the app	Your WebView window with the editor page.	The mobile Rust core next to the WebView: the page talks to it through a bridge — JNI on Android, a C interface on iOS.	This is how the ready-made SumSheet apps are built: for iPhone and iPad in the App Store, for Android in Google Play, for macOS in the Mac App Store. For embedding in your own app, a view kit (view-SDK) is built from the same build, under the same version number: the core library, the page, and the bridge (where to get it). Android — arm64-v8a only, Android 8.1 and newer; iOS — 16 and newer, device and simulator. It needs neither a server nor a network. The WebAssembly-inside-WebView variant remains for a pilot with a limited set of scenarios.
Native app screens	Your screens in Swift or Kotlin.	The Rust core as a library through a platform bridge.	On the core side, the bridge is written: a separate mobile core with a single door — a contract request as a JSON string, a response as a JSON string, and the session lives between calls. The same mechanism calculates as in the desktop app, so the phone doesn’t have a separate set of operations and won’t diverge from the desktop one. The core is exposed in two ways: a C interface for iOS and JNI for Android. The browser isn’t part of this line: a different bridge works there, unrelated to the mobile core (The core in the browser). The built library is verified on a real phone. What’s missing is the other part: Swift and Kotlin screens on top of the bare core. Today the developer kit ships the core together with the editor page and the bridge (the row above), not as a library for your own screens.
Computing on the server	The mobile interface sends the intent.	The Rust core runs on the server.	The core on the server works already today (The processor on the server). What’s missing is a ready-made multi-tenant wrapper and a network session model.

Why this isn’t a shrunken desktop app

• It needs touch selection, an on-screen keyboard, gestures, a compact ribbon, and dialogs that fit a narrow screen.

• A phone has less memory, so for large workbooks you have to keep an even smaller part of the sheet in it.

• The system can evict the app from memory while it’s in the background — taking the open workbook with it. That’s why checkpoints and session recovery are needed.

• File access, the Share menu, offline storage, and permissions are all built differently on iOS and Android.

Recommendation

For a first mobile pilot, take a tablet or a WebView and one narrow scenario: open the workbook → find and change a range → save. Consider a full Excel-level mobile interface a separate product, not the next step from this one.

What the mobile core actually exposes

The door is narrow — six calls on the C side:

Call	What it does
fastsheet_mobile_host_open	Starts a workbook session and returns a pointer to it.
fastsheet_mobile_host_execute_json	The one working call: takes a contract request as a line and hands back a response as a line. Everything else is bookkeeping.
fastsheet_mobile_compute_contract_version	The operations contract version. There’s no greeting line here like the processor has — this call is the only way to check compatibility.
fastsheet_mobile_last_error	The last error’s text. In the C interface, the response and the refusal reason are separate: the call returned nothing — the reason is fetched from here.
fastsheet_mobile_buffer_free	Free a string the core returned.
fastsheet_mobile_host_free	Close the session.

On the Android side, the same actions come through JNI as four FastSheetBridge methods: create, ask version, run request, release.

This is a state, not a contract

The view kit (view-SDK) ships these calls already wrapped: a Kotlin and Swift bridge, the editor page, and the core library in one archive, with the same version number as the build in the store. The bare names above show what is built and working, but they are not a compatibility promise: it’s too early to build your own screens directly on them — first the profile is fixed, then the names.

Other environments

• The core in the browser
• A separate process alongside your application
• The processor on the server
• The end-to-end scenario and what changes between environments