Build1 publisher2 min readPublished Updated
A Flutter plugin swaps Zebra's Link-OS SDK for raw ZPL over Bluetooth LE to skip Apple's MFi approval
Flutter plugin flutter_zpl_printer dropped Zebra's Link-OS SDK in 0.1.0 and now prints raw ZPL over Bluetooth LE and Wi-Fi on four platforms. Bluetooth LE sits outside Apple's MFi program, so iOS builds skip Zebra's approval step but lose Classic-only printers.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Like most Flutter Zebra packages on pub.dev, the plugin's first version wrapped Zebra's Link-OS SDK, according to its author.
- Zebra ships that SDK as libZSDK_API.a for iOS and ZSDK_ANDROID_API.jar for Android, which packages cannot redistribute, so developers had to copy them in by hand.
- The SDK's Classic Bluetooth path meant sending app details to Zebra, which submitted them to Apple, before the App Store would accept the build.
- The rebuilt plugin runs entirely in Dart, with native code kept only for USB enumeration and permissions.
- Scanning Bluetooth LE and Wi-Fi together lists one ZQ620 twice, so the author groups discovery results by the serial number found in both names.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Fleets with older Zebra models that speak only Classic Bluetooth cannot use this route on iOS and stay tied to the SDK and Apple's MFi submission.
- capability Packing stations on macOS or Windows laptops can print from the same Flutter codebase as the phones, a setup the phone-only SDK did not support.
- cost With no SDK in between, the app has to handle more of the printer itself, querying status before each job and merging duplicate discovery results.
Whether Apple's MFi program applies depends on which Bluetooth the app uses. The Link-OS SDK reaches printers over Classic Bluetooth through the `com.zebra.rawport` accessory protocol, and that path is what triggers the submission through Zebra to Apple [3]. Zebra's developer blog, quoted in the post, says: "If your app uses Bluetooth Low Energy and does not use Bluetooth Classic to communicate with Zebra printers, you don't need to follow the MFi whitelisting procedures because Bluetooth Low Energy is outside MFi." [11]
The config shows the difference. A BLE-only build adds `NSBluetoothAlwaysUsageDescription` to `Info.plist` and never touches `UISupportedExternalAccessoryProtocols` [12].
Without the SDK, the plugin uses the protocols Zebra printers already speak [5]. ZPL carries the label. SGD, Zebra's Set/Get/Do text protocol, reads and changes settings with lines such as `! U1 getvar "device.product_name"` [6]. The `~HS` host status command reports paper out, head open, paused and other states [7]. Over Bluetooth the transport is Zebra's LE GATT service. Over Wi-Fi it is a TCP socket on port 9100 [5][16].
The author's sample is short and careful. Discovery merges Bluetooth LE, UDP broadcast and multicast, and USB into one stream with a 15-second timeout [17]. It reads status first, sends ZPL only when `isReadyToPrint` is true, and disconnects in a `finally` block [17]. I would keep that status gate on any transport. The author's advice is to check `~HS` before every job [16]. When one printer is reachable two ways, the author tries Wi-Fi first and falls back to Bluetooth [15].
For these results to carry over to another fleet, the printers have to be Link-OS units with Bluetooth 4.0 or later [5][13]. Wi-Fi discovery also has to reach them by UDP broadcast or multicast [17]. The only test printer the post names is a ZQ620 [13]. The production evidence is one app, zPrint, printing on iOS, Android, macOS and Windows against real Zebra printers [9]. The post does not list the other models it was tested against.
I think this is the right trade for a new app on current Zebra hardware. Under the SDK, every developer copied binaries in by hand and every iOS app went through Zebra before App Store review [2][3]. The rebuild installs with one command, `flutter pub add flutter_zpl_printer`, and the README lists the Bluetooth and local-network permission strings for each platform [10].
What to watch
- Whether flutter_zpl_printer publishes results on Zebra models beyond the ZQ620, especially other Link-OS units with Bluetooth 4.0.
- Whether other pub.dev Zebra packages, most of which wrap the Link-OS SDK according to the author, move to Bluetooth LE transports.
- Any change to Zebra's guidance that Bluetooth LE sits outside MFi, since the plugin's iOS path depends on it.