It's handled by your http client which may or may not be part of the OS or even something in between (speaking of Android, it's probably far more likely to be o

It's handled by your http client which may or may not be part of the OS or even something in between (speaking of Android, it's probably far more likely to be on the OS side on iOS but if the OS allows raw TCP then it can't really keep an app from running its own http(s) on top of it). A frequent problem on android that might lead some to throw validation under the bus, is that certificate validation is much less robust than the one in browsers, particularly on old devices. A typical scenario is that the certificate of one of your backend approaches EOL, ops dutifully obtain a new one and it checks out nicely on all browsers. But a whole bunch of older Androids that might make up a quarter of your user base of you are unlucky has never heard of the root certificates involved so the app becomes unusable. A similar situation can arise if you have clients that check revocation (good) but don't check for alternative signature chains like a modern browser would do (not so good). The correct way to solve these situations is extending the server configuration with another certificate chain that is valid on the devices in question, no doubt about that. But when the app is not a core use of the backend and there server is not run by the same organization, breaching the wall of "but it works in all browsers, clearly the error must be on your side" defense can be quite hard. Nontechnical leadership will be extremely tempted to do the writing thing.