As a developer, I can tell you there is plenty of places an App writes and stores data, that if it wasn’t protected, I’d have to consider my app compromised. Settings/configuration are the obvious starting area, but anything that is “app internal” also falls under that, like, an internal cache, or sqlite database with an index of or data I have downloaded. Those all also exist on mobile and are used heavily. And weren’t those apps sandboxed by the system, this would all fall apart. (Also simply because you can’t access an sqlite database safely from more than once thread at a time.)
I do think there is very reasonable case for giving apps at least a configuration-type of folder to store this kind of information. And from the system protect them from especially accidental access, so that you one app doesn’t f*-up another app by messing with its internal data. That would only work if you can safely distinguish apps and app-disguising can be largely prevented.
Of course all this data is still accessible to the user themselves outside of the sandboxing mechanism (also because you sometimes just need to delete it – ehem). But it shouldn’t be shared between different apps. There is a reason we have different databases for different apps.
This is mostly about internal data, like metadata, indexes for performance and alike. And I do agree we need to find a mechanism to allow easy access to the actual content across apps. I like @Viv’s idea of “containers” here. Think of how many modern operating systems organise all Pictures in the “Photos”-Folder (which some then even localise, like Mac) and all Photo-Related Apps “know” about that. In the case of the sandboxed mobile, apps even have to explicitly request permissions to these on a case-to-case-bases.
I’ve argued before (and will here again) that permissions need to be more granular. Giving an app access “to a folder” still means it can delete all files in there without asking – or re-arrange the structure and I can’t find anything anymore (and thus render indexes of other apps incompatible). I think we are limiting ourselves largely by thinking of these in terms of ‘files’ and ‘folders’, when there is no need to. What if we instead think of these as “containers” (as a specific data type) with certain features, sub-items and protections. As an example, the “Photos Container” could have a feature allowing an app to “request picture” – that the user triggers in the email app by saying they want to attach a photo. The user the selects the photo from within the “launcher” (or whatever) and the “Photo Container” delivers the selected photos to the app. The App never had any read/write/whatsoever permissions to the container itself or the data it contains.
This is a very common use case on mobile phones today. MANY of them don’t even expose any file system operations to any apps NOR THE USER ever. That there is a filesystem under it, is more a relict of the history of how to organise hard drives than it is needed or appropriate for the use cases. They want to get rid of these structures and their bounds for a while, why would we bound ourselves into them when we don’t even have them in the first place?