SwiftX
All case studies
Refurbishment & ElectronicsmacOSHardware DiagnosticsRefurbishment

Refurbishment Diagnostics: Evidence Over Opinion

Apple Device Refurbisher (MENA)

A native macOS diagnostic app that replaces subjective refurb grading with behavioral detection — across CPU thermals, fan-and-acoustic, SSD lifespan and I/O, RAM stability, I/O ports, and battery — producing per-unit telemetry the operator can stand behind.

Diagnostic telemetry dashboard representing per-unit hardware inspection
Diagnostic domains
6 — CPU · fans · SSD · RAM · I/O · battery
Architectures
Apple Silicon + Intel
Modes
Self-test + DFU triage
Telemetry
JSON + versioned CSV

Refurbishment Diagnostics: Evidence Over Opinion

A native macOS diagnostic app that replaces subjective refurb grading with behavioral detection — across CPU thermals, fan-and-acoustic, SSD lifespan and I/O, RAM stability, I/O ports, and battery — producing per-unit telemetry the operator can stand behind.

The problem

Incoming-inspection grading at a refurbishment line had five structural problems:

1. Subjective grading. Two technicians on the same MacBook produced different grades. Verdicts hinged on which advisory threshold the tech happened to trust, how long they let stress run, whether they noticed the fan plateauing. There was no defensible record of why a unit was graded the way it was.

2. Vendor thresholds that don't fit refurb work. Apple's advisory ranges are designed for warranty triage on units sold within the past year, not for grading a four-year-old MacBook Pro coming off-lease — with paste degradation, fan-bearing wear, and a battery on its 800th cycle. Applied mechanically, they fail healthy units; applied loosely, they grade-up failing ones.

3. Two boot states, two workflows. A non-booting Mac couldn't be tested on the same workstation. Tethered DFU/Recovery tools lived on a second bench; a battery analyzer on a third; the technician carried verdicts between them on paper. No unified record. No way to correlate a battery anomaly seen in master mode against a thermal anomaly seen later during inspection.

4. No structured telemetry. Existing tools produced screenshots, not data. When a downstream customer disputed a grade weeks later, the refurbisher had a PDF. Cross-quarter fleet questions — "are we seeing more fan stalls on MacBookPro16,1 this quarter?" — were unanswerable.

5. Apple Silicon SMART blackout. On Apple Silicon, NVMe SMART data isn't exposed through public framework APIs. Most tools reported "unsupported" for half the fleet — meaning lifespan and write-endurance verdicts were silently unavailable on every M-series unit the line handled.

The approach

We built RefurbIQ, a native macOS app (with a SMJobBless-installed root helper) that replaces subjective grading with behavioral detection across every diagnostic surface a Mac exposes. Five pillars drove the architecture:

Pillar 1 — Behavioral detectors, not vendor thresholds. Verdict logic looks at what the part did during the test, not at what a spec sheet says it should report:

  • Fan stall fires when fan0RPM == 0 across the entire substantial sample window, regardless of chassis temperature — temperature-gated detectors miss a fan that never moves because the chassis never reaches the floor.
  • Fan stuck-high requires a dual-signal gate: high idle RPM and low modulation under stress. A MacBookAir8,2 chassis idling at 2700 RPM but modulating +1900 under stress is responsive, not stuck.
  • SSD I/O degradation is detected through F_NOCACHE + F_FULLFSYNC throughput stress, with per-chassis throughput tiers operators can override at runtime. SMART-clean SSDs that have lost write speed — invisible to traditional tooling — still trip the catastrophic threshold.

Each detector is regression-tested against telemetry captured from real reference hardware, including an i9-9980HK with documented NAND degradation.

