Ham Radio Software for Mac: 8 Apps Tested on an M4

WSJT-X 3.0.1 finally ships a native Apple Silicon build, and on my Mac it opens straight into an error. The program asks macOS for 48,275,376 bytes of System V shared memory. macOS 26.4.1 allows 4,194,304 by default, so the request fails with EINVAL and WSJT-X stops at "Unable to create shared memory segment" before its decoder ever starts. Google's autocomplete for "wsjt-x mac" already offers "wsjt x mac shared memory error", and the error has a mechanical answer, which I'll get to. It was also only one of three surprises from putting eight ham radio programs on one M4.

Scope first. Nothing here touched a radio: no rig, interface or antenna was connected, so I didn't decode a signal, key a transmitter or test CAT control. What I did on 2026-10-21 was download the current Mac builds of WSJT-X, WSJT-X Improved, JS8Call, fldigi, flrig, MacLoggerDX, QLog and Pat onto an M4 Mac mini running macOS 26.4.1 without Rosetta. I checked every executable with lipo, read signatures with codesign and Gatekeeper's verdict with spctl, launched each app for 12 seconds, and traced WSJT-X's shared memory call with a small interposer library. Interface problems come from owner threads on the Digirig forum, linked where I use them.

Eight ham radio apps on an Apple Silicon Mac

App	Job	Build checked	Binaries	Gatekeeper	On this Mac
WSJT-X (arm64 pkg)	FT8, FT4, WSPR, Q65	3.0.1	66, all native	Rejected: package unsigned, app ad-hoc	Opens, then shared memory error
WSJT-X (Intel DMG)	Same	3.0.1	67, all Intel-only	Accepted: Developer ID, notarized	Won't start: Bad CPU type
WSJT-X Improved	FT8 fork with extra features	3.2.1 (261010, Qt6 ARM)	65: 43 native, 22 universal	Rejected: no usable signature	Opens, then shared memory error
JS8Call	Keyboard chat over FT8-style signals	3.0.3, 2026-07-12	35, all native	Accepted: Developer ID, notarized	Runs
fldigi	PSK, RTTY, Olivia and most text modes	4.2.13	1, universal	Accepted: Developer ID, notarized	Runs
flrig	Rig control	2.0.12	1, universal	Accepted: Developer ID, notarized	Runs
MacLoggerDX	Logging, rig control (paid)	6.62	3, universal	Accepted: Developer ID, notarized	Runs
QLog	Logging (free)	0.54.0 DMG, 2026-10-20	69, all native	Accepted: Developer ID, notarized	Crashes at launch on macOS 26
QLog	Same	0.53.0 DMG, 2026-09-18	73, all native	Accepted: Developer ID, notarized	Runs
Pat	Winlink email client	1.0.0, 2026-04-19	1, Intel-only	Package unsigned	Won't start: Bad CPU type

The pattern is close to the reverse of what I found for astrophotography software for Mac, where the capture tools were Intel-only. Here almost everything has a native or universal build. The trouble is in how the builds are packaged.

WSJT-X: two builds, two different problems

The WSJT-X download page now lists a separate "macOS — Apple Silicon (arm64)" package next to the Intel one. On SourceForge, 3.0.1 also still offers wsjtx-3.0.1-Darwin.dmg, and that disk image is the Intel build: all 67 binaries are x86_64. It is signed and notarized, so Gatekeeper is happy, but without Rosetta it stops at Bad CPU type in executable.

The arm64 package is the reverse. Every binary is native, but pkgutil --check-signature reports "no signature" for the package, the app inside carries only an ad-hoc signature, and spctl rejects both. If you downloaded it in a browser, expect macOS to refuse it until you allow it under Privacy & Security. I downloaded with curl, which sets no quarantine flag, so I didn't see that dialog myself; the com.apple.quarantine attribute explains why the download method matters.

The package also does more than copy an app. Its postinstall script, which runs as root, does three things:

