The bytes are ordinary files. The constraints are the device: radios that change, operating systems that suspend background work, and storage permissions that hide the camera roll from a browser. RFC 9110 still defines the GET or POST. The phone decides whether that request is allowed to finish.
Background policy is the usual break. A browser upload that runs while the user watches can complete. The same upload backgrounded while they lock the screen is frozen or killed. A native app with a background-transfer entitlement can continue. A web page cannot promise that. Cellular plans also cap or charge for the large direction. A 3 GB upload on LTE is a different product decision from a 3 GB upload on Wi-Fi, even when the protocol is identical.
A field tech records an 1.4 GB inspection video and uploads it from the phone browser on a site with one bar. At 400 MB they lock the phone. The tab dies. A resumable client, reopened on the truck's Wi-Fi, reads the offset and finishes. A non-resumable form starts over and hits the carrier's fair-use slowdown. Downloads have the mirror problem: a mail link opens a preview that will not save the full file into Files, and the desktop user later cannot find it. The transfer "worked" inside an app sandbox and never became a file the recipient can forward.
Mobile is not a protocol family. iPhone and Android differ in the share sheet and the background rules. They do not differ in checksums. Prefer Wi-Fi for large objects, resume after suspension, and state the size before the cellular radio starts.
Related
Sources
- RFC 9110, HTTP Semantics
Mobile uploads are still HTTP; the OS may suspend them
- tus resumable upload protocol 1.0.x
Offset resume after a radio drop or a suspended app