Pillar 2 — One workflow, both boot states. A single app, a single record format. Inspection mode runs on a booting Mac across CPU thermals, fan-and-acoustic correlation, SSD lifespan and I/O, RAM stability, and I/O ports. Master PC Inspector triages a non-booting Mac tethered over USB-C in DFU/Recovery, using bundled signed irecovery and macvdmtool plus direct battery telemetry over the system management bus. Verdicts aggregate into the same CSV schema regardless of mode.

Pillar 3 — Per-unit telemetry, fleet-queryable. Every run writes per-domain JSON files and appends a row to a versioned aggregate CSV — same schema across the fleet, archivable, queryable, defensible. When a domain adds a column, the schema version bumps and on-disk files are migrated forward automatically. A year of inspection data is one SQL load against a single file.

Pillar 4 — Apple Silicon SMART, restored. We ship a bundled, codesigned universal smartctl binary, invoked from the privileged helper over XPC. Apple Silicon NVMe lifespan, power-on hours, and write-endurance percentages are now present for every supported M-series Mac. The IORegistry path remains a fallback if smartctl fails to parse.

Pillar 5 — Native and auditable, end to end. Universal binary (arm64 + x86_64). Architecture branches where silicon demands — Intel reads SMC directly; Apple Silicon parses powermetrics over XPC — but the verdict surface and the export format stay unified. Distributed via Developer ID, not the App Store, so refurbishment lines can deploy without store-review delays on every release.

How we built it

  • Language & UI: Swift, SwiftUI, AppKit interop
  • Concurrency: structured async/await, async let for parallel test phases under a DiagnosticOrchestrator
  • Privilege model: SMJobBless-installed root helper, NSXPCConnection over a Mach service, retry-wrapped read-path calls
  • Telemetry surfaces: powermetrics (Apple Silicon), SMC keys (Intel), IOKit NVMe user client, NVMe Log Page 02h, IORegistry parsing, AVAudioEngine with IEC 61672 A-weighting, F_NOCACHE + F_FULLFSYNC I/O probes, vendored universal smartctl, irecovery, macvdmtool
  • Test framework: Swift Testing (@Suite, @Test) with reference-hardware regression suites
  • Distribution: Developer ID-signed universal binary (arm64 + x86_64), ad-hoc and notarized channels — not via the Mac App Store

Business impact

  • Repeatable verdicts. Two technicians running the same unit produce the same grade. The decision is the device's behavior, recorded.
  • Audit-ready records. Every "Pass" or "Refurb-unsafe" verdict is backed by the actual telemetry that produced it — retained in JSON and CSV, retrievable weeks or months later.
  • Single tool, every boot state. Booting and non-booting Macs feed the same record format. The technician carries no paper between benches.
  • Fleet visibility. A versioned CSV schema means cross-quarter trend queries are a single SQL load against the aggregate file.
  • Apple Silicon, no blind spots. SMART data for M-series Macs now matches the depth of Intel-era reporting — lifespan, endurance, and power-on hours are present in every record.
  • No vendor lock. Behavioral detection generalizes across Mac model families, today and across new silicon generations — the same detector logic that catches a MacBookPro16,1 fan stall catches the next generation's fan stall.

Why it matters

Refurbishment grading is, ultimately, a claim. The operator says this unit passes — and somewhere downstream, a buyer trusts that claim or doesn't. The traditional toolchain offered no way to back the claim with evidence: a screenshot is not data, an advisory threshold is not a refurb spec, and a non-booting unit was a separate workflow entirely.

RefurbIQ replaces the technician's judgment with the device's own behavior, recorded in a format that holds up to inspection. Verdicts are reproducible, telemetry is queryable, and the same record format spans every boot state and every Mac generation the line handles.

The architecture is built to extend. New behavioral detectors slot into the orchestrator with the existing telemetry contract. New domains — battery cycle modeling, display panel uniformity, port wear — ship without disturbing the verdict aggregation. The result is a diagnostic platform that gets sharper as the fleet's data does — without ever asking a technician to decide whether 7,200 RPM is "high enough."

Ready to architect your transformation?

Start a project