sklar.app / dymobridge

DymoBridge

A native Apple Silicon replacement for DYMO Web Services — so browser apps keep printing to your LabelWriter 550 long after Rosetta is gone.

DYMO's background service (DYMO.WebApi.Mac.Host.app) is Intel-only, and its shared-certificate install breaks on macOS updates. DymoBridge answers the same local API from a single ~10 MB Swift binary. Your web app never notices the difference; your labels print exactly the same.

Download for Mac View on GitHub

Signed & notarized .pkg · Apple Silicon · macOS 13+ · MIT license

browser app (DYMO JS framework) → https://127.0.0.1:41951 same DLS API → dymo-bridge renders natively → CUPS (DYMO's arm64 driver) → LabelWriter 550
Why it exists

Plenty of web apps — EMRs like Kipu, shipping tools, label designers — print DYMO labels through the vendor's JS framework, which talks to a little web service on 127.0.0.1:41951. That service is an Intel binary living on borrowed Rosetta time, and its TLS setup (a certificate shared by every install in the world) has a habit of breaking on macOS upgrades.

DymoBridge re-implements that service natively: the same four endpoints (StatusConnected, GetPrinters, PrintLabel, RenderLabel), a renderer calibrated pixel-for-pixel against the vendor engine's own output, and printing through DYMO's CUPS driver chain — which ships arm64-native, so the 550's genuine-label handshake keeps working.

What you get

Drop-in compatible

Web apps built on DYMO's JS framework work unchanged — same port, same API, same rendered output.

One small binary

Swift + SwiftNIO/NIOSSL and nothing else. No Electron, no runtime, no Rosetta.

TLS that survives updates

A per-machine local CA with short-lived leaf certs, renewed silently. Deliberately zero keychain involvement.

Double-click installer

Signed, notarized .pkg — target Macs need no dev tools. Disables the vendor service reversibly; the uninstaller restores it.

Template adjustments

Optional JSON rules tweak the labels your app sends — move, resize, rescale, or drop fields — without touching the app.

Debuggable

Every print/render request is captured (XML + rendered PNG) for replay, and a local health page shows live status.

Install
  1. Install DYMO Connect for Desktop (it provides the LabelWriter CUPS driver) and confirm the printer shows up in System Settings → Printers & Scanners.
  2. Run the DymoBridge .pkg. It sets up TLS, swaps out the vendor service, and starts at every login.
  3. Open https://127.0.0.1:41951/ — the health page lists your printer. Print from your web app as usual.

Prefer building from source?

git clone https://github.com/xwrvnggp9n-star/DymoBridge.git
cd DymoBridge
sudo ./scripts/install.sh     # or ./scripts/build-pkg.sh to make your own installer
Template adjustments

Because the app sends the label template with every request, site-local layout preferences have to live bridge-side. Describe them once in JSON — this example drops an unused signature row and enlarges the patient block on a clinical specimen label:

{ "rules": [ {
    "trigger": { "objectExists": "TEXT_SIGNATURE" },
    "remove":  ["TEXT_SIGNATURE"],
    "objects": {
      "labelFullName": { "y": 540, "h": 150 },
      "TEXT_DOB":      { "y": 770, "h": 150, "fontScale": 1.2 }
    } } ] }

No rules file? Labels render exactly as sent.

DymoBridge is free and MIT-licensed. If it saved your office a headache, buy me a coffee ☕