Clients on a phone

What exists on Android, and what exists on iOS

What exists on Android is a small field of complete clients, most free and some of them free software, distributed through Google Play and through F-Droid, a repository that builds applications from their published source. They show the same transfer list a desktop client shows, with the same states of moving, complete, waiting and errored and the same magnet link handling, so How a transfer works applies here without amendment. Some are supported by advertising, which is worth checking before installing rather than after.

What exists on iOS is a different category. The App Store carries remote controls, which drive a client running on some other machine over its web interface or its API, and download managers, which fetch files over HTTP and never speak to a peer. Neither is a torrent client. Sideloading with a personal developer certificate is possible and that certificate expires on a short cycle; routes depending on jailbreaking sit outside what the platform supports. Of the two phone platforms, only Android has torrent clients of its own.

The qBittorrent project publishes no Android client, so an application carrying that name on a store or offered as an APK is either a remote control for a qBittorrent instance running elsewhere or is unrelated to the project. That distinction matters more than on a desktop, because the name is the only thing most people check.

What a phone does to a transfer

A phone does four things to a transfer that a desktop never does. It suspends the application: Android's Doze and App Standby cut background network access once the screen has been off for a while, so a client keeps a foreground service with a permanent notification to stay alive, and even then the battery optimization settings may need to exempt it. It restricts storage: since Android 10 an application writes to its own directory or to a folder the user picked through the system picker, so a save path on a memory card is not simply typed in.

It manages the radio and the meter: a client set to transfer only on Wi-Fi stops the moment the phone falls back to mobile data, and a client not set that way spends the data allowance instead. And it manages heat and charge, since sustained upload keeps the radio and the storage busy and the system throttles what is running to protect the battery, so a transfer that looked healthy on a desk slows once the phone is in a pocket. On iOS the equivalent limit is stricter: background execution is granted in short windows, so even a hypothetical client would be suspended long before a large transfer finished.

Where a phone build comes from

A phone build comes from a store, and the store supplies the publisher identity a desktop reader would get from a signature. Google Play and F-Droid are the two Android channels with a publisher behind them, and F-Droid builds from the published source, so what is installed corresponds to code somebody can read. On iOS the App Store is the only supported channel, which is why the category is absent.

An APK obtained from anywhere else carries no chain back to a project. Android asks permission before installing from an unfamiliar source, and the signing key rather than the file name identifies the publisher, so two files with the same name and different keys are different applications. Since a desktop project that publishes no Android client can have no official Android build, the safest reading of any APK named after a well known desktop client is that it is not from that project.

What goes wrong first on a phone

• The screen goes off, battery optimization suspends the client, and the transfer shows stalled on the next unlock.
• The save folder was never granted, and the client errors as soon as the first piece is verified and ready to write.
• The phone is on a mobile network, where carrier grade NAT means no peer can start a connection to it, so the client is permanently firewalled and can only connect outward.
• The device fills up, since a phone has a fraction of a desktop's storage and a large transfer reserves space before it has any data.
• The data allowance is spent by seeding, which continues quietly after the download finishes unless a limit or a Wi-Fi only rule is set.

What a phone cannot do

A phone cannot be a dependable member of a swarm. It cannot accept incoming connections on a mobile network, so it contributes only through connections it starts, which is half of what The swarm counts on. It cannot stay connected for hours with the screen off unless it has been exempted from power management. And it cannot hold a large transfer, or seed one for long without spending battery and metered data that a desktop spends neither of.

iOS additionally cannot run a client at all, because the constraint sits at distribution rather than at capability. The device is perfectly capable of the arithmetic; the application class is simply not in the store.

iPhone and iPad, asked directly

No, there is no torrent client for iOS in the sense the question means, and the same answer covers the iPad. What people do instead is move the client off the phone: run it on a machine that stays on, then drive it from the phone with a remote control application that talks to the client's web interface or its API. The transfer happens on the other machine, and the battery, the storage and the mobile network stop being constraints.

Android users converge on the same arrangement once a transfer gets large, which is a better answer than any comparison between the platforms. A reader whose real goal is having their own files on their phone wants a different technology: Syncthing on a phone keeps folders on devices you own in step with each other, with no swarm, no ratio and no peers you did not choose.