RubyMotion Tutorial: Write iOS Apps in Ruby | Hacker News Reader

RubyMotion Tutorial: Write iOS Apps in Ruby

rubymotion-tutorial.com

68 points10char11 comments

95% of writing a good iOS app involves knowledge and skills unrelated to the language. The tools, the frameworks, the design and interaction models, location awareness, and more. Objective-C is a microscopic hurdle compared to getting the rest of it right.

Objective-C is a fine language and is pretty easy to learn. Nevertheless there are a few advantages to RubyMotion for certain developers:

* No XCode. Getting comfortable with Xcode takes time and I frequently hear people complain about it crashing, being bloated, etc. With RubyMotion you can just use your regular text editor and a command line.

* Ruby. While Objective-C isn't bad, I actually enjoy using Ruby. I'm much more likely to refactor and abstract functionality.

* Third-party gems and code: While there are limitations, it is generally pretty easy to use gems and other ruby code in RubyMotion. From what I understand, you can also call out to third-party Objective-C libraries from within RubyMotion, so you don't lose out on that ability.

* REPL: Using a terminal and the simulator you can interact with your code while its running.

I wouldn't recommend using a regular text editor and dealing with the iOS APIs. I pretty much despise IDEs, but sadly the objective-c paragraph long method signatures require it. That's actually why I didn't even bother with RubyMotion, it doesn't solve the thing I hate the most about objective-c.

I just use AppCode, with Xcode for interface builder and dealing with things like data models. It's closest enough to something that isn't a total piece of shit so that I can avoid slitting my wrists all day.

Having a text editor does not mean that completion does not work. ctags etc. provide such features. It might not be as good as completion using a static type checker and might have false positives, but "uninformed" completion goes a long way.

Also, some of the higher level api look much more Ruby-like: https://github.com/rubymotion/BubbleWrap

Totally agree with that, but RubyMotion is more than just the Ruby language. There's no heavy IDE, no complex target/build setup, comes with a lightweight test environment, an interactive REPL...all that adds up to remove a lot of pain in the existing iOS workflow. You can definitely be proficient with the existing tools but I think RM is a lot better for newcomers.

There are some problems (debugging isn't great right now, memory bugs happen if you do tricky things), but it's only a few months old and I'm confident it'll get better over time.

Well I already saved 5% then, which is a good start.

Trouble is that by ignoring Objective-C, you make the rest far more than 5% harder. Like it or not, it's the native language of the platform, and all of the documentation, sample code, and community help assume familiarity with it.

This actually looks pretty powerful: http://www.rubymotion.com/features/

Here's the most important part:

> RubyMotion implements Ruby on top of the Objective-C runtime and iOS Foundation classes. Thanks to this tight integration, Ruby can interface with iOS very naturally at no performance expense.

> You can mix Ruby and Objective-C code, always have access to the latest C and Objective-C iOS APIs, and also make use of 3rd-party frameworks.

Looks cool. What are the benefits of RubyMotion over Rhodes: http://www.motorola.com/Business/US-EN/RhoMobile+Suite/Rhode...

I can't tell if Rhodes creates 100% native apps or some kind of web/native hybrids, but it doesn't like it uses Apple's iOS SDK. RubyMotion lets you use the same APIs and classes as normal Objective-C apps, so all existing literature is totally useable.

And something I didn't mention in the tutorial: you can even use existing Objective-C frameworks and code in RubyMotion apps using CocoaPods[1].

[1]: http://cocoapods.org/

Rhodes doesn't create 100% native apps. Your compiled app has a web server embedded in it.

Reply on news.ycombinator.com