Skip to main content

Where printing actually happens

Written for sales, support, and anyone joining the printing work. These are product facts. Rows marked not built are recommendations, not behaviour a proposal can promise.

The mobile and desktop apps are native containers around the same frontend-pwa build the browser already runs. Daily web work does not fork a second product. Background printing, though, is a platform rule — and on Windows and macOS the always-on printer today is still a different app, Print Bridge. The Tauri desktop host (apps/desktop, spec 054) is the installed POS UI, not a replacement for that agent yet: it ships no physical printer transport (FR-095).

For the hard limits (iOS MFi, iOS backgrounding, phone vs Bridge), see Mobile printing limits.

The matrix​

ClientPOS UIBackground printing
Browser (any OS)frontend-pwaPrint Bridge on the same machine (or web-bridge in a Chrome/Edge tab)
Android appthe mobile app, or a browserToday: this app keeps printer connections alive while it is backgrounded, and prints jobs it already accepted. Not built: pull jobs while the merchant uses Chrome or another app — that is Android agent mode, below.
iOS appthe mobile appNot possible. Apple suspends the app within seconds of leaving it. Pair an Android agent or a Print Bridge for kitchen stations; use the iPad as the till.
Windows / macOSbrowser, or the Tauri desktop app (apps/desktop)Today: Print Bridge. The desktop host is an installed POS container, not a printer agent, and advertises no hardware printing in this version (FR-095). Do not port the React Native app to Windows/macOS. Bluetooth on the Bridge is a small follow-on.

Feature 053-mobile-vendor-printing does not change this matrix. It adds manufacturer resolution, StarIO10, Android SPP/USB, and cash-drawer kick on the same mobile container. It is not Android agent mode and it is not a desktop printer transport.

Two follow-on features — Android agent mode, and Bluetooth for Print Bridge — would give every merchant on every platform a background printer, all running the same orchestrator code. Neither is in this release.

Daily PWA changes do not force a store release​

The app packages a copy of the frontend-pwa web build. Deploying that app also publishes the new build over the air through EAS Update. A merchant's device downloads it in the background and uses it on the next cold start. They can also open About → Check for updates to download and apply immediately, after confirming they are not mid-ticket. No store release, nothing the web team does differently from today.

A store release is only needed when native code changes — a new printer SDK, a new permission, an OS-level capability. That will be frequent during vendor-SDK work (design phases 4–6) and rare afterwards.

Mechanism: Mobile Shell — Releases. How the first binaries reach TestFlight and Play: Store submission.

Background printing is a platform rule​

Android, today​

The shell already has a connectedDevice foreground service, the outbox, the transports, the orchestrator, and per-station claims. What it does not do is pull jobs itself — it receives them from the web app inside the WebView. The WebView enqueues test prints today, and receipt documents after a Thermal print tap. That is still not an agent: the shell does not poll document-print-jobs.

So: the merchant can switch to WhatsApp and this device will finish jobs it already accepted, and keep its printer connections warm. They cannot take a sale in Chrome on another device and have this tablet print that sale's kitchen tickets. That second behaviour is agent mode.

Android agent mode (not built)​

A pulling agent polls the backend's document-print module for jobs assigned to its stations, the same way Print Bridge does. Then the merchant can use Chrome, the PWA in a browser, WhatsApp, anything — and the tablet on the counter keeps printing. That is Print Bridge running on a cheap Android device instead of a PC.

One design consequence: a pulling agent needs a credential of its own, the way the Bridge has a device token via pairing code. The shell must not hold a merchant credential (FR-012); that rule stays. Agent mode registers as a device, not as a merchant — exactly like the Bridge. Same rule, different client shape.

Recommended as the next feature after vendor-SDK printing.

iOS​

Apple does not allow an app to run indefinitely in the background. When the merchant switches away, iOS suspends yours within seconds, drops network sockets, and does not wake it reliably for new work. Narrow exceptions exist (BLE / MFi accessory sessions, silent push) but "sometimes" is not a kitchen printer.

That is why iOS prints only while the app is open, why iOS claims are withdrawn on backgrounding, and why the setup screen warns before a station is assigned. The product answer for an iPad merchant who needs background printing is not more iOS engineering: it is a cheap Android device in agent mode next to the printer, or a Print Bridge, with the iPad free for the till.

Details: Mobile printing limits.

Desktop printing is Print Bridge; the desktop host is the POS container​

A service that runs in the background, pulls its own jobs, and prints while the merchant uses a browser is exactly what Print Bridge does today on Windows and macOS. It is a background process with a device token; it polls the backend; it prints over TCP and USB.

The Tauri desktop app (apps/desktop) is a different job: an installed container around the same PWA, with a native runtime, a stable device identity, and the shared bridge. It is not a port of apps/mobile. react-native-windows / react-native-macos exist, but the pieces the mobile app depends on (static server, expo-sqlite, the WebView module, Expo config plugins) have thin or no support there — that is why desktop is Tauri, not React Native.

Physical printing from that host is not in 054 (FR-095). Until a later feature wires real transports, a Windows or macOS till that needs background printing still runs Print Bridge. What the Bridge lacks relative to the mobile app is Bluetooth — a small addition behind the same PrinterTransport port, using the shared print-orchestrator and receipt-escpos packages.

Later native hardware (scanners, scales, customer display, payment terminals) lands on the same bridge, not as a second desktop product. See Native capabilities beyond printing.