Native capabilities beyond printing

Status: mixed. Printing is the first native capability. Feature 054-desktop-runtime-shell still ships no physical printer transport (FR-095). Feature 053-mobile-vendor-printing ships a live printer-kick cash drawer on the mobile host (see below). Other rows on this page remain roadmap shapes, not a live API.

Once a native runtime exists, printing is only the first OS and hardware integration. The same bridge can expose other devices without teaching frontend-pwa about Windows, macOS, iOS, or Android.

The foundation already in the hosts:

• native runtime (Rust on desktop, Expo modules on mobile)
• normative bridge contract and capability handshake
• stable device identity
• tray / autostart (desktop)
• local persistence (SQLite outbox)
• native access to TCP / BLE / serial / USB (desktop; mobile per platform limits)

The PWA reacts to advertised capability, never to platform. See Overview for FR-003 / FR-004a.

Capability map

Capability	POS use	Priority
Barcode scanners	Scan SKU / EAN / UPC without relying on keyboard wedge	High
Cash drawers	Open drawer without relying only on the printer kick port	High
Electronic scales	Read weight for produce, meat, pharmacy	High
Payment terminals	Send amount; receive approved / declined	High
Customer display	Second monitor: cart, total, promotions, QR	High
Offline / local operation	Keep selling during internet outages	High
System notifications	Printer offline, payment failed, sync problems	Medium
Camera / QR scanner	Loyalty cards, documents, payment QR	Medium
RFID / NFC	Inventory, employee login, membership	Medium
Label printers	Product, shelf, barcode, pharmacy labels	Medium
Serial / USB devices	Generic integration for specialised hardware	Medium
Second-screen / KDS mode	Kitchen or customer-facing display	Medium
Local file export / import	Backups, reports, CSV, product imports	Medium
Auto-login / station identity	Dedicated till behaviour	Medium
OS credential storage	Secure API / device credentials	Medium
Remote diagnostics	Hardware inventory, logs, versions, health	Medium

1. Barcode scanners

Many USB scanners already work as keyboards, so the PWA receives typed digits today. A native HID path is still worth it: focus, duplicate scans, scanner identity, and symbology.

bridge.on("scanner.barcode", (event) => {
  // { value: "7501234567890", symbology: "EAN13", deviceId: "..." }
});

Instead of the scanner pretending to type 7501234567890[ENTER].

2. Electronic scales

Commercial scales typically speak serial / USB-serial / TCP / sometimes BLE — the same transports printing already needs.

scale.read();
// { weight: 1.475, unit: "kg", stable: true, deviceId: "scale-01" }

Then the sale line is 1.475 kg × Q32.50/kg without the cashier typing the weight.

3. Payment terminals

Highest commercial value, highest integration cost. Treat providers like the printer vendor registry, not one SDK:

payment-terminal
├── generic
├── VisaNet Guatemala
├── BAC
├── NeoNet
└── future provider

payments.charge({ amountMinor: 32540, currency: "GTQ" });

FlowPOS sends the amount; the customer taps or inserts; the host returns approved or declined; the sale completes. That replaces the cashier typing the total into the terminal and reporting the result by hand.

4. Customer-facing display

Tauri can own a second window. The PWA should not contain monitor logic:

customerDisplay.showCart(cart);

Possible content: line items, total, promotions, loyalty, restaurant order number, payment QR, tips, invoice status, marketing.

5. Cash drawers

Shipped on mobile (053). The pulse is PrinterSession.openCashDrawer() — its own call, not bytes appended to a receipt — so drawer outcome and print outcome stay independent.

• With a document that is configured to kick the drawer: authorised by taking the payment. No cash_drawer_event row.
• No sale: POST /cash-drawer/open then the native pulse then PATCH /cash-drawer/open/:id. Gated on PolicyResource.CashDrawer, which no existing role bundle grants. The attempt is recorded before the pulse.

Generic adapters emit ESC p. Star's adapter uses the SDK kick. USB / serial drawers that are not attached to a printer are still roadmap.

See Cash Drawer.

6. Offline POS

Strategically the largest follow-on after hardware. The hosts already own SQLite and versioned local PWA bundles. Do not reuse the print outbox for sales: separate queues and semantics (money, inventory, FEL).

Local catalog, prices, customer subset, inventory snapshot, pending sales, pending sync. Internet down → keep selling → durable outbox → sync when back.

7. Generic hardware gateway

Prefer a structured capability document in the handshake over a growing pile of ad hoc APIs:

{
  "capabilities": {
    "printer": { "tcp": true, "ble": true, "serial": true },
    "scanner": { "hid": true, "serial": true },
    "scale": { "serial": true },
    "cashDrawer": { "printerKick": true, "usb": false },
    "customerDisplay": { "secondaryWindow": true }
  }
}

The PWA never does if (isWindows). Future features that need merchant UI (scale weight, customer-display controls) get their own spec; they do not quietly invent capability-conditional screens against FR-004a.

Target bridge shape

DesktopBridge and the current mobile bridge should evolve toward a NativeBridge both hosts implement:

NativeBridge
├── device (identity, capabilities, health)
├── printer (discover, print, status)
├── scanner (discover, barcode event)
├── scale (discover, read, weight event)
├── cashDrawer (open)
├── paymentTerminal (charge, cancel, refund)
├── customerDisplay (open, update, close)
├── storage
├── notifications
└── system (network, version, diagnostics)

The same pattern on both hosts:

React Native host          Tauri host
        ↕                      ↕
   NativeBridge           NativeBridge
        ↕                      ↕
              frontend-pwa

That makes the work in apps/mobile and apps/desktop more than desktop printing. It is the foundation for a FlowPOS native hardware runtime.

Suggested sequence after printing

1. Barcode scanners — cheap, immediately useful
2. Electronic scales — retail / pharmacy vertical
3. Customer-facing second display — visible, relatively inexpensive on desktop
4. Payment-terminal integration — hard, high value
5. Offline sales runtime — large project, strong differentiator
6. RFID / NFC and specialised devices — customer-driven

Design the bridge as a general native capability surface now, even while printing is the only implemented capability. That is what stops a print-shaped DesktopBridge from becoming an architecture that has to be generalised six months later.