The Speed Drop You Probably Blamed on Your Wi-Fi
You queue up a large file, lock your phone, and walk away. Ten minutes later you come back expecting it to be done. It's at 34%. You stare at it, then you blame the router, then you restart the app and watch the little progress bar like that'll help.
None of that is the problem.
Your phone throttled itself on purpose. This isn't a bug or a carrier conspiracy. It's a deliberate, layered power-management system that both Android and iOS have built deeper into their operating systems over successive versions, and the screen going dark is the trigger.
What the Phone Is Actually Doing When You Lock It
The display is the single hungriest component in your phone, but the cellular or Wi-Fi radio is a close second. When you lock the screen, the OS reads that as a signal: the user is done actively using this device. Time to start conserving.
On Android, this kicks off a chain of states. The CPU steps down to a lower clock speed. Then, after roughly a minute, the system begins batching network requests rather than serving them continuously. After several more minutes of inactivity, many devices enter what Android calls Doze mode, where the network interface is essentially parked. Apps that haven't declared themselves high-priority receive network access only during brief, infrequent maintenance windows, sometimes as rarely as once every hour in deep Doze.
iOS does something architecturally similar through its Background App Refresh system and a concept called discretionary networking. If a download is happening through a standard URLSession without the explicit background-transfer configuration, iOS will deprioritize or suspend it once the screen locks and the app moves out of the foreground. The radio doesn't go fully silent. It gets stingy.
Think of it less like a switch and more like a thermostat that keeps nudging the temperature down every few minutes. Each step happens on a timer, and the phone descends faster if the battery is low.
The Staircase in Practice
Picture two people downloading the same 4 GB game file before bed. Maya plugs her phone in, starts the download through her console's companion app, and locks the screen. Priya does the same, but her phone is at 31% battery and she's on cellular.
Maya's phone, connected to power, applies lighter throttling. The charger signals to the OS that conservation is less urgent, so network access stays relatively generous through the night. She wakes up to a completed download.
Priya's phone descends that staircase fast. The OS applies aggressive Doze-equivalent behavior within a few minutes, the app hasn't been granted background-transfer privileges, and so it barely touches the network until she picks the phone up at 2 a.m. to check the time. That screen-on moment briefly wakes the system, the download surges, then slows again when she locks it. She wakes up to 61% downloaded.
Same file. Same app. Same night. Completely different outcome because of battery level, connection type, and how the app was built.
What Developers Can Do (and Often Don't)
This is where the story gets a little unfair to users, because the fix exists and a surprising number of apps just don't bother.
Both platforms offer a dedicated background transfer API. On iOS it's URLSessionDownloadTask with a background configuration. On Android, WorkManager and DownloadManager are the sanctioned tools. These APIs register the download with the operating system itself, not just the app. The OS then manages the transfer directly, keeping it alive through screen-off states, across app restarts, and even across reboots.
When an app uses these tools correctly, your download survives the staircase.
The problem is that implementing background transfer properly takes real engineering effort: handling a dropped Wi-Fi connection mid-download, a storage-full scenario, a force-close from the user. A lot of apps, especially smaller ones, skip it entirely and run the download inside a foreground service or a plain network call. That works fine while you're watching. The moment the screen goes dark, you're at the mercy of the OS.
You can often spot the difference by watching the speed graph immediately after locking the screen. A sharp cliff means the app isn't using background transfer. A gradual taper, or no change at all, means it probably is. Honestly, most apps fail this test, and that's a real engineering failure, not an acceptable trade-off.
What People Misread About This
The most common assumption is that this only matters on cellular. It doesn't. Wi-Fi radios are also subject to power management, and on many Android devices the Wi-Fi chip will drop to a lower-power scanning mode after the screen has been off long enough, reducing throughput even on a strong home network. The effect is usually less dramatic than cellular throttling, but it's real. Have you ever noticed a download stall on Wi-Fi and then immediately pick up the moment you touched the phone? That's exactly what happened.
The other thing people get tangled up in: cycling airplane mode does nothing useful here. You're not stuck in a bad state that needs resetting. The system is working as designed.
The levers you actually have are keeping the screen on (impractical), plugging in (genuinely useful), forcing the app to the foreground and leaving it there (annoying but effective), or switching to an app that implements background transfer properly. For large downloads, the charger is the single most reliable fix. Plugged-in devices get meaningfully more permissive network treatment on both platforms because the OS no longer has to defend the battery. Blunt instrument. Works every time.
Your phone is running a continuous negotiation between what you're asking it to do and what it thinks it needs to preserve. Background downloads sit low in that negotiation. Your next alarm, your phone call, your notifications: those sit higher. The throttling isn't your phone being slow. It's your phone making a judgment call about what matters while you sleep, and the frustrating part is that it's usually right.