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.
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.
Just because you can use it from C doesn't mean it's a C ABI. You can do almost anything from C, but the semantics of the APIs require additional work in order to use correctly. Just because golang can interface with C doesn't mean C APIs have a golang ABI right?
ABI is the language used to write the OS, thus OP is kind of right.
While Windows has moved away from pure C, and nowadays has ABIs across C, C++, .NET, COM, WinRT interfaces, you can still program Windows applications in straight C.
The caveat is to only use APIs up to Windows XP, and Petzold's book to follow along.
You can argue that JNI technically is exposed via C, yeah if you ignore the JVM/ART semantics that go along with it.
Likewise on Windows, technically you can use bare bones structs with function pointers to deal with COM, use CLR COM APIs to call .NET via reflection, and a similar story with WinRT, but it is not going to be fun, and then there is the whole type libraries that have to be manually created.
I think we’re talking past each other, and you’re largely repeating what I already covered .
My original response delineated between levels of the stack, and also already called out that Android requires you to use the NDK/JNI to use the C ABI.
I also specifically called out windows as well.
My point is that the original persons distinction of what supports a C ABI is conflating different levels of the stack. It’s not a useful distinction when describing the platforms and the windows case is why I quote “PC” since desktop semantics vary quite a bit as well
A more useful delineation of why mobile dev is harder to just do an asm hello world is that mobile dev doesn’t really have a concept of CLIs without jumping through some hoops first. So you have to pipe such a thing through some kind of UI framework as well.
A ton of native apps are written on mobile. On desktop, there is a trend of shipping a full browser together with a goddamn webapp instead of making a proper desktop app. I wouldn't say that desktop is more successful there...