Saltar al contenido principal

Mobile printing: platform constraints

Written for sales and support. These are product facts, not defects awaiting a fix, and a proposal that promises otherwise will be wrong on the day it is delivered.

iOS MFi Bluetooth is per-vendor, not a blanket no​

Star, Epson and Bixolon classic Bluetooth printers use Apple's MFi programme. Reaching one requires the app to declare that manufacturer's protocol string, and Apple rejects builds that declare a protocol they cannot demonstrate.

Feature 053-mobile-vendor-printing ships StarIO10. When that native module loads, Star Bluetooth is a real path on both platforms. Epson Bluetooth on iOS is still blocked: the handshake reports awaiting_mfi_approval for Epson BLE rather than offering a connection that will fail. Bixolon and Epson have profiles (so a scan can name them) but no vendor adapter in this tree — they print on the generic path where one exists.

PrinteriPhone / iPadAndroid
Network / Ethernet (any brand)YesYes
Bluetooth Low Energy (generic writable characteristic)YesYes
Star Bluetooth (StarIO10 present)YesYes
Epson Bluetooth (MFi)No — waiting on PPIDYes (SPP / vendor when added)
Classic Bluetooth / USB, no-name ESC/POSNo — iOS generic transports are tcp and bleYes (generic:spp, generic:usb)

The setup screen states the limitation on each affected printer rather than showing one that silently fails.

What to say: "On iPhone and iPad, FlowPOS prints to network printers, BLE printers, and Star Bluetooth when the Star integration is in the build. Epson Bluetooth on iOS is a later release. Android also reaches classic Bluetooth and USB printers."

iOS does not print while the app is in the background​

Bluetooth and accessory sessions do not survive app suspension on iOS. When the FlowPOS app is backgrounded or closed, the device hands its assigned kitchen stations back to the Print Bridge, and jobs queued in the meantime print when the app returns to the foreground.

Nothing is lost — the queue is durable and survives force-close, restart and over-the-air updates — but it is deferred.

What this means for a proposal:

  • An iPhone or iPad assigned to a kitchen station needs somebody keeping the app on screen during service.
  • A site that cannot guarantee that should use Android, or keep a Print Bridge for its kitchen stations. Both are supported alongside mobile printing.
  • Receipts printed by the person holding the device are unaffected: the app is in the foreground by definition when they take the sale.

Android holds connections through a foreground service and does print in the background for jobs this app already accepted. It does not pull jobs while the merchant takes a sale in Chrome or another app — that is a follow-on (Android agent mode). The full picture, including why desktop is Print Bridge rather than this app, is Printing topology.

A phone does not replace a Print Bridge​

A Print Bridge is a dedicated, mains-powered, always-on device. A phone is none of those. Where both serve the same station, the phone takes it only while it can actually print, and the Bridge takes it back automatically otherwise — within a minute at worst, immediately when the app is closed cleanly.

Mobile printing removes the requirement for a second device. It does not make the Print Bridge obsolete for a busy multi-station kitchen.