Skip to content
SumOfficeSumOfficeSumOffice
Menu
What SumOffice isProduct and deliveryAI and MCPContact us
Getting started
What SumOffice isAdd the editor without a programmerEmbed into a web applicationEmbed into a desktop applicationEmbed into a mobile applicationHow to read this documentationGlossaryAI tools and MCPContact usEarly access request
Product and delivery
Your own office instead of Microsoft OfficeWhat you get: in shortWhat the delivery includesCustomizing for your brandEmbedding modesFeature parity with Word and ExcelVBA, Power Query, and agentsSecurity, privacy, and operationsPreview without the editorWhat embedding gives you that Office doesn'tWhat's promised, and what isn'tPilot and acceptanceCommercial packagingRisks and honest boundariesWhat's coming next

Embed into a mobile application

What exists today for the phone and the tablet: ready-made apps in the stores, a viewing kit for embedding and a server path for editing — step by step and without promises that nothing can back up.

The SumDoc and SumSheet mobile apps are released: for iPhone and iPad — SumDoc and SumSheet in the App Store, for Android — SumDoc and SumSheet in Google Play. They are built the same way as described below: the editor screen inside an ordinary application.

For your own application you have three paths. To show a document — the ready-made viewing kit (view SDK) for Android and iOS: the same engine and the same page as in the store apps, under the same version number. To let people edit from a phone — your server computes the document and your application shows the screen; this path works today. To edit right in the application, without a server — a separate delivery, which is agreed with the team.

What exists today

Section titled “What exists today”
Path Documents (SumDoc) Spreadsheets (SumSheet)
Ready-made app App Store and Google Play. App Store and Google Play.
Viewing, the core inside your application View SDK: Android (arm64-v8a) and iOS 16 and newer. View SDK: Android (arm64-v8a) and iOS 16 and newer.
Editing, the core on the server, your screens Works. Works.
Editing, the core inside your application A separate delivery, by agreement. A separate delivery, by agreement.

The viewing kit is connected in three actions: add it to the project, show it in a web view, pass the file. Archives, checksums, the instructions and speed measurements are on the viewing kit page. What each of the paths costs — Phone and tablet and where SumDoc is deployed.

Editing from a phone through your server

Section titled “Editing from a phone through your server”

The idea is simple: the phone does not compute the document, it shows it. The heavy work is done by the same core, but on your server — where it has memory and where you control it. For the business this means: the file and the edit history never leave your server, and the mobile application stays yours.

The steps below are for whoever will do the wiring.

  1. Put the core on your server. The same executable as for the desktop path. How it runs as a service — The processor on a server for spreadsheets, The editor in the browser for documents.

  2. Set up three addresses on your side. This is your ordinary API, nothing special:

    POST /workbooks → open a document, return a session id
    POST /workbooks/{id}/commands → perform an action
    POST /workbooks/{id}/save → collect the finished file

    This is how the mobile application talks to the core. Outward you hand out your own session id and never show the core’s internal names to the client.

  3. Show the document on the phone screen. Two ways, and both are yours:

    • a web view inside the application — then the editor shell draws the screen, and you do not need to build an interface;
    • your own screens in Swift or Kotlin — then you draw everything yourself and ask the core only for the content.

  4. Take a narrow scenario for the first pilot. Not “all of Excel in your pocket” but one clear task: open a workbook → find and change the needed range → save. Such a pilot can be completed and shows the real cost of the work.

What to expect from a phone and what not to

Section titled “What to expect from a phone and what not to”
  • Less memory. A large workbook has to be held in an even smaller portion than on a computer.
  • The system may evict the application from memory while it is in the background — together with the open document. So you need checkpoints and session recovery.
  • A finger is not a mouse. Selection, the on-screen keyboard, gestures, a compact ribbon and dialogs for a narrow screen are separate work, and it is yours.
  • iOS and Android differ in files, “Share”, offline operation and permissions.

How the core works on a phone

Section titled “How the core works on a phone”

The store apps and the viewing kit run the same core as on a computer, so the set of operations on the phone is not separate and will not drift from the desktop one. For developers: the mobile core has one door — a request and a response as JSON strings, and the session lives between calls; it is exposed through a C interface on iOS and JNI on Android, while the browser uses a different bridge — Phone and tablet.

Where each of these is heading — What comes next and Risks and honest boundaries.

Next

Section titled “Next”

See what it looks like

The live examples open in the phone browser just as they do on a computer.

Editor · Spreadsheet

Understand the cost

What you will have to do and what the contract fixes before work starts.

Pilot and acceptance

Embed into a web applicationThe same server path, but for the browser — and there it takes one evening.
Embed into a desktop applicationIf you also have a desktop program: the core runs next to it as a separate process.

Documentation assistant

Answers are assembled from the documentation and may be inaccurate — check the sources.