It's all about where the stable ABI exists. You can do anything in practice, but if you stray off the happy path it will result in pain. On PC OS, everything used C (or in Linux, syscall) ABI. On android the ABI is java based, and on iOS it's objc/swift based. These are deliberate choices and while they make some use cases more difficult, they are optimized for the use cases the companies care about. I'm personally preferential to a language agnostic IPC boundary being the abi, but that has its own cons as well.
Small correction.
On PC, MS-DOS did not use C, rather interrupts and there was no common C ABI.
On OS/2, a mix of C ABI and SOM, with C, C++ and Smalltalk as main languages.
Windows started only with the C ABI, nowadays it is a mix of C, C++, .NET, COM, WinRT, depending on the subsystem.
You’re conflating ABI with primary language for frontend development.
Android, iOS and “PC” all use the C ABI at their C stack level. They just have different languages available for their primary SDK.
Windows doesn’t use a C api primarily for example, so your PC example is wrong. Mac shares the same frameworks as iOS so is no more Swift/objc than iOS. It’s just that you can’t really ship electron (JIT) or easily use Qt (licensing) on iOS. But you can just as happily develop entire apps in the same C as you could on a “PC”. Case in point, blender builds for iOS.
Android is definitely the most out-there of the platforms because the jump from JNI to Java SDk is quite large but that is completely orthogonal to what you’re incorrectly claiming. Your comment is conflating completely opposite ends of the stack, but if we go by your definition, Android is Linux just as much as Linux distros on desktop.