There is a particular kind of bug report that arrives only after launch: the app "doesn't work", with no error, no crash log, and a user who has already given up. Nine times out of ten the app is working exactly as written. It was simply written for conditions that do not exist outside the office.
The four assumptions that break
Almost every failure of this kind traces back to one of four assumptions baked in during development, all of which hold on a developer's machine and none of which hold reliably in the field.
1. That a request either succeeds or fails
On a good connection this is nearly true. On a mobile network it is not. A request can be sent, received, processed, and the response lost on the way back. The server recorded a purchase; the app believes nothing happened. If the user taps again, and your endpoint is not idempotent, they have now paid twice.
The fix is not a longer timeout. It is a client-generated request key sent with every action, which the server uses to recognise a repeat and return the original result instead of doing the work twice. It costs an afternoon to build and eliminates an entire category of angry support ticket.
2. That the connection stays up for the whole task
Checkout flows, form wizards and uploads are frequently written as though the user will remain connected from the first tap to the last. Design instead for interruption: save progress locally as they go, queue the action when the network drops, and finish it when the network returns. The user should be able to close the app mid-task and find their work waiting.
3. That data is free
A 12 MB image on a home screen is invisible on Wi-Fi and expensive on a metered plan. Users notice when an app eats their bundle, and uninstalling is the obvious remedy. Compress aggressively, size images for the device that will show them, cache what will not change, and do not re-download the same assets on every launch.
4. That the phone is fast
The device most of your users hold is several years old with limited memory. Heavy animation, large dependency trees and doing work on the main thread all show up as jank or an outright freeze on that hardware, and not at all on the flagship in your pocket. Test on a cheap phone. Buy one specifically for this if you have to; it is the highest-value hardware purchase a mobile team can make.
The uncomfortable part
None of this is difficult engineering. It is all well understood and none of it takes long. The reason it is skipped is that the failure modes are invisible during development — everything works on the machine where the code is written, so nothing signals a problem until the app is in front of real users on real networks.
Which is the argument for treating bad conditions as the default case rather than an edge case. Build for the interrupted connection and the mid-range phone first, and fast networks take care of themselves.