> Sometimes we forget that the OS exists to facilitate the apps, not the other way around For OS where the base operating system didn't offer much functionalit

> Sometimes we forget that the OS exists to facilitate the apps, not the other way around For OS where the base operating system didn't offer much functionality to apps beyond the basic API for building controls and so on, this might be true. For Apple's systems, especially macOS and iOS/iPadOS, this isn't quite true. On iOS, apps need to be built according to system conventions and standards in order to be able to take advantage of a lot of services that the OS provides (such as accessibility, automation, i10n). When a macOS or iOS ignores system conventions, the result can range from completely unnoticeable, a slight inconvenience, or the app being next to unusable after the OS updates due to underlying features being changed without the developer having updated their (needless) custom code to account for it. I notice this with the Sensibo app which follows Material design guidelines. It took me a long time to figure out how to edit a particular bit of information because the icons that the app used were not what I was expecting. On iOS, an editable table view should be accompanied by a button at the top right that says "Edit"; Sensibo instead provided a pencil icon. After I finished editing, I wasn't sure what to do — on iOS, I expect to see a "Done" or "OK" button where the Edit button was; instead, Sensibo required me to click on the pencil again even though it was greyed out and looked inactive. When an app doesn't conform to the guidelines and I have a choice about whether or not to use that app, I'll generally prefer to find something else where I'm not expected to memorise how to use it. Sometimes we forget that apps exist to facilitate getting tasks done, not forcing us to remember their deliberately-included inconsistencies compared to every other app on the system (including third party ones).