Clients on macOS

The three clients that run natively on macOS

The clients that run natively on macOS differ mainly in the toolkit they were written against, which explains most of how they feel. Transmission began on Mac OS X and still ships an interface written against Apple's own frameworks, so it behaves like a Mac program rather than a port. qBittorrent is written in Qt and presents the same window on macOS, Windows and Linux; it runs on libtorrent, the engine described on the qBittorrent page. Deluge is written against GTK, a toolkit that is not native here, so its Mac build is the one that looks least like the rest of the system.

All three are free and open source, none carries advertising, and none has a paid tier. The question that fills forum threads is which one to run, and the honest answer is a property of what you need rather than a ranking. What none of them changes is the transfer itself, which proceeds as How a transfer works describes.

What macOS does to a transfer that is already running

macOS acts on a running transfer in four places, all of them outside the client. The first is folder access: since macOS Catalina a program must be granted access to the Desktop, Documents, Downloads and any removable volume before it can write there, and the first attempt raises a system prompt. Deny it and the transfer stops with an error rather than a stall, because the write itself was refused.

The second is sleep. A Mac laptop with the lid closed sleeps, and a sleeping Mac transfers nothing: the client is still loaded, the swarm is not. The third is App Nap, which throttles applications the system judges idle in the background, so a minimized client slows down without any setting having changed. The fourth is the file system. APFS on a Mac is case preserving but case insensitive by default, so a torrent containing two files whose names differ only in capitalization cannot be written out whole; the same torrent completes without complaint on a case sensitive Linux volume.

Where a Mac build actually comes from

A Mac build comes from the project that writes the client, and on this platform that matters more than on any other desktop, because almost none of the general purpose clients are distributed through the Mac App Store. Apple's review rules leave the category effectively empty there, so the file arrives as a disk image holding an application bundle, and the reader drags it into the Applications folder themselves.

That route runs into Gatekeeper. Every file arriving through a browser is tagged with a quarantine attribute, and macOS refuses to launch an application whose developer it cannot verify. A signed and notarized build opens without argument; an unsigned one has to be approved by hand, and in current releases that approval sits in System Settings under Privacy and Security, though the wording moves between releases. Package managers such as Homebrew publish casks for these clients, but a cask is a recipe that fetches the project's own file rather than a separate build, so the trust still points back at the project. Macs with Apple silicon and Macs with Intel processors also need different code, so projects ship either a universal build carrying both or two files with the architecture in the name.

What goes wrong first on a Mac

• Gatekeeper refuses the first launch, so the client never starts and nothing about the transfer is at fault.
• Folder access is denied, and the client shows an errored transfer as soon as a verified piece cannot be written.
• The lid closes, the Mac sleeps, and every transfer shows stalled when the machine wakes, until peers are found again.
• Two file names in one torrent differ only by case, and the write fails on a volume that treats them as one name.
• The router forwards nothing, so the client shows firewalled: outgoing connections only, which is a network condition rather than a Mac one, as Is it safe? and The swarm both explain.

What macOS will not do

macOS will not keep a transfer moving while the machine is asleep, and no setting inside a client overrides that, though the system's own energy settings can be told to stay awake while the display is off. It will not silently run an unsigned build. It will not hand you a client from the Mac App Store. Its application firewall, when switched on, blocks incoming connections per application and can be set to block all of them, which leaves a client permanently firewalled while its downloads still work. And macOS cannot make a router forward a port: the system firewall and the router are two separate gates, and both have to be open before another peer can start a connection to you.

Opening a torrent file on a Mac, and where the client puts it

To open a torrent file on a Mac, double click it once a client is installed, because the first client installed usually claims the file type. When nothing happens, select the file in Finder, open Get Info, choose the client under Open With and press Change All, which sets the handler for every torrent file rather than that one. A magnet link is different: it is a URI scheme rather than a file, so the browser asks whether to hand it to the client.

The copy the client keeps is what people really mean when they ask where the torrent file went. Adding a transfer copies the metadata into the client's own working folder, inside the per user Library folder that Finder hides; hold the Option key while opening the Go menu to reveal it. That folder holds the torrent copies, the resume data recording which pieces are verified, and the settings. The downloaded data is elsewhere, in whatever save path was set when the transfer was added, so deleting the torrent file you double clicked changes nothing.