Dear Mobile App Developers
Obviously Apple and Google have done a good job building out the IP stack for mobile devices (I still can't believe Steve Jobs tricked AT&T into allowing them access to the data pipe back in the day), but, I thought things would have evolved further than they have. Stable IP connections are fleeting in today's volatile network environment, yet developers and product managers have yet to fully embrace this reality. Apple, Google, and the cell network carriers (all of them) want us developers to believe that the IP layer is there and that it can be counted on, but, unless a device is connected, and stationary (not actually "mobile"), to a strong WiFi connection (perhaps at home, or at work), the chaos that is the networking layer has dramatic end-user app experience impact, and it isn't great. Here are some tips to help you build software that is good.
There are two top-level considerations when defining how your app should behave, and how a developer should build it: one, how does my app behave when the IP layer is flaky, and two, do I want my app to support offline use?
Flaky Networks
Mobile users bounce in and out of countless network connections during the day. If they commute to work, their phone grabs/lets-go-of countless shoddy cell tower connections, and random public WiFi connections that are trying to be helpful. As this is happening, if your app is trying to do something over the network (here's looking at you Spotify, Apple Music, Apple/Google Maps, Waze, on and on and on) it is going to struggle. If you don't appropriately separate your app/UI layer from its underlying data/network connection layer, your users are going to be bombarded with latent, broken, UI experiences. "Loading...", blank screens, "pull down to refresh", etc are all avoidable experiences if you invest the time and energy to ensure appropriate caching, and UI elements/backgrounds, are at the forefront of your experience, and the data layer, is in the background.
Building UI that is tightly bound to network connections is a fast way to a poor user experience. Instead of assuming your app has a network connection, envision it without one. How would it behave from cold-start, to shutdown? Envision that experience, make it amazing, and then layer in the I/O.
Offline Mobile
I applaud any company/PM who wants to handle true offline use cases, as it's usually a sign that they're enlightened to the fact that the network is busted and is going to be for our lifetimes. That said, if you're going to do it, do it right. Audible & Spotify are two noteworthy apps that have attempted this, but, both have serious issues. The former's offline experience for Apple Watch flat-out doesn't work, and the latter's Offline Downloads to Apple Watch are intermittent at best. It's easy to blame Apple in this case, but, you can still provide a cleaner UI to the end user to help them understand the sync process, which always a challenge.
In general, a nice and clean abstraction of front-end/UI from back-end/data allows for solid offline implementations. It's 10x easier to build this in initially than it is to retro-fit it into an app after-the-fact, so, if you're considering prioritizing offline down the road, I'd architect this in from the start.
Greedy Buffering
If your app can anticipate data needs, grab the data early, often, and in big chunks (bandwidth permitting). Mobile mapping apps and music/movie/tv streaming apps are good examples of this. Detect whether or not the network connection is flakey/changing, and if so, read-ahead and cache while you can. Make hay while the sun is shining, don't wait for your user to get stranded on an airplane (no... airplane WiFi does NOT count as a stable network connection), or stuck without a cell data connection. When you have a strong, stable, signal, exploit it and get the data down!
Analog Signal
Consider building all/some of your app functionality using SMS when possible. IP connections are hard to come by for truly mobile users, yet analog SMS can get into nooks and crannies "data" connections can only dream of. Apple/Android Notifications are nice when users have stable IP connections, but, for users on the move, that's not as often as we'd all like to believe.
HTTP Byte-Range Is Your Friend
Most cloud-based storage infrastructure supports HTTP as an interface these days, and importantly, most of those frameworks support Byte-Range requests. Get to know Byte-Ranges so you can build more effective caching and dynamic I/O schemes into your apps. No-one bothers doing this anymore, yet it can provide a significant edge for your app's experience.
Conclusion
Mobile apps could unilaterally be greatly improved if PMs and developers conceded that the dream of ubiquitous low-latency/high-bandwidth are a pipe dream, and that at an architectural level, software needs to be written with true I/O separation between data and UI layers.
PS - no, 5G doesn't solve either of these... it barely even improves them.