What happens when your network changes?

A 221 MB video, from Uganda to Utah

A workmate in Uganda sent a video to Samson’s Android phone in Utah. The receiver moved between mobile data and office Wi-Fi, then briefly had neither connection available.

Recorded network-change test · 5 min 29 sec · Published October 29, 2026

Open the test on YouTube ↗ · Read Samson’s account of the test ↗

The published recording removes long waits and a store-search detour. The retained footage runs at its original speed. This is one observed Android transfer, not a guarantee for every device or network.

What recovery depends on

Iroh attempts to find a usable connection between the devices. It can use a direct path when available or an encrypted relay when a direct path cannot be established. A relay still needs a working network connection.

Recovery depends on your app version. In the current macOS and Windows development builds, interrupted receives wait for a usable connection and retry network failures and timeouts with increasing delays. They are not limited to three attempts. Core retains recoverable receives for up to seven days from creation; that is a recovery window, not a delivery guarantee. Cancelling, expired recovery data, a missing sender, or a save or storage error can still prevent completion.

In those desktop builds, Pause keeps the recovery data. After reopening SEYFR, an interrupted receive needs an explicit Resume and a usable save destination; it does not silently resume or save. macOS may ask you to choose the folder again if permission has expired. If the app asks you to check the save folder, do that before confirming another save, because files may already have been written. Cancelling or discarding a receive is different from pausing it.

Older releases and other platforms may use a different receive flow. The Android recording above demonstrates one active transfer recovering; it does not demonstrate desktop restart recovery. The source review here is not a new physical-device network test.

If your transfer stops

1. Check both devices. Make sure the sender and receiver are connected to a usable local network or, for remote transfers, the internet.
2. Keep SEYFR running. Keep the devices awake and return to the transfer screen. A sleeping or closed app cannot continue moving bytes. Mobile operating systems can also restrict background connections.
3. Check the status. Allow an active transfer to recover after restoring connectivity. If a recoverable desktop receive is paused or restored after restart, use Resume on that job rather than starting a new receive. Follow any save-folder or permission prompts. If the transfer has failed permanently or the sender ended the share, ask the sender to share again.
4. Confirm the save. Wait for successful receipt and open the received file. A preview or partial progress bar is not a completed transfer.

Your sender’s original files remain on their device. Keep them until you have checked the received copies.

Choose your network—and mind your data plan

A shared local Wi-Fi network or hotspot can carry a nearby transfer without internet, when the devices can reach each other. Separate networks require internet access on both sides.

Switching to mobile data can use your carrier allowance. SEYFR is free, but your mobile data may not be. If you want to avoid using mobile data, choose Wi-Fi in your device’s network settings before transferring.

Try it with your devices

Start with a small file, then check the received copy. If a transfer fails, tell us the sending and receiving platforms, which network changed, and what SEYFR displayed. Do not share private filenames or transfer codes.