Every Objective-C class/object is a C structure. Every Objective-C message send is actually a C function call (objc_msgSend). Every Objective-C method is actually a C function definition. So, to the contrary, every Cocoa project is just using C functions, types and using the ObjC runtime.

The point you are trying to make is that porting an ObjC application to another language would be difficult because of the syntax of the language, notably, the interspersing of arguments within the method name. My point is that this has zero relevance to adopting a new application-level API.

An application-level API hooks into OS-level calls (which are not ObjC), which gets turned into assembly, which gets turned into machine code. The only way Cocoa applications would no longer run is if the Cocoa library could no longer bridge the the operating system or if they intentionally did not ship the Cocoa library. Thus, creating a new application-level API would deprecate Cocoa, but wouldn't render those applications useless.

Clearly, a company would have to transition to the new language/API. However, once again, the syntax of ObjC would not make it any more difficult or easy to make this transition compared to any other language. And this did not stop Apple 10 years ago, so I don't envision this stopping them again (C Carbon -> ObjC Cocoa; note that you can still make Carbon calls on Mac OS X).