This would be all kinds of awesome, but I think it's probably a dream. To leap from ObjC to Ruby would be a absolutely massive undertaking for them.
That said, they've pulled off crazier shit before.
That said, they've pulled off crazier shit before.
Now as for whether they'd replace Objective-C with MacRuby, no, that wouldn't make sense. The two would live side by side. Apple can continue to implement Cocoa frameworks and core applications in Objective-C while also offering an excellent Ruby programming environment built on top of that.
It's sort of like C# vs. F# or IronPython in the .NET world -- Microsoft didn't have to replace the base .NET assembly implementation language (a.k.a. "assembly language for CLR") in order to provide more attractive dynamic or functional languages on top of the same infrastructure.
EDIT: In fact, the semantic mismatch between Objective-C and dynamic languages like Ruby is less than the mismatch between dynamic languages and the CLR, which mirrors the statically-typed semantics of C#. Is Apple's combination of the Objective-C type and dispatch systems and LLVM going to one-up .NET from a direction that we didn't see coming?
Here's one example: With the .NET type system, you can check a set of arguments against the signature of a method defined in the type information of an object instance, which means that you can be absolutely certain that your invocation will succeed without corrupting state or returning incorrect results. What's more, you can do this check at compile time (in a static language, like C#) or at run time, via reflection. The .NET JIT and runtime code generation facilities mean that you can do 'static' verification at load time for scripts instead of at the point of every invocation. In cases where you have a mismatch between the types requested and the types provided, you get clear, precise error feedback that allows the problem to be corrected. The .NET runtime is able to use this type system to perform a large number of useful safety checks against all code when it's first loaded, so that in many cases it can guarantee no memory corruption or out-of-bounds accesses will occur without having to check every single operation.
As the vast majority of Objective C invocations in a Cocoa application are effectively static (you're sending a message, as described in the Apple documentation, to an object of a given interface, as described in the Apple documentation, which you constructed following instructions in the Apple documentation), the dynamic nature of ObjC invocation wins you very little. The ObjC type system cannot provide you much assistance for those invocations, because it's built atop the C type system - GCC will check your argument types for you statically at compile time, but at run time, given an arbitrary ObjC object, it's going to be quite difficult to be certain that an invocation will succeed. What's more, in most cases GCC can provide no more than warnings, and those warnings are often incorrect.
On the other hand, for the vast majority of code written in a language like Ruby or Python, your method signatures contain no type information, so no validation can be performed. Neither Objective C or .NET win here because both require strong types for arguments. You need only look at NSArray to see how little you win by using Objective C in this case.
Ultimately, in both cases, neither environment is a good fit for a language like Ruby, but I would argue that .NET (and, for similar reasons, the JVM) provides a far stronger foundation upon which to build a language like Ruby. Building a language like Ruby on top of Objective C is only superior to building it in C due to its status as Apple's preferred language for OS X development.
And I would nitpick the argument that Objective-C requires types for arguments. You can declare arguments as "id" in Objective-C, exercising message passing, and objects will respond to the messages regardless of type. This is why MacRuby and Objective-C are a good fit: both languages are based messages, a concept alien to .NET.
Not to mention the ability to call existing APIs and the fact that C and MacRuby will both be running on LLVM—I think it's less crazy than it appears.
Java/Cocoa? Java/WebObjects? Heck, we still have the "NS" prefix…
While I think that MacRuby will definitely gain some traction, I don't think they'll completely replace it any time soon.