A working look at Cyberduck on macOS
Most write-ups of Cyberduck restate the protocol list and stop. That is the least useful part, because the protocol list has been the strongest thing about this application for fifteen years and nobody disputes it. The questions that actually decide whether to keep it are narrower. Is the project still moving. What does it refuse to do. And which of the jobs it gets used for is it quietly the wrong tool for.
The current release is 9.5.4, dated 25 August 2026, from iterate GmbH. It runs on macOS 10.13 or later, on 64 bit Intel or Apple silicon. It is licensed under the GPL with the source on GitHub. Those four facts already answer more than a feature table does.
The project is active, and the changelog proves it
Abandonment is the first worry with any long lived free tool, and here it is misplaced. The release history through 2026 is dense and the entries are specific rather than cosmetic.
Version 9.5.0 in June 2026 added support for Liquid Glass on macOS, alongside a substantial rework of the interface. Transfer details and the bookmark window moved to popovers, controls for unavailable options were hidden in the bookmark window, a Connect button was added there, and Connect and Disconnect entries were added to the Go menu. That is the behaviour of a project keeping pace with the platform rather than one running on maintenance.
The same release added AWS IAM Identity Center support for S3, credentials from the credential_process directive in the AWS configuration, and instance metadata retrieval using IMDSv2. Those are not consumer features. They are the things a project adds when actual infrastructure teams are filing requests.
Point releases since then have been bug fixes at the same level of specificity. A crash opening the bookmark window in 9.5.3. A crash opening a folder whose name starts with a dot in 9.5.2. Login failures against AWS GovCloud in 9.5.4. This is a maintained codebase with a real issue tracker behind it, which is the honest answer to the abandonment question.
What it is unusually good at
The protocol range is the headline and it earns the place. FTP and FTP over TLS, SFTP, WebDAV, SMB, Amazon S3, Google Cloud Storage, OpenStack Swift, Azure, Backblaze B2, Box, Dropbox, Google Drive, OneDrive, SharePoint, Nextcloud, ownCloud, Files.com, DRACOON, iRODS and Spectra BlackPearl. Very little else speaks all of that from one window, and nothing else does so for nothing.
Two capabilities deserve more attention than they get. The first is Cryptomator support, which gives client side encryption of both file contents and filenames, with directory structures obfuscated, against any of those backends. That turns an untrusted server into a usable one without adding a separate tool, and it is built in rather than bolted on.
The second is external editor integration. A file on a server can be opened in whichever editor is preferred locally, edited, and written back without a manual download and upload cycle. For anyone maintaining configuration files or templates on a remote machine, this single feature accounts for most of the time the application saves.
Behind those, the platform integration is careful. Passwords are stored in the system Keychain as internet passwords, which means they are available to other applications and validated through the Keychain's own trust settings. Quick Look works on remote files with the space bar, without downloading first. Bonjour discovers FTP and WebDAV services on the local network. The application can register as the system wide handler for FTP and SFTP links. Thirty localizations are included.
The parts that only matter after a month
Three behaviours separate a tool that gets kept from one that gets replaced, and none of them appear in a feature comparison.
Synchronisation shows a preview of the affected files before anything happens. That sounds minor until the first time a sync would have deleted a directory. The related Compare action, available when files already exist at the destination, skips files whose checksum matches and falls back to comparing modification dates when the server offers no checksum. Both behaviours require preserving timestamps, which is a setting rather than a default, and synchronisation does not work correctly without it.
Resume works, but not everywhere, and the difference is documented rather than discovered. Uploads can resume on FTP, SFTP, WebDAV and S3 through multipart uploads. Downloads can resume on FTP, SFTP, WebDAV, S3 and OpenStack. On anything outside those lists an interrupted transfer reloads from the beginning, which is worth knowing before starting a large upload on a flaky link.
Bookmarks hold up at volume. They reorder by drag and drop, filter by typing, keep a history of visited servers with a timestamp for each, and import from other clients. A Spotlight importer indexes the bookmark files, so a server can be reached from the system search field rather than from inside the application. For anyone managing dozens of servers this is the quiet reason Cyberduck stays installed long after a faster client has been tried.
Sharing is handled at the same level of detail. The HTTP URL of a selected file can be copied or opened directly, including pre-signed URLs for S3 and CDN URLs, and on Nextcloud and ownCloud the application can create share links and view or revert previous versions of a file.
What it deliberately does not do
The clearest way to understand Cyberduck is by what sits outside it, because the boundaries are drawn on purpose.
It does not mount a server as a disk. That is Mountain Duck, a separate paid product from the same developer, which presents remote storage as a volume so that ordinary applications can open from it directly. Cyberduck browses a server in its own window and moves files across the boundary explicitly. People who expect a mounted drive and get a transfer window usually describe that as a missing feature when it is a product boundary.
It does not manage local files. There is a local disk browser, but the application is built around the remote side, and nothing about it is intended to replace the Finder for day to day work on the Mac itself.
There is no terminal in it. For a tool aimed squarely at people who administer servers, this is the most consequential absence. The work pattern it produces is familiar to anyone who has done it: the transfer window on one side, a terminal on the other, and a Finder window somewhere behind both.
Support is best effort, which the project states plainly for anyone without a registration key. Bug reports go to a public tracker, discussion happens in GitHub Discussions, and there is no response commitment. For a free tool this is fair. For a workflow with a deadline attached, it is a fact to plan around rather than discover.
How the money works
| Route | Cost | What differs |
|---|---|---|
| Project site download | Nothing | A donation prompt appears around install, update and quit |
| Registration key | From 10 USD, one time | Prompt removed, key is personal and covers several machines |
| Mac App Store | 23.99 USD on the US storefront | No prompt, updates arrive through the App Store |
Nothing is feature gated in any of these. The application is the same build at the same version regardless. The App Store price exists because the donation key model is not permitted under Apple's developer agreement, so the project ships a fixed price build there instead of skipping the store.
That structure is worth understanding before judging the value. Cyberduck is not cheap software. It is free software that asks, which is a different arrangement, and the thing being bought with a contribution is the absence of a dialog rather than a capability.
Where the friction actually shows up
After a few weeks the complaints that persist are rarely about features. They cluster around three things.
Segmented downloads help throughput but the merge step is slow, and the documentation says so directly: merging the segments may take a considerable amount of time. On a large file over a fast link, the download finishes and then the application appears to hang while it reassembles. Worse, if some segments are missing the parts are left in a folder and the file cannot be restored without downloading it again or resuming the transfer.
Transfer speed on FTP has two documented penalties that are easy to trip. Enabling the change of permissions slows the transfer rate when uploading many files, and so does enabling the change of modification date. The second is the harder trade, because synchronisation requires timestamps to be preserved in order to work at all.
And the window count. Browsing a remote directory, checking something locally, and running a command against the same tree means three applications open and three separate navigation states to keep aligned. Nothing in Cyberduck causes this and nothing in it fixes it, because the local half of the job was never in scope.
Who it fits, and who should look elsewhere
It fits anyone whose remote storage is scattered across incompatible services. If one job needs S3, another needs an old FTP server and a third needs a client's Nextcloud, having one window that speaks all three is worth more than any refinement a single purpose client could offer.
It fits people on older hardware. The macOS 10.13 floor means a Mac that Apple no longer updates still runs a current build, which very few commercial tools can match.
It fits occasional use well. Open it, move something, close it. The bookmark model and the Keychain integration make that friction free.
It fits less well where the remote side needs to feel local, which is the Mountain Duck case. It fits less well where transfers are continuous and throughput is the binding constraint, since the transfer settings need real tuning before they perform. And it fits least well where the actual complaint is that local browsing, a shell and file operations are spread across three windows. That is a file manager question rather than a transfer client question, and no amount of evaluating clients against each other will answer it.
One more case is worth naming because it comes up constantly. Files that arrive from a phone or tablet before being pushed to a server pass through a different path entirely, and that half of the workflow is not something a server browser was built to smooth.
What to do with this
If the protocol range is the reason Cyberduck is installed, keep it. Nothing else covers that ground for nothing, and the project is demonstrably maintained. Contribute the 10 USD if the prompt is the only irritation, since that ends it for less than the store build costs.
If the persistent complaint is the window count rather than anything Cyberduck does badly, the tool being evaluated is the wrong one, and a file manager with a built-in terminal such as Atriens is the category to compare instead.
Frequently asked questions
Is Cyberduck still being maintained in 2026?
Yes. Version 9.5.4 was released on 25 August 2026, and the releases before it through the year include interface work for Liquid Glass, AWS IAM Identity Center support for S3, and a steady run of specific bug fixes with issue numbers attached. The source is on GitHub under the GPL.
Can Cyberduck replace the Finder?
No, and it does not try to. It has a local disk browser, but the application is built around browsing and transferring to remote servers and cloud storage. Day to day local file work stays in the Finder or in a dedicated file manager.
Why is Cyberduck 23.99 USD in the Mac App Store if it is free?
The donation key model is not permitted under Apple's developer agreement, since software asking for voluntary contributions does not get approved. The project therefore sells a fixed price build in the store with no donation prompt. It is the same application at the same version as the free download.
Does Cyberduck work on an older Mac?
Current builds require macOS 10.13 or later on 64 bit Intel or Apple silicon, which is a low floor by 2026 standards. For systems older than that, the changelog documents which earlier release is the last one supported and keeps those installers available.
Why do large downloads seem to stall at the end?
That is most likely the merge step of a segmented download. Files over 100MB are split and fetched over several connections, then reassembled, and the documentation notes the merge can take a considerable amount of time. If segments are missing, the parts are left in a folder and the transfer has to be resumed or repeated.