There's no fundamental reason that underlying map data used by a good % of mapping apps, couldn't be stored 1x on-device, in some standard format and shared across apps.
Users could pick & choose what subset(s) of map data they want to store locally. Different apps could pick & choose what features to offer, how to use available data & how to render it.
Sad to see that such a conceptually simple problem hasn't been addressed yet. We're talking a good # of apps here, many millions of users, and enormous amounts of storage & bandwidth wasted.
Edit: I'm assuming that last bit is a problem for the app developers themselves, too.
There are a few fundamental reasons: 1. at least iOs app privacy/sandboxing model makes sharing any data files pretty difficult, if impossible. I suspect Android has similar issue. 2. there is no such thing as "just map data" - every app has to do opinionated decision what they need in their maps data (e.g. aerials, elevation, choice of POIs, languages etc), how it gets styled (it makes requirements to actual data). And this is for just simple base map data, you have also routing, address search databases etc on top. So there is not much to share really, and not easy to share. Not even talking about huge challenge to standardize it.
(I'm founder of Nutiteq, we also did FOSS SDKs for offline maps)
Every version of Organic Maps and CoMaps (and probably to some extent OsmAnd) use slightly different formats of maps; consider a new feature to support park bench backrests/colors/materials. That info likely wouldn't have been in the map files before for efficiency, and now it needs to be. But any given other app may not have that feature at all, and instead decides to save space and bandwidth by compressing the files instead. And a third app might improve performance on old devices by preprocessing routes and storing them in a new format in the map data.
So you can see the work of keeping map files cross-compatible would either hamper the release of new features, or take a bunch of work, all to save a few hundred MB on people's phones
Again, I don't think you understand how it works in detail, and you just assume from a high level that "it all looks the same, therefore it must be simple to make it all work together".
Some apps show raster tiles. Which means that if you want a different style, you just cannot share them. If you want the same style but you don't want to show exactly the same data, you can't share them. "Ok, you say, I personally don't care about raster tiles, I believe that everybody should be happy with vector tiles". That is wrong, but let's assume it.
Vector tiles are much more compact, but at the cost of the rendering engine: it has to read the information stored in some format and render the map according to different things like the style. How do you load the data to access it and rendering rapidly? Maybe you want to remove data so that it's more efficient and doesn't lag, or maybe you really want all that detail and more phones will lag when loading. Maybe you want to optimise the storage, so you remove the information you don't want to show, etc. Those requirements are incompatible, it's a tradeoff. Different apps choose different tradeoffs and therefore don't share resources.
Don't get me wrong: some apps could decide to share resources, and that would be fine. But it's not like all apps have the exact same needs and should obviously be sharing all that.
If you think that maps are "obvious" and a "conceptually simple problem", then you surely don't know much about what goes under the hood when you load a map in your phone. It's is actually quite complex.
Users could pick & choose what subset(s) of map data they want to store locally. Different apps could pick & choose what features to offer, how to use available data & how to render it.
Sad to see that such a conceptually simple problem hasn't been addressed yet. We're talking a good # of apps here, many millions of users, and enormous amounts of storage & bandwidth wasted.
Edit: I'm assuming that last bit is a problem for the app developers themselves, too.