When Apple finally released the API for Apple Business & School Manager last year I was thrilled. I took it as an opportunity to try and create a Swift CLI for it which ended up being asbmutil, a Swift binary that directly communicates with the Apple School & Business Manager API. I posted it in the MacAdmins Slack, didn't think much about it, and it ended up getting used by folks — along with requests to make it better.

Today I'm shipping ASBMUtil.app, a native SwiftUI front-end on top of the same engine. Same credentials store, same API client, same bulk operations — inside a native Liquid Glass Tahoe app.

Not every Mac admin wants to live in the terminal. Even a well-built CLI carries its own friction — "here's the command, make sure the profile is set, redirect jq somewhere, don't forget the –mdm flag…"

Hence the GUI app. Same engine underneath, same credentials store, same API client.

What's in the App

The main view is a single native table with every managed device in your Apple Business & School Manager account — Macs, iPads, iPhones, Apple TVs, all of it — right next to each other. Click a row and a sidebar slides in with the full device details: serial, order, status, MDM assignment, AppleCare coverage, MAC addresses, the works. Select a handful, right-click, reassign.

• Device browser — every managed device in one paginated, sortable table with a details sidebar. AppleCare coverage enrichment is a toggle away.
• Powerful filters — filter by device status, by order number, by model family, by MDM server — stack filters to narrow to exactly the specific devices you want.
• MDM server list and assignments — see every server and what's assigned to it.
• Bulk assign / unassign — multi-select in the table, pick a destination server, go. Or import a CSV if that's how your desired state arrives.
• Export to CSV or JSON — selection or filtered results out through the macOS share sheet.
• Multi-profile switching — flip between Apple Business & School Manager instances from the sidebar; manage credentials in settings.

Filters

The filters match the web — same categories, same stacking behaviour — so if you already use the ABM filters, you already know how these work. The difference is that here they run against a native table with every device already loaded, so stacking is instant, the selection carries into bulk assign/unassign in one click, and the filtered set exports to CSV or JSON through the share sheet.

Filter by order number, device status, model family, or MDM server — and stack them, so "unassigned iPads from the last PO that haven't been routed to Intune yet" is three clicks.

Once you've narrowed to the right cohort, export (CSV/JSON) or bulk-reassign works on the filtered selection — not on the whole fleet.

What You Get

• Pure Swift 6 binary — no external runtime dependencies.
• Credentials stored in the macOS Keychain — data-protection class, no per-app ACL prompts.
• Multiple profile support — manage several AxM instances (school-district-east, business-unit-3, whatever) from a dropdown instead of –profile flags.
• Automatic OAuth 2 client-assertion handling — token lifecycle handled for you.
• Paginated device fetch — walks the full inventory without you worrying about page cursors.
• Bulk operations — CSV import or multi-select directly in the GUI table.
• StrictConcurrency enabled — actor-isolated, race-free by design.
• Bulk device-to-server resolution — server-side device listing gets the whole fleet in 4–5 API calls regardless of size, instead of per-device lookups.
• Bulk AppleCare enrichment — list-devices –include-applecare runs a two-pass fan-out across the whole fleet, no CSV required.

Recent API Coverage

I've kept the tool caught up with the AxM API as Apple has shipped new fields:

• API 1.5 — MAC addresses now support multiple values (array format) for devices with multiple network interfaces.
• API 1.4 — Wi-Fi, Bluetooth, and built-in Ethernet MAC addresses for macOS.
• API 1.3 — AppleCare coverage lookup for devices (single-serial via get-devices-info, whole-fleet via list-devices –include-applecare).
• API 1.2 — Wi-Fi and Bluetooth MAC addresses for iOS, iPadOS, tvOS, and visionOS.

Running in the Cloud

Alongside the GUI app, the other side of the coin — fully cloud, headless operations — has gotten a lot of work too. Fully static Swift runtime via –static-swift-stdlib, URLSession fixes for musl, and keychain-less credential provisioning from env vars so the same codebase runs cleanly on Ubuntu. One Swift 6 binary, one data model, one API client — running unchanged inside Azure Functions, AWS Lambda, or any Linux container.

Cloud automations that the Linux binary offers:

• Reconciliation (inventory → Apple) — a trigger fires off a desired-state list (a CSV, a DB query, an event), the function asks asbmutil what Apple Business & School Manager currently shows, diffs the two, and issues assign/unassign calls to close the gap. Anything the inventory system considers authoritative — MDM server, department, ownership tags — can drive the comparison.
• Enrichment (Apple → inventory) — a timer pulls the full device list plus AppleCare coverage via asbmutil, hashes the normalised payload per serial, stores the fingerprint in blob storage, and only writes back to inventory when the Apple-side data has actually changed. Warranty months, coverage status, order number, MDM assignment — all flow in automatically, and the hash cache keeps API traffic and downstream write-load proportional to real change, not fleet size.

Outcome: inventory and Apple Business & School Manager stay in lockstep without anyone opening either UI. Warranty data flows in one direction, MDM assignments in the other, both driven by the same Swift binary you'd run on your Mac.

