Glossary

Files, downloads and transfer

Most of what feels arbitrary about files on an iPhone follows from one rule about isolation, and most of what makes downloads reliable follows from one feature of HTTP. These are both, plus the ways files get from one device to another.

Sandbox

The rule that each app can only see its own storage. It is why one app cannot open another's downloads, and why "the file is next to the video" is not a thing that exists on iOS.

Every app gets a private directory and no view of anyone else's. Files move between apps only through deliberate acts — a share sheet, a document picker, a drag — each of which is a decision the person made rather than an app helped itself to.

The cost lands in small places. Desktop players find film.srt beside film.mkv automatically; on iOS there is no "beside", so a subtitle file has to be handed over on purpose and the app has to be the thing that remembers the pairing.

See also: App groupSecurity-scoped bookmark

App group

A shared container two apps from the same developer may both open — the only sanctioned crack in the sandbox. It is how a share extension hands a file to the app it belongs to.

A share extension is a separate program from the app it appears to be part of, with its own sandbox and a very short life. It cannot write into the main app's storage.

So it writes into a container both are permitted to see, and the app drains that container next time it opens. Nothing crosses a developer boundary, and nothing crosses without an explicit tap.

See also: Sandbox

Security-scoped bookmark

A token that remembers permission to a folder outside the sandbox — an external drive, a folder in iCloud — so the app can reopen it later without asking again.

When you pick a location through the system file picker, the permission granted is for that moment. A bookmark preserves it across launches, and the app must explicitly start and stop using the access it represents.

It is what makes browsing an external SSD possible without copying anything in, and it is scoped to exactly what you chose — a bookmark to one folder grants nothing about its neighbour.

See also: Sandbox

Range request

Asking a server for a specific slice of a file — bytes 5,000,000 to 5,999,999 — instead of the whole thing. It is what makes a download resumable and what lets several connections fetch one file at once.

A server that supports ranges answers with 206 Partial Content and the slice asked for. One that does not answers 200 and sends everything from the beginning, which is the difference between resuming a download and restarting it.

Everything interesting about a download engine rests on this one HTTP feature. Without it there is no resume after a dropped connection, no resume after a reboot, and no way to use more than one connection.

See also: Resumable downloadParallel connections

Resumable download

A transfer that continues from exactly where it stopped rather than starting again, by recording how many bytes are committed and asking for the rest.

The requirement is that the number recorded is never optimistic. A byte counted as written but still sitting in a buffer becomes a hole in the file when the app is killed — and a hole in the middle of a video is a corruption that only shows up an hour into watching it.

Which is why the count has to follow the write to disk rather than the read from the network, and why every handover between foreground and background transfer has to agree on one number.

See also: Range requestBackground transfer

Parallel connections

multi-connection, chunked download

Splitting one file into ranges and fetching several at once. It helps when a single connection is being limited, and does nothing at all when the bottleneck is your own line.

A server that caps each connection's speed can often be persuaded to deliver more in total across several. This is where multi-connection downloading earns its reputation.

It is not magic and it is frequently misunderstood. If your connection is already saturated, more connections divide the same capacity into smaller pieces and add overhead. Some servers also refuse or throttle multiple requests from one address.

See also: Range requestResumable download

Background transfer

A download handed to the operating system so it continues after the app is closed. The system decides the timing, which is the trade for it continuing at all.

An iOS app stops running shortly after you leave it. A transfer given to the system's background service survives that, and survives the app being killed, and resumes after a reboot.

What it gives up is control. The system batches these transfers according to its own view of power and network conditions, so a background download may pause and resume in ways an in-app one would not — and it will finish.

See also: Resumable downloadSandbox

WebDAV

An extension to HTTP that turns a web server into a file server: list, read, write, move, delete. It is what Nextcloud and ownCloud speak, and what most NAS boxes offer.

Because it is HTTP underneath, WebDAV works through the same infrastructure as anything else on the web — no special ports, no special client protocol — which is why it survived while more elaborate file protocols did not.

For someone who would rather not put files in a company's cloud, it is the practical alternative: your own server, your own credentials, ordinary standards.

See also: Cloud storage

Cloud storage

Files kept on someone else's server, reached through that company's API — Dropbox, OneDrive, Box, pCloud. Each has its own interface, which is why apps support them one at a time.

There is no universal cloud protocol. Every provider designed its own API and its own sign-in flow, so adding a provider to an app is real work rather than a configuration entry.

Sign-in is normally OAuth, which means the app never sees the password: the provider authenticates the person and hands back a token that can be revoked from the provider's own settings at any time.

See also: WebDAV

WebRTC

A standard for connecting two devices directly, without a server between them once the connection exists. It is what device-to-device transfer uses to move a file across the room.

A small signalling server introduces the two devices to each other — this is what the six-digit code is for — and then withdraws. The file travels directly between the devices and is not stored anywhere in between.

On the same network it is as fast as that network allows. Across the internet it depends on whether both sides can be reached directly, which is where connections occasionally fail for reasons neither device can see.

See also: Local HTTP server

Local HTTP server

An app answering web requests on your own network, so a web browser on your computer can open a page served by your phone. It is how Wi-Fi Transfer works, with no cable and no account.

The phone shows an address; the computer opens it; the page it gets is served by the phone itself. Files move directly over the local network and never leave it.

Since anyone on the same network can reach that address, it needs a lock — a code to enter, permissions granted per operation, and destructive ones off unless deliberately turned on.

See also: WebRTC

The other subjects