Throwing Cold Water on MacRuby for iOS

Fad du jour on Twitter is #welovemacruby, echoing a call posted here to bring MacRuby to iOS, calling it to Apple’s attention through the usual process of posting duplicate feature requests to

Please don’t. This is as bad an idea as I’ve heard in some time. The petitioners are only wasting their own time and Apple’s.

The reason I can say that is that Ruby was already tried and rejected as a first-class language for Mac development. In Leopard, Apple made Ruby and Python first-class languages for Cocoa development, creating Cocoa bindings for those languages and fully supporting them with Cocoa-Ruby and Cocoa-Python project templates in Xcode. Tutorials were posted… code was open-sourced… developer sessions were presented…

And yet, there’s no indication that there was any significant developer up-take. The Ruby and Python project templates disappeared in 10.6’s version of Xcode, a seemingly quick admission of defeat, or at least irrelevance.

Arguing this on Twitter, I put out a call to show me examples where any scripting language has delivered end-user applications on the desktop since the days of VB and Hypercard, or ever done so on mobile. To his credit, Philip Hodgetts fired back with some of his examples from the video production world. So far, he’s the only taker.

Still, I’ve long been impressed by the degree to which scripting languages have failed to be adopted for desktop and mobile development, given their dominance on the server side. Since the fall of VB, and setting aside the interesting case of browser apps running in JavaScript, substantially all major end-user desktop applications are written in C-derived languages, either compiled or running in a VM: C++, Obj-C, C#, and (if we’re extremely generous) Java. If Ruby and Python are so great, why haven’t they made greater in-roads into desktop development? Even if Apple were employing nefarious skullduggery to keep Ruby down — you know, just because Apple is evil and everything — why haven’t Ruby, Python, Scala and the rest of the hipster scripting languages taken over on Windows and Linux? (At least that’s my impression… I’ve searched for information on developing Ruby for Windows, and all I get is pages about devloping with Ruby on Windows, meaning to write your Ruby webapps on a Windows box, just like all these “Mac Ruby” developers seem to be web developers who own Macs. They’re writing webapps with Ruby, not desktop apps.)

I’m not going to say that the C-based languages are ideal for desktop and mobile development, but the fact that they haven’t been seriously challenged by the scripting languages, despite all the interest in and shared knowledge about scripting languages, makes me think that that they’re the best choice we have. It is not plausible to think that lots of developers haven’t already tried to use scripting languages for desktop apps. Surely they must have, and the results haven’t yet been compelling enough to dislodge the compiled C-based languages.

There’s one more thing. Inspired by the interest in the well-attended and voted-best-in-show Cocoaconf talk about the Accelerate framework (hardware-optimized low-level math and DSP functions), I posted a pair of tweets yesterday saying that good iOS developers were looking for ways to make their apps better, while Android developers were looking for ways to make their development experience better. On iOS, we’re willing to endure some developer pain in order to get apps running faster and looking prettier. Adopting a scripting language, with their inescapable overhead, runs counter to that. Android devs even acknowledge the performance advantage of the iOS software stack… so why mess that up with the overhead of a scripting language?

Thusfar, none of the really serious, really good iOS developers I know have retweeted their support for #welovemacruby. I don’t think that’s a coincidence. And I don’t think this is just an “Obj-C is what it is, take it or leave it” stance. I have yet to hear a case made for MacRuby on iOS. It won’t be faster, and while it might attract a few developers, the platform obviously doesn’t lack for active development. Indeed, the best argument made by the site is empathy (or pity) for the guy who works on it. I wish him the best, but I don’t see any evidence that MacRuby for iOS is going to improve individual iOS apps or the platform as a whole.