I plan to write in more detail how I'm running these and the code behind them in follow-up posts.

How to Use All Three

The CLI has its place. It's the thing I'll use to check which MDM a device is assigned to when I need quick operations — asbmutil list-devices-servers –mdm "Intune" piped through jq and grep, done in a second.

For bulk operations I reach for the GUI app — load a CSV, select in the table, hit the button. Being able to see what's assigned, what's unassigned, and peruse the fleet side-by-side catches mistakes before they ship and surfaces clean-up opportunities you'd miss on the command line.

And for the continuous, unattended work — nightly syncs, warranty enrichment, inventory reconciliation — the Linux binary inside a serverless function quietly does it in the background, no interaction, automated.

Same data model, same trust store, same API calls underneath.

Grab It

Repo: github.com/rodchristiansen/asbmutil

Grab the latest .pkg or .dmg from the releases page. The installer drops both the app into /Applications and the asbmutil CLI into /usr/local/bin.

A note on signing: the released artifacts are unsigned and not notarized. On first launch Gatekeeper will complain — clear the quarantine attribute and you're good:

xattr -dr com.apple.quarantine /Applications/ASBMUtil.app
xattr -dr com.apple.quarantine /usr/local/bin/asbmutil

Or build and sign it yourself from source — make build in the repo will do the whole signing + notarization dance if you drop your own Developer ID into .env. As Mac admins you know the drill.

Requirements: macOS 14+, and an AxM API account with a client ID, key ID, and PEM. If you already have the CLI configured, the app reads the same keychain profiles — nothing to migrate.

More posts coming on the specific things this tool makes trivial that ABM's web UI makes painful — starting with the bulk device-to-server resolver, which I think is the most interesting piece of the codebase. For now: v1 of the app exists, it works, and I'd love to hear where it breaks for you.

QuickLook on the Mac doesn't support previewing the contents of YAML files. You're digging through repos, config files, CI pipeline files, playbooks, terraform plan and you want to peek at a YAML file without opening it.

You hit Space.

Nothing. Just the generic document icon staring back at you.

QuickLook on the Mac supports text files, plists, JSON—but YAML? Nothing out of the box. I fixed that with YAML Quick Look.

What It Does

It's a native macOS Quick Look extension that does two things:

1. Preview: Hit Space on any .yaml or .yml file, and you get a clean, scrollable plain-text view—same experience as .txt or .plist.
2. Thumbnails: Finder shows file content in the icon itself, so you can tell files apart without opening them.

Dark mode works. Large files are handled (truncated at 10 MB so it doesn't eat your RAM). It uses a shared YAMLFileReader module backing both extensions, so the behaviour is consistent.

It's not a syntax highlighter—that was a deliberate choice. Quick Look is for glancing, not editing. Plain text, monospace, scrollable. That's it.

Why I Wrote This

Honestly, it was scratching my own itch. I spend a lot of time in repos and Terraform configs, and the missing YAML preview was a small but consistent annoyance.

There are third-party alternatives, but most of them are either abandoned, use Homebrew, or are bundled inside larger editor apps. I wanted something clean, native, and deployable via a single pkg.

It's available on GitHub under MIT. It requires macOS 14 Sonoma or later.

The App

The app is three targets:

• YamlQuickLook — A lightweight container app. You open it once to register the extensions, then mostly ignore it. I added Status, Preview, and Settings tabs to make it feel like a real app rather than a hollow shell.
• YamlQuickLookExtension — The Quick Look preview extension
• YamlQuickLookThumbnailExtension — The thumbnail generator

The shared module (YamlQuickLookShared) handles all the file reading logic, so both extensions stay thin. The test suite covers 38 cases across the reader—everything from empty files to malformed YAML to files at the size limit.

Installing It

The simplest path: grab the latest zip from Releases, move the app to /Applications, and run the post-install script to strip quarantine and activate the extension:

xattr -cr /Applications/YamlQuickLook.app
pluginkit -a /Applications/YamlQuickLook.app/Contents/PlugIns/YamlQuickLookExtension.appex || true
pluginkit -a /Applications/YamlQuickLook.app/Contents/PlugIns/YamlQuickLookThumbnailExtension.appex || true
qlmanage -r
qlmanage -r cache

Building with Code Signing

The release build isn't code-signed—I don't have (yet) a Developer ID. You can sign and notarize with your own cert for your environment. I plan to release it onto the Mac App Store.

If you want a properly signed and notarized build—which I'd recommend for org-wide deploys—clone the repo and configure signing in Xcode for all three targets:

xcodebuild -scheme YamlQuickLook \
  -configuration Release \
  -derivedDataPath build \
  CODE_SIGN_IDENTITY="Developer ID Application: Your Name (TEAM_ID)" \
  DEVELOPMENT_TEAM="TEAM_ID" \
  clean build

Then notarize it with xcrun notarytool and staple the ticket. The README has the full steps. A signed build skips the xattr step entirely and removes the quarantine friction for your users.

The Makefile also has a make release target that handles the signing and notarization flow if you've set up your credentials in .env.