Nikon MAID SDK on macOS Apple Silicon

Background

eclipseClick is a desktop application for automated eclipse photography. It controls Canon, Sony, and Nikon cameras via their respective SDKs. On Windows, Nikon camera control uses the MAID SDK (Module Architecture for Imaging Devices) — a proprietary C API where Nikon distributes camera-specific .md3 module files for each supported camera model.

My native C++ bridge (NikonBridge) loads these modules via LoadLibrary/GetProcAddress, calls MAIDEntryPoint to communicate with the camera, and exposes functionality via JSON-RPC over stdio.

The goal: get this same Nikon camera control working on macOS, specifically on Apple Silicon (M1/M2/M3) Macs.

The Journey of Failures

The Solution: libgphoto2

After determining the MAID SDK is fundamentally incompatible with Apple Silicon, I chose libgphoto2 — an open-source library that communicates with cameras via the PTP (Picture Transfer Protocol) standard over USB. It runs natively on ARM64 via Homebrew.

How libgphoto2 Differs from MAID SDK

Property Name Translation

MAID uses Nikon-specific capability IDs. libgphoto2 uses PTP property names. I built a translation layer mapping canonical names to gphoto2 widget names (e.g., shutterSpeed → shutterspeed, driveMode → capturemode).

Value Format Differences

Shutter speeds: MAID returns "1/125", "1/250". libgphoto2 returns decimal seconds like "0.0080s". I snap to the nearest standard Nikon denominator from a table of 35 values.

Drive modes: MAID returns "ContinuousShooting". gphoto2 returns "Burst". The app's readiness checklist checks for "continuous" in the label, so translation was critical.

Allowed values: MAID returns only currently-valid values (which change based on lens and mode). gphoto2 returns ALL PTP-defined values, including unsupported ones.

Performance: The PTP Protocol Tax

The MAID SDK uses asynchronous callbacks for capture pipelining. libgphoto2's synchronous PTP implementation adds ~2 seconds overhead per capture. For eclipse totality bursts, DSUSB at 3 fps is the recommended capture method on both platforms.

Other macOS Challenges

ptpcamerad

macOS runs ptpcamerad — a system daemon that claims exclusive USB access to PTP cameras. It must be killed before libgphoto2 can communicate with the camera, and it respawns immediately. SIP prevents permanent disabling.

Canon EDSDK on Apple Silicon

Canon's EDSDK is also x86_64 only, but works under Rosetta (no PAC issues — it's a proper Framework, not a bundle with ObjC internals). The Electron app builds as x64, and in dev mode I use a separate x64 Node.js binary for the Canon bridge subprocess.

Final Architecture

eclipseClick (Electron, arm64)
├── Canon Bridge (x64 via Rosetta)
│   └── EDSDK.framework
├── Nikon Bridge (arm64 native)
│   └── libgphoto2
├── Sony Bridge (arm64 native)
│   └── Sony CrSDK (universal)
└── DSUSB Shutter (HID)

eclipseClick (Electron, x64)
├── Canon Bridge (x64)
│   └── EDSDK.dll
├── Nikon Bridge (C# .NET 8)
│   └── MAID SDK .md3 modules
├── Sony Bridge (x64)
│   └── Sony CrSDK
└── DSUSB Shutter (HID)

Lessons Learned

1. 1

   Don't assume .dylib = macOS module. Nikon's MAID modules are .bundle directories, not flat dylibs.

2. 2

   CFBundle vs dlopen matters. macOS bundles loaded via dlopen can't find their own resources.

3. 3

   Rosetta has limits. x86_64 code using ObjC dispatch or IOKit USB hits PAC failures on Apple Silicon. These are unfixable.

4. 4

   PTP is slow. Designed for file transfer, not real-time camera control. Each operation requires a full USB round-trip.

5. 5

   Kill ptpcamerad. macOS's PTP daemon claims exclusive device access. Third-party USB camera libraries must race against its respawn.

6. 6

   Open-source alternatives exist. libgphoto2 supports 2000+ cameras natively on ARM64. Not as fast as proprietary SDKs, but it works.