Objective-C isn't used in XNU the kernel that Mac OS X uses, Mach is a mixture of C and C++ (A subset of it actually, known as IOKit).
I imagine that the kernel can easily compiled with the Objective-C or Objective-C++ compiler, if Apple so wishes.
All languages require runtimes, even C. The thing is that C as high level assembler it is, uses the operating system as its runtime.
The C language is also part of Objective-C, in a similar vein as C++ also supports most of the C89 features with small exceptions.
So it is possible to have the Objective-C runtime compiled using the C subset of Objective-C. This is known as compiler bootstrapping.
The same applies if you would be using the C subset of a C++ compiler.
I am old enough to remember the days when UNIX and C were funny research projects. Look at them now.
So I leave you with a list of research projects for the boring days, when you don't have anything to read.
http://www-spin.cs.washington.edu/
http://www.oberon.ethz.ch/archives/systemsarchive/native_new
http://www.ocp.inf.ethz.ch/wiki/Documentation/Front
http://programatica.cs.pdx.edu/House/
http://research.microsoft.com/en-us/projects/singularity/
I don't doubt that C is not the systems programming language of the future. But it's not going to be done in a system that's based around automatic GC either.
Additionally, I find it interesting to note, that if you had in fact been very familiar with all the work you mention. You should actually have noted that many of these systems go through significant effort to sidestep the GC.
It not just talk about some guys showing up papers at OS geek conferences.
The Oberon Native for example, was for long time the main operating system at the operating system research department at ETHZ. Most researchers used it as their daily OS for all tasks you can think of.
http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf
The GC was done at kernel level. Besides Oberon code, there is just a little bit of assembly for the device drivers and boot loader.
No, admittedly, I don't, at any more than a basic level. But you're still wrong.
Try compiling, linking, and running an ObjC program without the ObjC runtime. See how that fails. See how long it takes you to write a minimal runtime that can run your program in user-space, and then kernel-space. It won't be quick.
Try compiling, linking, and running a plain-vanilla C program without the "C runtime" (I guess you mean a combination of libc, libgcc, and crt.o, basically what you get when you pass -nostdlib -nostartfiles to gcc). Yep, that'll fail too. Then get it to compile and run anyway. Not that hard.
That's* the difference I'm talking about.
At the very least, kernels like Linux and Mach/Darwin already have kernel-friendly replacements for the libc functionality they commonly use. Doing something similar for ObjC would be time consuming. Certainly it isn't impossible, but note that I never said that: I merely pointed out it wasn't easy.