[Tracker] macOS support status

[axpnet]

AeroFTP macOS Support Status

Umbrella issue tracking the state of AeroFTP on macOS: which OS versions and hardware are confirmed working, what is still open, and the remaining roadmap item (Apple code signing and notarization).

Current release: v4.1.6. Every release ships two native builds: AeroFTP_<version>_aarch64-beta.dmg (Apple Silicon, no Rosetta) and AeroFTP_<version>_x64-beta.dmg (Intel).

Before opening a new macOS issue, please check this page. If your case is already listed, add a thumbs-up reaction or a comment with your exact macOS version, hardware (Intel or Apple Silicon model) and the AeroFTP version. We keep this issue updated as reports come in.

Note on installation: the macOS build is still in beta and not yet signed or notarized with an Apple Developer ID, so Gatekeeper marks it as "damaged" on first launch. One-time workaround after moving the app to Applications:

sudo xattr -rd com.apple.quarantine /Applications/AeroFTP.app

Help wanted: macOS testers

Our macOS coverage is limited by how many hardware and OS combinations one small team can own, so confirmed real-world reports are worth a lot to us. If you run AeroFTP on a Mac, a short report helps. Please include:

• macOS version (Apple menu > About This Mac)
• Hardware: Intel or Apple Silicon, and the model (e.g. MacBook Pro 2015 i7, or M2 Air)
• AeroFTP version and which dmg you used (aarch64 or x64)
• Does it boot into the full UI? Does a test connection work (e.g. anonymous FTP to test.rebex.net)?

Drop it as a comment here or thumbs-up an existing row that matches your setup. We credit confirmed reports in the "Confirmed working" table below.

Confirmed working

macOS	Architecture	Hardware	Build tested	Confirmed by
Big Sur 11.7.11	Intel	MacBook Pro 13" Mid 2014, Core i5 2.8 GHz	Intel preview (4.0.x)	maintainer (internal)
Monterey 12.7.6	Intel	MacBook Pro 2015, Core i7	4.0.4_x64-beta.dmg	@reset131
26.5.1 (25F80)	Intel	MacBook Pro 16" 2019, Core i9 8-core	4.1.1_x64-beta.dmg	@JonathanHarford
Tahoe 26.6	Apple Silicon	M5	4.0.4_aarch64-beta.dmg	@alexhorner
Tahoe 26.5.1	Apple Silicon	MacBook Air 15" M4, 2025	4.1.1_aarch64-beta.dmg	kramer

Coverage spans Intel and Apple Silicon, from Big Sur through the latest Tahoe.

Open: Gatekeeper "damaged and can't be opened" 🟡

This is the one macOS item still open, and it affects every Mac, every macOS version and both architectures. It is not an AeroFTP bug: Gatekeeper shows that message for any app not signed with an Apple Developer ID and notarized, which is the same barrier every unsigned open-source Mac app hits. Nothing in the app can work around it from the inside, only the signing itself removes it.

Until then, the one-time command at the top of this page is the fix, run once after moving the app to Applications:

sudo xattr -rd com.apple.quarantine /Applications/AeroFTP.app

