Developers — SumOffice
Download
The ladder

See a document first. Integrate second. Edit third.

Viewing a document is the fast half of office integration — so that's where we start you. Every rung below carries an honest status: what's live is live, what's coming says so. What the engine can't draw yet, it preserves byte-for-byte and tells you — a file always comes back whole.

RUNG 0

Open a document right now

Live

Real SumDoc editor, in your browser, no install and no sign-up — a demo cabin opens one of our real-world sample files. Edits live only inside the cabin and are not saved anywhere.

Honest note, measured today: in the two long reports and the workshop brochure, some captions and headings are still drawn on top of body text — we built a measure for it and it names 19 such places; 17 of them a reader would notice. Text running past the sheet edge — 83 lines this morning — is fixed, and so is the brochure page that drew every glyph twice. No text is lost in any of these files: every word is on the page, and the files are verbatim originals — download them and compare.

RUNG 1

One command, for agents and scripts

Live · macOS (Apple silicon)

No package manager, no install: download one binary from this site and turn any DOCX into a self-contained HTML page that opens with a double-click — offline, view-only, honest about what it didn't draw.

curl -LO https://sumoffice.com/dl/sumdoc && chmod +x sumdoc
./sumdoc render report.docx -o report.html

145 MB, darwin-arm64 today — more platforms and a slimmer build are coming; sha256. An npm wrapper may follow — it is not required.

Working with an AI agent? Paste this to it

Everything below is on this page already — the block just saves you the explaining.

Show me report.docx as a web page, offline, without installing Office.
Use SumOffice: download the binary, verify the checksum, render the file.

  curl -LO https://sumoffice.com/dl/sumdoc
  shasum -a 256 -c <(curl -s https://sumoffice.com/dl/sumdoc.sha256)
  chmod +x sumdoc
  ./sumdoc render report.docx -o report.html

The result is one self-contained HTML file: no server, no network, view-only.
Machine-readable notes about this engine: https://sumoffice.com/llms.txt

Agents can also read llms.txt directly — it is the machine-readable front door of this site and states plainly what is live and what is not.

RUNG 2

In your product — desktop

Live · ~30 min, measured

One binary, one localhost port, your WebView. The full walk-through with the bootstrap handshake, document events and the headless session protocol is the quickstart.

RUNG 3

In your product — mobile

view-SDK · SumDoc 2026.3.33 and SumSheet 2026.3.32 · Android and iOS

Our own SumDoc and SumSheet apps are exactly this integration shipped to the stores: a system WebView around the same surface. The view-SDK is those same bits — the engine and the page from the store builds of SumDoc 2026.3.32 and SumSheet 2026.3.32 — packaged as a drop-in for your app, released together with each store build under the same version number.

SumDoc (.docx / .docm):

Android view-SDK 2026.3.33 · 84 MB → · README · sha256
arm64-v8a only · adds ~160 MB per architecture to your APK — ship as an App Bundle

iOS view-SDK 2026.3.33 · 203 MB → · README · sha256
FastDocMobileCore.xcframework (device + simulator, arm64) + page + bridge + reference view · iOS 16+ · adds ~130 MB to your binary

SumSheet (.xlsx / .xlsm):

Android view-SDK 2026.3.32 · 24 MB → · README · sha256
arm64-v8a only · adds ~90 MB to your APK — ship as an App Bundle

iOS view-SDK 2026.3.32 · 70 MB → · README · sha256
FastSheetMobileCore.xcframework (device + simulator, arm64) + page + bridge + reference view · iOS 16+ · adds ~50 MB to your binary

  • 1. Add: Android — copy jniLibs/, assets/ and the two bridge files into your module, add androidx.webkit and abiFilters += "arm64-v8a"; iOS — add the xcframework, the bridge (SumDoc: with its bridging header), the page folder (assets/a4 or assets/f1) as a folder reference and the reference EditorWebView.swift.
  • 2. Show: Android — a WebView with JavaScript, DOM storage and file access on, the bridge attached (SumDoc: FastDocWebBridge(webView, bytes, …).attach(); SumSheet: a document-start script with the workbook and addJavascriptInterface(SumSheetWebBridge(…), "F1Native")), load file:///android_asset/a4/index.html or …/f1/index.html; iOS — a WKWebView with the bridge as its message handler (SumDoc via the sumdoc:// scheme handler, SumSheet via loadFileURL).
  • 3. Open: hand over the .docx / .xlsx bytes — from your bundle, a picker, an ACTION_VIEW intent or onOpenURL — the reference activity and view in the zips do all of it.

Verified on empty projects built from the READMEs alone. SumDoc: Android — the bundled sample and a 37 KB business letter render 1.5–2 s after a cold launch on an arm64 emulator and about 3.5 s on a Galaxy A22 5G; iOS — 2–3.4 s on the simulator, 2.5 s / 2.1 s (first launch / relaunch) on an iPhone 12 and 3.2 s / 1.8 s on an iPhone 11 Pro Max, "Open in…" included. SumSheet: Android — the bundled workbook shows its grid, ribbon and sheet tabs 16 s after launch on an arm64 emulator and 18–20 s on a Galaxy A22 5G (the page is the full 30 MB editor; those are the store app's numbers on the same devices); iOS — 13 s from launch to the grid on the simulator, and the host runs on an iPhone 12. Free to evaluate and prototype; for production licensing contact us.

RUNG 4

Editing

Same engine, same surface

Viewing and editing are one engine and one layout — upgrading is not a re-integration. Commands run sequentially, every response echoes your id, and a refusal arrives before the change: the document, its history and the file stay untouched. See quickstart, Path B.

Why view-first? Because seeing your files open correctly is the fastest way to trust an engine — and the cheapest way to find out it's wrong for you. Everything else builds on that trust.