/bin/launchctl load /Library/LaunchDaemons/com.wsjtx.sysctl.plist
/usr/sbin/sysctl kern.sysv.shmmax=52428800 kern.sysv.shmall=25600
ln -sf /usr/local/wsjtx/* /usr/local/bin/   # jt9, wsprd and 15 other tools

So the arm64 installer sets the shared memory limit for you, both immediately and at every boot through a LaunchDaemon. I didn't run it: it needs an administrator password and writes to /Library/LaunchDaemons, and this Mac runs other jobs I don't want to disturb. What I measured is the problem it exists to fix.

The shared memory error, measured

WSJT-X's interface and its jt9 decoder pass audio through a System V shared memory segment. Here are the limits on a stock macOS 26.4.1 install:

$ sysctl kern.sysv.shmmax kern.sysv.shmall
kern.sysv.shmmax: 4194304
kern.sysv.shmall: 1024

A five-line Python test confirmed the ceiling: shmget succeeded at 4,194,304 bytes and failed with errno 22 at 4,194,305. To see what WSJT-X asks for, I copied the app, re-signed the copy without the hardened runtime so macOS would load an interposer library, and logged every shmget call:

[shmlog] shmget(key=0x510fb06e,size=48275376,flags=03600) = -1 errno=22 Invalid argument

WSJT-X Improved 3.2.1 made the same 48,275,376-byte request. In both cases the app stayed open but no jt9 process ever appeared. JS8Call 3.0.3 doesn't link shmget or Qt's shared memory class at all, and it ran with the default limits. fldigi, flrig and MacLoggerDX don't use it either.

The fix ships inside the Intel DMG as com.wsjtx.sysctl.plist, a LaunchDaemon that runs sysctl with the two values above at boot. The DMG's ReadMe has you copy it to /Library/LaunchDaemons with sudo, set the owner to root:wheel and reboot. Two later notes matter. The ReadMe says that on Sonoma 14.6 or later you must also switch "sysctl" ON under System Settings › General › Login Items. The WSJT-X Improved release folder adds a text file for macOS 27: if sysctl -a | grep sysv.shm still shows the old value after a reboot, check the plist for a com.apple.quarantine attribute, remove it with sudo xattr -d, set mode 644, and load it with launchctl load -w. A quarantined plist dragged in from a browser download is a plausible reason the daemon never runs.

After a reboot, check the value before opening WSJT-X:

$ sysctl kern.sysv.shmmax
kern.sysv.shmmax: 52428800

If it shows 20971520, JTDX has set it, and WSJT-X will still fail.

QLog 0.54.0 won't launch on macOS 26

QLog is a free logger. Its README says the Mac DMGs are built by a separate maintainer and published in aa5sh/QLog releases. Version 0.54.0 appeared there on 2026-10-20. On this Mac it dies before drawing a window, with exit code 134:

dyld: Symbol not found: _pipe2
  Referenced from: .../QLog.app/Contents/Frameworks/libusb-1.0.0.dylib
  (built for macOS 27.0 which is newer than running OS)

The app's Info.plist claims macOS 14.4 as the minimum. vtool disagrees: 65 of the bundled libraries declare a minimum of macOS 27.0. In 0.53.0 the same libraries declare 26.0, and that build ran fine here. My guess is that the libraries come from whatever machine builds the DMG and inherit its macOS version, but that is inference from the version numbers, not something the project has said. If you're on macOS 26, use 0.53.0 until a fixed DMG appears. I couldn't test 0.53.0 on macOS 14 or 15, and its 26.0 libraries suggest it may not work there either. The fork has GitHub issues turned off, so I couldn't find any existing report.

Native and fine: JS8Call, fldigi, flrig, MacLoggerDX

JS8Call 3.0.3 is native and notarized, and the download page lists only an Apple Silicon DMG for this version, so Intel Mac users are the ones who need an older release now. fldigi 4.2.13 and flrig 2.0.12 are single universal binaries and both are notarized. That contradicts the project's own readme.dmg.txt, which still says the DMGs are "signed, but not certified by Apple". MacLoggerDX 6.62 is universal and notarized, and its minimum is macOS 10.13. All four launched and stayed up.

Pat, the open-source Winlink client, publishes only a darwin_amd64 package for 1.0.0, so it needs Rosetta on Apple Silicon even though the Pat site lists macOS as supported. CHIRP, the radio programming tool behind the "does chirp work on mac" searches, says its current build is universal for Big Sur and later, but its download server returned a Cloudflare 403 to my scripted requests, so I haven't verified that. Ham Radio Deluxe has no Mac version; its support article points Mac users to a Windows virtual machine.

The interface between the Mac and the radio

Software is half the setup. The other half is an audio interface plus a serial port for CAT and PTT. The WSJT-X ReadMe says the USB serial chip inside Icom, Yaesu and Kenwood radios is a Silicon Labs bridge, and it sends Mac users to Silicon Labs for a driver, but on macOS 26.4.1 Apple's own driver already matches the CP2102 IDs. USB to serial adapters on a Mac has the full list of IDs macOS covers without extra software. The audio side is a standard USB audio device, so macOS needs no driver for it.

The Mac-specific complaints are about audio levels. In a Digirig forum thread from 2026-10-18, Digirig's K0TX notes that the CM108B audio chip has an automatic gain control setting, but "Apple's USB audio driver has no UI for them, not even an input level slider", and that macOS blocks direct USB control of the chip. The workaround found in that thread is setting input volume through Audio MIDI Setup or an aggregate device. An FT-450D owner using fldigi couldn't get transmit audio low enough to stop ALC on two different Macs and concluded the combination wouldn't work for that radio. A TS-480 owner on a MacBook Pro saw the WSJT-X waterfall turn noisy after 10 to 15 minutes, and reselecting the audio device cleared it each time. And an M1 MacBook Pro owner had the Digirig audio device drop out intermittently. Not every Mac report is a Mac problem: one owner who lost CAT control after updating to macOS 26.3 later found a plug sitting 1 mm out of its socket.

As an Amazon Associate I earn from qualifying purchases. The Digirig Mobile was $64.95 and in stock for a New York address as of 2026-10-21, with a 4.8 rating from 575 reviews. Its listing describes a CP2102 serial chip and a CM108 audio codec, the same chips covered above. I haven't used one. If your radio has its own USB port that carries both audio and CAT, check its manual before buying one; you may not need an interface at all. If you're shopping for audio gear for the shack, audio interfaces for Mac covers class-compliant devices, and RTL-SDR on a Mac covers receive-only SDR dongles.

What to install, by job

For FT8 on an Apple Silicon Mac, use the WSJT-X arm64 package and let its installer set the shared memory limit, or install the Intel DMG's plist by hand if you'd rather not run an unsigned installer as root. Either way, confirm kern.sysv.shmmax reads 52428800 before you troubleshoot anything else. For JS8, JS8Call 3.0.3 needs none of that. For PSK, RTTY and the older text modes, fldigi with flrig for rig control is native and notarized. For logging, MacLoggerDX is the paid option that ran cleanly; for free, QLog 0.53.0 runs on macOS 26 and 0.54.0 doesn't yet. For Winlink, Pat needs Rosetta.

FAQ

How do I fix the WSJT-X shared memory error on a Mac?

WSJT-X 3.0.1 requests 48,275,376 bytes of System V shared memory, but macOS allows only 4,194,304 by default. Install com.wsjtx.sysctl.plist to /Library/LaunchDaemons, owned by root:wheel, and reboot so shmmax becomes 52428800. The arm64 package does this for you. On Sonoma 14.6 or later, also enable "sysctl" under Login Items, and on macOS 27 remove any quarantine attribute from the plist.

Does WSJT-X run natively on Apple Silicon?

Yes, from the separate arm64 package. WSJT-X 3.0.1's arm64 macOS package contains only native binaries, but it is unsigned, so Gatekeeper rejects it until you allow it. The older Darwin DMG on SourceForge is an Intel build and needs Rosetta on M-series Macs.

Is there free ham radio logging software for Mac?

Yes. QLog is free and has native Apple Silicon DMGs. Version 0.54.0, released 2026-10-20, fails to launch on macOS 26 because its bundled libraries require macOS 27, while 0.53.0 runs on macOS 26. MacLoggerDX is a paid Mac logger that ships as a universal, notarized app.

How this was checked: on 2026-10-21 I downloaded WSJT-X 3.0.1 (the arm64 package and the Darwin DMG), WSJT-X Improved 3.2.1, JS8Call 3.0.3, fldigi 4.2.13, flrig 2.0.12, MacLoggerDX 6.62, QLog 0.54.0 and 0.53.0, and Pat 1.0.0 from their official download locations onto an M4 Mac mini running macOS 26.4.1 without Rosetta. I checked every Mach-O file with lipo and vtool, signatures with codesign, pkgutil and spctl, and launched each app for 12 seconds. The 48,275,376-byte figure comes from an interposed shmget on a re-signed copy of each WSJT-X app. I didn't install the WSJT-X package, change any sysctl value or reboot, and no radio or interface was connected, so none of this tests decoding, CAT or transmit. Interface reports are from the Digirig forum threads linked above. The Amazon price, stock and rating were read the same day with a New York delivery address.