You might appreciate that many of these processes compete internally within a single app’s access to compute/networking. This is how a developer can prioritize

You might appreciate that many of these processes compete internally within a single app’s access to compute/networking. This is how a developer can prioritize within their own app’s processes. Regarding prioritization across multiple apps’ processes, you might be surprised by just how considerate iOS developers can be. They (we!) tend to obsess over user experience, and knowingly adjust QoS to fit the user’s best position vs the app’s best position, understanding that such a values-first approach to development raises overall product quality. (You can call that “alignment.”) After all, it is literally a single line of code. For my primary project minimal.app, I use .userInteractive QoS extensively for collaboration and sync, and otherwise fall back to a more appropriate QoS. The point that I have internalized is that this most crucial process (sync/collaboration) is an order of magnitude or greater more important than any other process. Of course I will internally prioritize this key process, and such internal prioritization naturally bleeds into the greater ecosystem appropriately, benefitting the user. This QoS system is so well-designed that my self-interest (or rather, my obsession with making my app as useful as possible) aligns across other apps and their self-interests.