IMO iOS and Android are terrible examples of how to do this. They break decades of convention in how to write POSIX-like applications, and force developers into locked-in practices.
Android gives lip service to the NDK, but in practice you can't really run many useful C/C++/Golang/Rust/etc programs on Android, because the system breaks POSIX. You can't keep a simple webserver running without starting a foreground service, which requires Java/Kotlin. There's no /etc/resolv.conf for DNS resolution, so you have to use custom servers or use the Android NDK compiler (which can be a huge pain). Plus they lock down the filesystem more each year. Android 10/11 are a complete mess on this front. Fortunately they've rolled back some of the more draconian changes, but only because of developer outcry. The fact that they even wanted to do some of the things in the first place is sad.
I'm not saying this is an easy problem to solve, but it's obvious that the big boys have only made a token (if that) effort to build a good, open way of doing it.
I think proper sandboxing on a traditional Unix is hard enough that ~nobody does it right; you can't let any apps run as the user if you want to prevent them from snooping on each others' files, but the user needs to be able to control all of them.
I don't know of a justification for removing /etc/resolv.conf, but I guess "applications' networking should be under the control of the user" is sorta necessary; I think it'd make more sense to do it with network namespaces or iptables rules or something, but /shrug.
>> you can't let any apps run as the user if you want to prevent them from snooping on each others' files, but the user needs to be able to control all of them.
I was thinking about that recently and my conclusion will be highly controversial.
In the same way Wayland implements security that X never could, I think the GUI might be a place to implement file and folder access permissions. If the user does not grant access to a file through a dialog, the app couldn't read it. Same for folder access, which would grant an application access to an entire folder or perhaps an entire hierarchy.
Obviously this would break some things, but real change may require some of that. How much, I don't know.
>IMO iOS and Android are terrible examples of how to do this. They break decades of convention in how to write POSIX-like applications
That's a good thing. We should break "decades of convention in how to write POSIX-like applications" if we want to get any further than POSIX-like OSes and programming models...
> Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.
> Reuse your own or other developers' C or C++ libraries.
Writing POSIX CLI applications is not a goal.
ISO C and ISO C++, alongside OpenGL ES, Vulkan and OpenSL are more than enough to have something like Qt running.
I’m a big fan of the capability-based photo access in ios; when an app tries to access my photos it opens a system dialog which allows me to select the set of images the app can see.
That's on them ("regular computers"). Their OSes could offer the same capabilities to map to.
That said, it's not:
(a) as if there aren't cross platform photo apps that run on iOS and "regular computers". Photoshop and Lightroom come to mind immediately, Affinity Photo also. And those aren't just iOS and Mac, they're also on Windows. So there's that.
(b) as if what would slow you down / prevent you from doing such a cross platform photo app would be the iOS capability / image access request feature.
Android gives lip service to the NDK, but in practice you can't really run many useful C/C++/Golang/Rust/etc programs on Android, because the system breaks POSIX. You can't keep a simple webserver running without starting a foreground service, which requires Java/Kotlin. There's no /etc/resolv.conf for DNS resolution, so you have to use custom servers or use the Android NDK compiler (which can be a huge pain). Plus they lock down the filesystem more each year. Android 10/11 are a complete mess on this front. Fortunately they've rolled back some of the more draconian changes, but only because of developer outcry. The fact that they even wanted to do some of the things in the first place is sad.
I'm not saying this is an easy problem to solve, but it's obvious that the big boys have only made a token (if that) effort to build a good, open way of doing it.