When I was doing performance work on the platform one of the notable things was how slow some of the message passing was, but how little that mattered because of how many active components there are computing concurrently and across parallel compute units. It'd still show up where latency mattered, but there are a ton of workloads where you also basically hide or simply aren't worried about latency increases on that scale.
A counter case though, as an example, is building the system using a traditional C-style build system that basically spams stat(2) at mhz or these days ghz speeds. That's basically a pathological case for message passing at the filesystem layer, and it's a good example of why few microkernels which aimed at self-hosting made it over the line. It's probably possible to "fix" using modern techniques, but it's much easier to fix by adjusting how the compilation process works - a change that has major efficiency advantages even on monolithic kernels. Alas, the world moves slow on these axes, no matter how much we'd rather see everything move all at once!
Edit, to explain: in ios, everything revolves around mach ports, which are capabilities.
https://docs.darlinghq.org/internals/macos-specifics/mach-po...
At one level, it proves the model. The shame is that Mach otherwise has kind of not taken off. Gnu the OS was going to be Mach at the core, at one point IIRC
[1] https://source.android.com/docs/security/app-sandbox#protect...
[2] https://www.csoonline.com/article/3811322/iphone-users-targe...
[1] https://www.ise.io/wp-content/uploads/2017/07/apple-sandbox....
All app authors must comply with the rigorous App Store guidelines so the technical limitations on what they can do don't really matter anyway.
Add sideloading as an option and we'll get to see how secure iOS really is.
GrapheneOS is definitely secure enough to tolerate sideloading, but I don't know if iOS is or not.