eXPassenger is right - developers often code something that works successfully in their always-on environment while forgetting that the app will often be used in less connected places. Or rather, the developers code what the spec tells them to code, and the project managers didn't put "work despite a dodgy connection" in the spec. But twas ever thus - I think it was Macintosh System 7.5, way back in 1994, that introduced a new help system that would regularly fail unless you were online.


I've not used the Firstbus app - we're mercifully free of Firstbus round here - but in my experience, most generalist developers just unthinkingly embed an off-the-shelf map component in their apps and then tick the box to say "map done". Usually this is the platform-native one (i.e. Google or Apple maps), sometimes it's Mapbox or another third party. In-app maps absolutely can run offline or in conditions of limited connectivity, but only if you put the effort in!

 

It's less needed these days but I was certainly aware in earlier Coffee Shop days of the need for it to work on a very thin connection that frequently broke.  It still works thin, though currently the worker server is internally a but spongy.

 
I know that I am showing my age, but I believe that programmers today assume that connectivity, processor power and storage will always be available and concentrate instead on the 'prettys'.

 
The Firstbus app put me in mind of the following as it appears to be particularly liable to being bitten by this - once the phone signal's contention ramps up, the app stalls and throws out a rather uninformative error message.

I'm wondering if the authors of these sort of apps need to concentrate on work to reduce the volume of data that needs to be exchanged at these times, or to make the handling of this situation more efficient so that the app has a better chance of continuing to work when the network connection is less than good. For starters, they don't appear to cache the image and therefore data-heavy operations such as their handling of maps.

Perhaps the likes of MQTT technology offer an opportunity to improve things? (MQTT is a communications technology much used by the 'Internet of things' to exchange small amounts of data on a network connection that may be poor quality or unstable. I've no idea what I'm talking about here so may be out on a limb).

Mark