Downloading

What a download manager does that a web browser will not

A four-gigabyte file, ninety per cent done, and then a phone call — or just a locked screen — and it is gone. This is the most common complaint about downloading on iOS, and it is not a bug. It is the operating system doing exactly what it was designed to do, and the reason a separate class of app exists.

8 min read Updated 29 July 2026

30s Roughly how long a suspended app keeps running before iOS stops it
206 The HTTP status that makes resuming possible at all
1 byte How much of a properly resumed transfer is re-downloaded

Why the transfer stops when you switch apps

iOS does not let an app keep working simply because it would like to. When you leave an app, it is suspended within seconds, and a suspended app has no CPU time, no network sockets and no way to notice that it has been stopped. Everything it was holding in memory is still there, but frozen — and if the system needs the memory, the app is terminated outright without being told.

A download running on an ordinary connection inside the app therefore ends at the home gesture. Some apps hide this by asking for a few extra seconds of background time, which is why a download sometimes survives being backgrounded for exactly as long as it takes you to notice it did not.

The proper answer is different in kind. iOS provides a background transfer service: you hand the system a list of URLs and destinations, and the system does the downloading itself, in its own process, on its own schedule. Your app can be suspended, terminated, or not running at all — the transfer continues, and the app is relaunched in the background when there is something to report. This is the mechanism behind every download that survives a locked screen, and using it is a design decision an app makes up front, not a setting you can turn on.

The four mechanics that decide whether a download survives

Range request: An HTTP request that asks for bytes 5,000,000 onwards instead of the whole file. If the server answers 206 Partial Content, resuming from the middle is possible; if it answers 200 OK and starts from the beginning, it is not — the file has to be fetched again from zero.
Parallel connections: Splitting one file into several ranges and fetching them at the same time. It helps because a single connection is often throttled by the server or limited by round-trip latency, not because your internet is faster with more sockets open.
Committed offset: How much of the file is safely written to disk, as opposed to still in flight. A download that resumes from the last committed byte is correct; one that resumes from what it *thinks* it received produces a corrupt file that only reveals itself hours later.
Background session: The system-run transfer described above. It is slower to start, cannot be given arbitrary custom logic, and it is the only thing that keeps running when the app is not.

Why a download fails, and what each failure looks like

Most “stuck download” reports are one of these five, and they are easy to tell apart once you know the shape.

What you see	What is actually happening	What helps
Stops the moment you leave the app	The transfer was running in-process, not in a background session.	Nothing you can do from outside — this is an app design issue.
Restarts from 0% every time	The server ignores range requests, so there is no way to continue from the middle.	A stable connection, or a smaller file. Some hosts allow ranges only for signed links.
Fails after a few minutes, repeatedly	The link has expired. Many hosts issue URLs valid for five or ten minutes.	Fetch the link again from its page and start over; the old one will never work.
Downloads fast, then the file will not open	What arrived was an HTML error page or a login page with a video file name.	Check the size — a 14 KB “film” is a web page. Inspect the link before committing to it.
Very slow despite a fast connection	Per-connection throttling at the server end.	More parallel connections, if the server permits them. If it caps by IP address rather than by socket, nothing will help.

When there is no file to download at all

A large part of the video on the web is not delivered as a file. It is delivered as HLS — an .m3u8 playlist that lists hundreds of small segments, a few seconds each, often at several quality levels so the player can switch as your connection changes. There is no single URL holding the film, because the film only exists as a sequence.

Saving one means fetching every segment and then remuxing them: writing the video and audio streams into a normal MP4 container. Nothing is re-encoded, so nothing is lost and it takes seconds rather than the length of the film. The result is an ordinary file that plays anywhere.

This is also why “download this stream” takes noticeably longer to start than downloading a file: the playlist has to be fetched and parsed, a quality level chosen, and only then can the segments begin arriving. And it is why some streams cannot be saved at all — if the segments are encrypted under a DRM scheme, the keys are deliberately not obtainable, and no tool that respects the law will get past that.

What separates a real download manager from a download button

It survives the app closing

Background transfers handed to the system, with a handover that continues from the same committed byte rather than starting the file again.

It tells you what a link is before you commit

Size, type and whether the server supports resuming — all knowable from a single HEAD request, and all useful before you spend four gigabytes of a data plan.

It queues rather than floods

Ten files at once is slower than three at a time, because each connection gets a smaller share and the failures multiply. A queue with a sensible concurrency limit finishes sooner.

What lands is a normal file

In a folder you can see, named sensibly, playable by anything — not a database blob that only that app can open.

Habits that prevent most download problems

Start big files on Wi-Fi and leave the screen on for the first few seconds
Handover to the background session happens early; after that the screen no longer matters.
Do not queue twenty items at once
Three to five concurrent transfers is the sweet spot on almost every connection.
Check free space before, not after
A transfer that fills the disk fails at 98%, and iOS may have already purged your caches trying to make room.
Treat an instant “completed” with suspicion
A film that finished in two seconds is an error page. Look at the file size.
Re-fetch expired links from their page
Retrying a dead signed URL will fail forever, no matter how many times the app retries it.

How this differs across devices

iPhone

The strictest environment: suspension is aggressive and storage is tight. Background sessions are not an optimisation here, they are the only thing that works.

iPad

The same rules, with more room to run — and the one iOS device where a big library can reasonably land on an external drive instead of internal storage.

Mac

No suspension at all, so long transfers behave the way they do on any desktop. The practical limit is the server, not the operating system.

Questions this raises

Do more connections always mean a faster download?

No. They help when a server limits the speed of each individual connection, which is common. They do nothing when the limit is your own connection, and they can make things worse when a host counts sockets per IP address and starts refusing them. Somewhere between four and eight is the useful range; thirty is counterproductive.

Can a download continue while the screen is locked?

Yes, if it was handed to the system’s background transfer service. The lock screen is irrelevant to that service — it is the app being suspended that matters, and the whole point of the mechanism is that it keeps going regardless.

Why does my download restart instead of resuming?

The server did not honour the range request. You can tell because the progress goes back to zero rather than picking up. Some hosts support ranges only on their signed download URLs, some disable them entirely, and a few honour them for small files but not large ones.

Is converting a stream to MP4 the same as re-encoding it?

No. Remuxing moves the existing video and audio into an MP4 container untouched — lossless, and fast enough to finish in seconds. Re-encoding rebuilds the picture with a different codec and always loses quality. If saving a two-hour stream takes two hours, something is re-encoding when it did not need to.

FoxDL

How FoxDL downloads

The engine has two lanes: an in-process one that is fast while the app is on screen, and the system background session that takes over from the same byte when it is not.

Parallel chunks for a single file, written straight into their final position on disk rather than into temporary parts that have to be joined afterwards.
Background transfers that continue after the app leaves the screen, and pick up at the last committed offset — not at the last byte the app thought it had.
Resume after a drop, a reboot or a force-quit, provided the server honours range requests. When it does not, FoxDL says so rather than looping.
HLS streams remuxed to MP4, so what lands in the library is an ordinary file, not a folder of segments.
A download inspector that reports the real size, type and resume support of a link before you start.
Everything lands in a normal folder that the Files app can see.

Free allowances differ by platform: on iPhone and iPad a small number of passes topped up by a short rewarded video you start yourself; on Mac, where there is no advertising at all, a fixed daily count. Pro removes the limit on every device.

Questions people ask about this

All questions

Your library, finally in one place.

Free to download. No account, no sign-up, and the whole feature set is in the free version.

Download on the App Store