Every subsequent launch works normally. This is tracked here rather than as a separate bug (#77 was closed into this page on 2026-07-28). Progress lives in the roadmap at the bottom of this issue, and we will comment here the day signing and notarization land, so the workaround disappears for good.

Waiting for signing: @juanlopez4691. If you would like a ping when it ships, comment on this issue or add a thumbs-up here and we will add you to the list.

Resolved (historical)

#	macOS	App	Resolution
#241	Intel (all)	4.0.4	Native Intel x64-beta.dmg restored alongside Apple Silicon, confirmed by @reset131 on Monterey 12.7.6. Closed 2026-07-28
#47	26.2 / 26.3 (Apple Silicon)	2.9.1 to 4.0.4	Main-thread deadlock was an upstream TAO bug, fixed in tao 0.35.2 shipped in v4.0.4. Closed 2026-07-28 on the Apple Silicon macOS 26.x confirmations in the table above
#290	Tahoe 26.6	4.0.0 to 4.0.4	0x0 window self-heal landed in v4.0.4, confirmed by @alexhorner. Closed 2026-07-28
#77	26.4 (M1 Pro)	3.3.4	Gatekeeper "damaged": not a code bug, folded into the Gatekeeper section above. Closed 2026-07-28
#98	26.3.1	3.4.8	Menu bar Quit, closed
#62	Intel	3.x	Non-interactive UI: App Sandbox removed, JIT and WebKit entitlements added in v3.1.5

Remaining roadmap

• Apple Developer ID code signing
• Notarization (removes the Gatekeeper workaround entirely)

_{Status legend: 🔴 confirmed · 🟡 investigating · 🟢 fixed (pending release) · ✅ released}

---

Maintained by the AeroFTP team.

[JonathanHarford]

MacOS 26.5.1 (25F80)
MacBook Pro 16-inch 2019, 2.3 GHz 8-Core Intel Core i9
AeroFTP 4.1.1 x64

Looks like full UI to me! Test connection to rebex does not work ("The server is taking longer than usual to respond") but SFTP to my server works beautifully.

[axpnet]

Thanks for the detailed report, @JonathanHarford, this is a great addition to our coverage.

Two useful firsts here: it's the first confirmed Intel machine on a Tahoe-era macOS (26.5.1), and the first confirmation on 4.1.1. A full UI plus a working SFTP session to your own server is exactly the signal we look for, so we've added your setup to the "Confirmed working" table above:

macOS	Architecture	Hardware	Build tested	Confirmed by
26.5.1 (25F80)	Intel	MacBook Pro 16" 2019, Core i9 8-core	4.1.1_x64-beta.dmg	@JonathanHarford

On the test.rebex.net timeout: that's almost certainly not AeroFTP itself. Since SFTP connects and transfers fine, your network stack and the client are healthy. test.rebex.net is plain anonymous FTP, which opens a separate passive data connection on a high port, and those passive ports are frequently slow or blocked on home and corporate networks (and the public Rebex box is occasionally sluggish on its own). If you want to sanity-check plain FTP, a quick retry or a different FTP endpoint usually goes straight through. SFTP working the way it does is the important result.

Thanks again for taking the time to test and write it up, credited above.

[axpnet]

macOS builds move off the retiring macos-14 runner (brownouts from October 5)

GitHub is retiring the macos-14 runner image on November 2, 2026. Before that, every job on it fails on purpose during scheduled brownouts: October 5, 12, 16, 19, 23, 26, 29 and 30, each from 14:00 UTC to midnight UTC.

AeroFTP builds both macOS releases on that image: the Apple Silicon DMG and the Intel DMG (cross-compiled on the same arm64 machine). The AeroRsync test matrix uses it too. Without a change, any pull request or release built during a brownout would get no macOS packages.

Why this is not a one-line change. The image is pinned on purpose: when AeroFTP tried macOS 15, the DMG packaging step of Tauri failed there. So I am testing before switching, rather than switching and hoping.

What I am testing, on a separate branch, before October 5:

1. Both DMGs (Apple Silicon and Intel) built on macos-15 and on macos-latest (macOS 26): the build, the DMG packaging, and that the image mounts and holds the app with every binary it ships (the GUI, the CLI and the helpers).
2. The AeroRsync test matrix on the same images.

Possible outcomes

• A. Packaging works on macOS 15 or 26. The builds move to that image and nothing changes for you: same DMGs, and the same minimum macOS version (checked as part of the test).
• B. Packaging still fails there. The app bundle is built as today and the DMG is created by AeroFTP's own packaging step instead of Tauri's. Same result for you, a different tool behind it.
• C. The fix needs a newer Tauri. AeroFTP is pinned to Tauri 2.11.0 because 2.11.1 broke file-access permissions, so an update would come only after that is verified, and B would bridge the gap.

Nothing changes in the releases already published, and nothing changes for Linux or Windows. I am reopening this tracker for it: the test results and the chosen option will follow here, and it closes again once the builds run on the new image.

[axpnet]

Results: macOS builds now run on macOS 15

Outcome A: Tauri's DMG packaging works on macOS 15 (and 26) for both the Apple Silicon and the Intel DMG, with the current Tauri version. Both installers and the AeroRsync checks now build on a pinned macos-15 (#1039).

Nothing changes for you: the binaries still run from macOS 10.13 (Intel) and 11.0 (Apple Silicon), checked on the binaries themselves; only the SDK moves from 14.5 to 15.5. Every macOS build now also compares its DMG with the last release and fails if a binary is missing, has the wrong architecture or needs a newer macOS.

The developer test tool seed_test_profiles, found in the v4.2.1 Windows and macOS packages, is no longer shipped (#1043).

This ships in v4.2.2. main now builds on macOS 15 (build), so I am closing this tracker again.