Syncthing on a phone
Syncthing runs on Android as a full peer, and on iOS it does not. That single asymmetry explains almost everything about continuous sync on a phone. The Android app carries the same sync engine as the desktop program, so a phone is an ordinary device in your set of devices: it holds folders, it serves blocks to your laptop, and it appears in the device list like any other. On iOS there is no app from the Syncthing project at all, and what exists comes from unaffiliated developers working inside limits Apple sets for every app on the platform.
What the Android app actually is
The Android app is the same engine in an Android wrapper, not a reduced client. It runs the sync process as a foreground service, which is why it keeps a permanent notification in the shade: Android requires that notification as the price of a process that goes on working when the app is not on screen. The user interface is a thin layer over the same web interface the desktop version exposes on port 8384, and the settings that matter are the Android ones stacked on top: when to run, over which networks, and which folders on storage it is allowed to touch.
Device identity works exactly as it does everywhere else. The phone generates its own device ID on first run, you add it to a laptop or a home server by pasting that ID, both sides confirm, and the connection is TLS with both ends authenticated. Sync traffic leaves the phone on port 22000 and local discovery announces on UDP port 21027, exactly as it does on a desktop. Nothing about the phone changes the trust model, so a phone that has been added to a folder can write to that folder, and the Syncthing page on this site covers the shared mechanics of device IDs, discovery and relays in full.
Why a fork exists, and whether the fork is safe
The fork exists because the app published under the project's own name and a community maintained fork have diverged in scope and in how consistently each has been maintained. The fork is an independent build of the same upstream engine, packaged by a different maintainer, and it carries a larger set of Android specific controls than the plainer app does: conditions for when syncing should run at all, finer control of the notification, and more options around power and network state.
Yes, a reputable fork of an open source program is safe in the sense that matters here: the engine is the same audited code, the source of the fork is public, and the network behavior is unchanged. Safety on Android is a question of provenance rather than of the word fork. Install from a store or repository that builds and signs reproducibly, check that the listing is the maintainer's own, and prefer whichever build the project's own documentation currently points to, because which Android build is actively maintained has changed over time and is the one detail worth confirming rather than assuming.
What iOS does differently, and why there is no equivalent
iOS does not permit the thing Syncthing needs, which is a process that stays alive indefinitely watching a folder. An iPhone suspends an app shortly after it leaves the foreground, and the background modes an app may declare are a fixed list built for specific jobs such as audio playback, navigation and short scheduled refresh tasks. Continuous file synchronization is not on that list, so an iOS build could sync while you are looking at it and then stop, which is a different product from the one people mean when they say Syncthing.
Storage is the second obstacle. An iOS app writes inside its own container, and reaching anything else means going through the Files app and the document provider system rather than owning a directory the way an Android app can. Peer to peer software has always been shaped by what the host platform permits, from the desktop application Napster required in 1999 to a phone that suspends its apps by policy. Third party iOS apps that speak the Syncthing protocol do exist, built by developers unconnected to the project, and they work within both of those limits rather than around them. Treat them as separate products with their own behavior, not as the same program on a different phone.
Android and iOS side by side
Android and iOS differ on five points that decide what continuous sync can do on each.
| Behavior | Android | iOS |
|---|---|---|
| App from the project | Yes, alongside a community fork, and which one is current has changed over time | None |
| Runs while the screen is off | Yes, as a foreground service | Not continuously |
| Folder anywhere on storage | Within scoped storage rules | Only through the Files system |
| Acts as a full peer for other devices | Yes | Only while active |
| Conditions on network and charging | Yes, and extensively in the fork | Limited |
What a phone does to continuous sync
A phone changes sync from a background certainty into something the operating system schedules around you, and four platform behaviors account for most of what you will see.
- Doze and app standby hold back network access and deferred work when a device sits unused, so a phone in a drawer overnight syncs in bursts when it wakes rather than continuously.
- Background execution limits mean a foreground service and its notification are the only reliable way to keep running, and killing that notification stops the sync.
- Scoped storage restricts which directories an app may read and write, so folder choices on a modern Android device are narrower than on a desktop and shared storage often needs an explicit grant.
- Metered connections matter because sync is symmetric: the phone uploads as much as it downloads, which is why running only on unmetered wifi, and only while charging, is the usual configuration.
The result is that a phone spends much of its time in the waiting state rather than moving, and that is normal rather than a fault. A folder that shows as up to date minutes after a change on the laptop is behaving as designed, and the same platform pressures apply to a torrent client on the same handset, which is why running BitTorrent on a phone is its own topic and covered separately under clients on a phone. The Glossary defines the state words, and the alternative worth knowing is that an always on machine at home removes the problem entirely: the phone syncs to it when it can, and the machine holds the folder the rest of the time.