Comments (6)

  1. casademora

    I’m going to take the contrarian stance on this post 😉

    From a technical perspective, I think MacRuby, as it stands now, cannot be the primary development language for the iOS environment for one simple reason: Ruby is *so* dynamic, it basically requires that there be some runtime garbage collection mechanism to function properly. Ruby, the language, holds no provision for dealing with memory yourself, so even ARC is out of the question at this time.

    Following the technical argument that MacRuby specifically is slow is not learning the facts. The past implementations of Ruby (and Python) were bridges to the ObjC runtime and native environment, so I can see how you might think MacRuby follows the same history. MacRuby is NOT A BRIDGE. It’s not some interpreter sitting on top of some ObjC codebase. Think of MacRuby code at the same level as ObjC code…they’re more peers in the MacRuby implementation.

    The fact is, MacRuby apps can be compiled in the exact same manner as native ObjC apps. Performance is not an issue in this case. So, if it’s not performance, then it’s the tooling, right? Well, MacRuby integrates not only with Xcode directly through IB, it also can talk to your regular Objective C code. Think about how this works…MacRuby *and* ObjC are compiled into the the same MachO executable. They are both running on the same LLVM and ObjC runtime. It makes sense that Ruby can see ObjC code. MacRuby is basically shorthand ObjC at this point.

    Just because Ruby is a scripting language doesn’t mean that you cannot build powerful mac or mobile applications on it. It just hasn’t happened yet, and probably not because the “serious” developers think it’s not the right tool. Those “serious” developers are probably comfortable in the tools and environment they’ve got already. If I had a process or a language I had invested years in learning, I’d probably be wary to change it too. Most corporations are weary of change….just see how long it’s taken Windows XP to go away… and Java never seems to want to go away…change is hard whether you’re big or small.

    I will agree that I’d rather build apps on the native environment and the native tools. You will get the best, most compatible experience, you will never be playing catchup with the frameworks, and you’ll get the best support out there since there’ll be a wider community out there. But at the same time, what if you had a tool right in front of you that let you work faster, made your code a tad more readable and still worked with your toolset and mindset, would you switch then? Perhaps not, but that’s ok. But that doesn’t mean there shouldn’t be some language option to use MacRuby instead of ObjC.

    As a developer with a lot of time invested in learning ObjC well, I have an interest in seeing the continued growing adoption of ObjC. But at the same time, I keep an eye out for technologies like this that can help build great apps.

    MacRuby is a little different. Perhaps it’s time to think different, again.

  2. headius

    Again with the performance statements.

    MacRuby is built atop ObjC, and integrates tightly with it. Many of MacRuby’s data structures are implemented in ObjC where they’d be implemented in C in standard Ruby. Some forms of dispatch are done just like ObjC.

    This does not mean Ruby is as fast as ObjC. The performance of actual Ruby execution can still be an issue, as can Ruby’s semantics applied to ObjC data structures.

    I’m not saying MacRuby isn’t awesome, but this meme that somehow it’s “written in ObjC so it’s as fast as ObjC” needs to end.

  3. jakesinger

    You’re article misses the real use case for MacRuby on OS X and iPhone:
    -in-house development of applications for in-house deployment.

    We need to be able to quickly develop and deploy applications internally. Scripting style languages give us that capability. What makes MacRuby really attractive is the native performance to an excellent scripting language. A language, mind you, that is built on the same principles as ObjC.

    Having access to all the Ruby Gems and frameworks is a major win. Both on the Server and the Client side, be it OS X Server and iOS clients.

    This is a win for both Apple and the developers. It creates affinity for Apple among corporate users. It allows Apple products to be the core of major internal deployments. Wants a body of software is developed for the platform internally, it makes it very difficult to switch platforms. Look to Microsoft as an example in this area.

    Apple needs to look at this as a 10 year cycle, they shouldn’t expect major adoption until a threshold is reached after a few years of stability. Otherwise, Apple products in the workplace will always take an up and down seesaw ride within corporate america.

  4. jpollard91

    Hi, as a newb to Macs (just got my first one a few months ago, not counting an early-90’s Mac), and also interested in Ruby and iOS for fun reasons (being a full Windows/.NET/web dev by day…), it looks like the developer of MacRuby has made a commercial product for developing native iOS apps, on the foundation of MacRuby. A little pricey ($199), and my own bias is usually towards learning the native stuff anyway (at least for the groundwork–and when things don’t work as expected). I’m still dropping into native Win32 in C# from time to time…But I can’t really speak for or against anything until I really dig in, this response is really just more informational…
    Like you mention in another post, learning a different language (or framework), isn’t necessarily a waste of time, it can provide insights on new (or better ways) of thinking about problems, or just be interested in and of itself.
    Cheers and thanks for the blog, it’s chock full of good Mac and iOS info.

  5. […] 除了Mac应用,你一定也很想知道能否用MacRuby来开发iOS端的应用,到目前为止Objective-C仍然是官方的首选,也有人泼过MacRuby的冷水,但MacRuby的开发者并没有放弃,他们开发了RubyMotion,让开发者能方便地使用Ruby来开发iPhone和iPad的原生iOS应用,且得到众多好评。 […]

  6. […] isn’t one on iOS. That kind of surprised me at first, until I remembered that I was the one throwing cold water on scripting languages on iOS as an idea that sounds good in practice but hasn’t panned out in reality. Still, while it […]

Leave a Reply to 欣欣向荣的Ruby家族 | chainding Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.