RubyMotion - Ruby for iOS

http://www.rubymotion.com/

by acangiano • 14 years ago

485 240 14 years ago

spicyj• 14 years ago

This looks really cool -- would be nice if there was some way to try it out before buying.

This is from Laurent Sansonetti, the original author and long time maintainer of MacRuby. It doesn't say that anywhere until after you buy it, which they should really change since that made me go from "Uh, did some random guys just take MacRuby's code and hack in some extra stuff to sell it?" to "Holy crap so THIS is what he's been working on!"

octopus5• 14 years ago

Actually they say that this is based on MacRuby:

http://www.rubymotion.com/features/

at the bottom of the page:

RubyMotion is based on MacRuby, a widely-used implementation of Ruby created and maintained by Apple for over 4 years. Starting from a solid and stable code base, the guys who originally created MacRuby now work on RubyMotion. You're in good hands.

jeremymcanally6• 14 years ago

Ah, now I see! I suppose I glossed over that. It should be bigger. ;)

RowanH• 14 years ago

Some impressive stuff here, check out the getting started video at around 4:30 The 'positioning a label' live from the simulator command line is way cool. http://www.rubymotion.com/getting-started/

sant0sk1• 14 years ago

This is really awesome, but I found some bad news in the FAQ:

> Because RubyMotion implements a dialect of Ruby that is statically compiled, regular Ruby gems will not work in RubyMotion. We provide documentation which describes how to architect gems to work with RubyMotion.

deedubaya2• 14 years ago

Anyone who has done any serious MacRuby development would already tell you that normal Ruby gems aren't usually the best way to go (slow, don't use Objective-C frameworks).

I can see where this could be a problem if you typically just glue gems together to make products, but if you're used to rolling your own solutions it isn't a big deal.

Sucks, but not a show stopper.

jballanc10• 14 years ago

On the upside, CocoaPods support is integrated with RubyMotion. Sure, there is a whole world of useful Ruby gems, but, generally speaking, the libraries you'll find in CocoaPods have been developed specifically for iOS.

thibaut_barrere2• 14 years ago

I personally don't care, as I will mostly use a mixture of well-tested, iOS specific ruby libraries I will write and share, together with ObjC libraries.

jamesgeck0• 14 years ago

I didn't see any documentation describing the ins and outs of statically compiled Ruby. Anyone know how it differs from normal Ruby?

tobiasbischoff• 14 years ago

nice, but where is the advantage over just using objc? the hard part of coding for iOS isn't objc, it's learning how to use all the API's.

hlidotbe5• 14 years ago

Having been part of the private beta I can tell you that it's a huge time saver. Objective-C is nice be ruby is much more expressive, you can use the same API with much less code, you can skip XCode altogether and use your favorite editor, ...

I can't express properly how awesome it is, really.

protomyth3• 14 years ago

The call syntax is still painful compared to straight Objective-C as it actually uses more characters and is not as clean. I really wish he had come up with something that resembled Objective-C better.

mattgreenrocks2• 14 years ago

In the Ars article, I noticed the author mentions you can't use XCode's layout tools.

In practice, how big a problem is that?

octopus5• 14 years ago

It depends, if your background is in dynamic languages like Perl, Ruby, Python than using Ruby for iOS makes a lot of sense. On the plus side Ruby is better for programmer productivity.

If you have a good background in C than yes, using Objective-C is not so difficult.

FuzzyDunlop• 14 years ago

I concur with the other posters who say Objective-C itself is not the barrier, the API is. Such is the design and verbosity of the API (which is great for self-documentation and talking about, less so for typing), it'd be an absolute nightmare to work with without the extensive auto-complete Xcode offers.

This is a very exciting (and very positive) development, but at this moment in time I would still bite the bullet with Objective-C. I came to it with a background in PHP of all things and didn't struggle with picking it up in a few weeks.

I can't wait to see the things people do with it and with Ruby's metaprogramming.

pjmlp4• 14 years ago

I agree, but many young developers have C phobia and somehow seem not to be able to grasp C based languages.

andybak• 14 years ago

Or they've been spoiled by certain language features and it seems unbearable to go backwards.

frou_dh• 14 years ago

I like C but have Obj-C-aversion because "high level" languages that still need header files all over the place just ain't right.

jeremymcanally6• 14 years ago

I write code in both Ruby and Objective C pretty regularly, but man oh man is my Ruby code SO MUCH shorter and cleaner in a lot of respects. A lot of the Objective-C API's are just terribly terribly verbose. My favorite one to whine about is NSTask; it shouldn't take me 10 lines of code to spawn a simple external process. :P

For me, I prefer working in Ruby. Some people don't. But I think this will probably spurn me to get more serious about writing more iPhone apps, and it should open the door for a few more people who work on Ruby-based apps to write their own simple iPhone apps rather than paying a consultant to do it for them.

cageface2• 14 years ago

But you're going to be coding to those same Apis in ruby too, just with a lightly different syntax.

ScotterC2• 14 years ago

I could see this really taking off.

My worry is that it would take off so well that the ruby gem community could get fragmented into libraries for RubyMotion and libraries for regular ruby projects.

cheald2• 14 years ago

There are already exclusive libraries for MRI/JRuby, so adding a third platform doesn't seem like it would break the world. Tools like Bundler do a great job of keeping things moving smoothly.

ScotterC2• 14 years ago

Didn't realize bundler kept track of what ruby you were using.

jeremymcanally6• 14 years ago

I'm supposing that they will probably implement it as another platform option like you can do right now for JRuby/Windows/etc. It shouldn't affect much. I haven't looked at the documentation, though, so I can't say for sure.

hlidotbe5• 14 years ago

As mentioned above, CocoaPods will probably be used for this purpose as it is already the de-facto repository for MacRuby.

tommy_m• 14 years ago

Cool free 50 min video on RubyMotion -

http://pragmaticstudio.com/screencasts/rubymotion

vldo• 14 years ago

missing trial period so i'd rather wait for mobiruby

pjmlp4• 14 years ago

But mobiruby does not compile to native code, does it?

jballanc10• 14 years ago

The difference is that, as far as I can see, mobiruby is a Ruby interpreter/VM embedded in an Obj-C application. This is in contrast to MacRuby which is implemented directly on top of the Obj-C runtime. So, MobiRuby still has to go through the work of converting Ruby objects into Obj-C objects, whereas in MacRuby a Ruby object is an Obj-C object.

For a practical example of what this means, see the most recent sample code that was released for mobiruby: https://gist.github.com/2577620

octopus5• 14 years ago

This is huge from a programmer productivity perspective.

melvinram2• 14 years ago

Will apps created using this have any problems getting approved with App Store?

deedubaya2• 14 years ago

At the bottom of the features page

>RubyMotion is 100% compliant with Apple's App Store policies. Your code is compiled ahead-of-time, never interpreted, and you access the entire set of iOS public APIs. At the end, a RubyMotion app looks pretty much the same as an Objective-C app.

acangiano3• 14 years ago

No. From the FAQ (http://www.rubymotion.com/support/#faq):

"Applications submitted to the App Store must conform to the Review Guidelines dictated by Apple. RubyMotion implements a dialect of Ruby that conforms to those rules. RubyMotion apps are fully compiled, do not download or interpret code and are using public iOS APIs through the exact same machinery as regular Objective-C apps."

melvinram2• 14 years ago

Yay!!

fourgone• 14 years ago

I would rather see confirmation from Apple (doubtful) or developers who have successfully submitted apps to the App Store.

jwarzech• 14 years ago

I've played around with what seems like ever alternative framework under the sun (Titanium, Rhodes, PhoneGap, MonoTouch, Corona) and have been pretty frustrated with how clunky they usually feel. However with everything its claiming and the decent price point I'm toying with purchasing site unseen...just wish I could try it for a few hours first.

acangiano3• 14 years ago

Two suggestions:

1) http://arstechnica.com/business/news/2012/05/exclusive-build... (Review with code)

2) http://pragmaticstudio.com/screencasts/rubymotion (Screencast)

randomdata4• 14 years ago

MacRuby is probably a decent place to start. While it won't mirror a true RubyMotion environment, it should be close enough to get a feel for what you're in for.

instakill• 14 years ago

Are there any example apps in the wild that were made using RubyMotion?

jamesjn• 14 years ago

There's a few example rubymotion apps at: https://github.com/HipByte/RubyMotionSamples

I find them really easy to follow.

sjtgraham• 14 years ago

I don't see the point of this. Objective-C is not hard to learn, and with ARC, blocks, the new literals for NSArray and NSDictionary, etc, Objective-C has actually become pleasant to write IMO. The example RubyMotion code also doesn't look very nice either.

The problem with Rubyists (being one for the past 6 years I feel qualified to say this) is in general they want to use Ruby for everything. It's not always the best tool for the job.

heretohelp2• 14 years ago

>problem with Rubyists...want to use Ruby for everything

This is generally true of the Java community as well. There was a solid decade where there was a jSomethingOrOther for everything in development.

Kudos• 14 years ago

Now that typically means it's a jQuery plugin ;)

maercsrats• 14 years ago

In reference to your first paragraph, that's all your opinion. You are completely entitled to it and I respect it. My opinion is that this looks awesome and I really want to try it out. Especially since I know Ruby (and C) but I don't know any Obj-C.

As for your second paragraph, you can say that about any '-ists'. I've met java, python and .Net people who all love their respective languages and just want to code in that. To me, Rubyists aren't better or worse in that respect.

38leinad• 14 years ago

totally agree with you. just for your statement "I really want to try it out. Especially since I know Ruby (and C) but I don't know any Obj-C.": Would be interesting to really know what is the steeper/longer part of the learning curve: learning ObjC or learning the frameworks. To me, ObjC is a lean language (with an awful bracket syntax just like lisp) but learning the ins and outs of the frameworks is what took me the most time.

randomdata4• 14 years ago

Especially since I know Ruby (and C) but I don't know any Obj-C.

Interestingly, from my point of view, Obj-C made perfect sense to me when I realized that it was basically Ruby with C syntax. Given the heritage of Ruby and Obj-C, they come out as very similar languages, so I found it a breeze to pick up the other.

The hard part was learning the Cocoa (Touch) frameworks, but I'm not sure a Ruby API would have made that any easier. It's simply a massive amount of information to take in all at once.

Smudge• 14 years ago

> Objective-C has actually become pleasant to write IMO.

Yeah, well, you know, that's just, like, your opinion, man.

Flow• 14 years ago

Haven't you heard? New shit has come to light man.

thibaut_barrere2• 14 years ago

I use Ruby since 2004 (but not exclusively).

I've been using Ruby to create pleasant to use APIs around more complicated (native) APIs in both Java and .Net and it has always been a very big win in my situations.

I just bought a RubyMotion license and can see it going very far :)

phillmv• 14 years ago

> Rubyists in general want to use Ruby for everything.

Well… why not?

This is a relatively objective statement; the problem with ruby tends to be the crappy interpreter we're forced to suffer through - not the language itself. The Ruby language, in my biased opinion, as far as OO-functional languages go is pure awesome.

My initial reaction was: "A Ruby to Obj-C ABI compiler? Fuck no, what is wrong with you."

Upon learning it was the MacRuby dude: "Holy shit fuck yes".

I really don't want to ditch my entire development workflow to pick up Xcode, and Objective C, and miss out on all of the development libraries and vibrant community that I already have access to.

The problem with company led development environments is that they're tailored to the vendor's, and not the community's, needs. Development is rigid and low on innovation.

If this framework is half as good as it seems to be, within a month we'll see a dozen libraries that abstract all sorts of pain away from iOS development. Abstracting the pain away is something the Ruby community tends to do well.

I've gone from being totally uninterested in iOS development to being excited in what I can do inside UIWebviews. Naive, maybe, but it's probably significantly lowered the amount of investment I have to make into creating an iOS app.

deeds• 14 years ago

> Upon learning it was the MacRuby dude: "Holy shit fuck yes".

Couldn't have said it better myself.

55pts2• 14 years ago

I like ruby but please, do not call it a functional language. Its not even remotely close.

bphogan• 14 years ago

In much the same way as JavaScript developers want to do everything in JavaScript, including write mobile apps (PhoneGap/Titanium) and server-side apps (Node.js).

Learning is hard, and doubly so when you're in your comfort zone. You can deride that and make it about a person's "toughness" as a programmer, or you can think about exactly how much time it takes to learn a language and its idioms, highlights, lowlights, problems, and features.

A person who's really good at C# or Java is not going to be really good at Obj-C without losing a significant amount of time. That's why these kinds of projects appear. There's only so much time in the day to learn a new language well. :)

tolmasky• 14 years ago

I've never understood this logic: The existence of this project is not an attack on Objective-C. Objective-C is not hard to learn and awesome, I agree. But what does that have to do with providing an alternative? There can exist multiple good solutions to one problem. You said it yourself: Ruby is not always the best tool for the job, perhaps Objective-C is also not always the best tool for the job. Perhaps the use of UIKit through Ruby will provide interesting insights that will later be used to make Objective-C better: all the Objective-C 2.0 additions (including the ones you mention) were certainly a response to modern languages that made a lot of things easier for programmers.

As an Objective-C programmer myself, I was initially really turned off by this attitude from the JavaScript community: (Why do we need we need a LISP implementation in JS? It's already a functional language! Why do we need Objective-J? JS already kind of has classes!). Hilariously enough, the only language that was "accepted" by the JS community was the one that specifically promised that it wouldn't add any new features: CoffeeScript. I missed the Objective-C community precisely because I had always found it quite unreligious and practical: to each his own when it comes to development -- I hope that with its latest success it hasn't become more dogmatic and insular.

nupark29• 14 years ago

I am personally concerned that the Rubyists will flood the iOS development space, bringing their culture and introducing a dogmatic and insular environment.

We already have -- and without great fanfare -- Lua, JavaScript, C# (MonoTouch), et al. This seems somehow different.

sassafras3• 14 years ago

I can't speak for the parent, but my take on it is that Ruby is considerably slower than Objective-C and one of the slower scripting languages in common use, IIRC. I wouldn't go out on a limb and suggest that it's unsuitable for iOS development without having a chance to see it myself, but it's something to keep in mind.

As I'm sure you've seen, even Objective-C is too slow for many things when developing for iOS - for instance, if you want to get halfway decent UITableView performance it's best to write a custom UIView where instead of laying out nested subviews, you drop into C and do all your layout in drawRect using only CoreGraphics API calls.

If you're attempting to do anything more complicated than hooking together pre-fab components, your performance is probably going to suck if your views are written in Ruby. And it's the silky smooth graphics people have come to expect that give iOS the reputation it's earned for slick UI.

It doesn't mean you shouldn't necessarily use a framework like this, but you don't get all that convenience for free. I've often felt that the reason Objective-C remains in use (aside from the fact that it's kept alive by Apple) is that it sits in a really practical middle ground between the bare metal performance of C and the convenience (and tradeoffs) of "nicer" languages. As I said above, though, this is just my default reaction, and I'd love to see this stuff in action if it's truly usable for a reasonable subset of use cases.

jballanc10• 14 years ago

Objective-C's heritage as a strict superset of C means that it's great for doing high-level stuff while still keeping your hands in the low-level (necessary when performance becomes a main concern).

Objective-C's heritage as a strict superset of C means that, ultimately, it's syntax is limited (why do you think all the new literal forms are prefixed with "@"). Ruby, on the other hand, excelles at constructing DSLs.

I think you'll find that this strength of Ruby will make RubyMotion a compelling solution for a wide range of tasks in iOS development. That said, CocoaPod support is built in, so you really can have the best of both worlds.

chc11• 14 years ago

I already know both languages — in fact, I've known Objective-C for 10 years and Ruby for only six — and I still see some reasons why this is interesting.

Anecdote: When ARC was first released, I decided to turn it on for a small project. The very first method I wrote blew up with a memory error. The reason? I used the NSFontMatrixAttribute of NSFontDescriptor. For some reason, ARC doesn't handle it correctly. I've never had such a thing happen in Ruby.

There is still a long way to go from where Objective-C is. It's moving in the right direction, but there's still a long road ahead of it. Ruby is closer to being there, though the lack of tool support (particularly autocomplete) makes it a much less compelling proposition than it would otherwise be.

Also, Ruby can be considerably easier than Objective-C to read because there is a lot less line noise. Objective-C's method names read very smoothly out loud, but they can also be visually overwhelming at times and make code sort of melt together into a wall of text. It's maybe a little bit easier to read Objective-C quickly when you're being very deliberate about it, but it's much easier to skim Ruby in my experience.

I probably won't be using this, and I think your criticism of Rubyists is kind of valid, but I think — for this particular project — you're dismissing it too readily.

exim• 14 years ago

I agree, language itself is not a problem. It is iOS API that matters (or needs to be fixed, in context of this thread).

Actually, I can say the same regarding Java/Android API correlation.

coffee6• 14 years ago

Speed is what you're missing.

Not to denigrate you or your statement, and yes Objective-C is not that hard to learn, but it comes down to speed.

If I've never programmed in Objective-C and if I'm experienced in Ruby my time from concept to live iPhone app can be FAR quicker by using the tools/language I'm already familiar with (regardless of which tools/language).

Remove the concept of learning a new language, a new IDE, and only require that I learn a new lib to work against and I'm FAR quicker.

Yes, there may be some limitations. But this is iterative development. Build something as solid and quick as possible, and give users the chance to play with it. If it works, and you need more flexibility, it's reasonable to spend the time on learning new tools/languages.

chc11• 14 years ago

Compared to learning Cocoa (Touch), Objective-C is really nothing — especially since to use MacRuby you have to learn a bunch of kinda-awkward hacks they've stuck on top of Ruby to make it compatible with Objective-C (e.g. the "def foo(bar, baz:quux)" syntax and Pointers). It's a very simple language. Unless you are exceptionally bad at learning syntax, you're really not saving yourself a whole lot of time.

spacemanaki3• 14 years ago

Forgive my ignorance of iOS, but do the current Objective-C based tools deliver "An interactive shell [...] for introspection, live coding and debugging" ? If RubyMotion can actually deliver a real first-class REPL that works, that would be a pretty huge deal. Lack of a REPL is the biggest reason why I dislike mobile (Android) development.

malyk3• 14 years ago

No, it doesn't, and it is the thing that I miss the most going from Ruby to Obj-C. All of the other benefits of ruby over obj-c are great, but it's the interactive shell that is the highlight of RubyMotion to me.

jawngee4• 14 years ago

Yes, it's called GDB or LLDB, depending on your compiler. Not live coding though, but I don't know if that's a big deal.

jbrechtel2• 14 years ago

What are you looking for with an Android REPL? Asking because this is something I might be interested in building. Feel free to take the conversation to email (@gmail) or twitter (@jbrechtel) if you'd rather limit the off-topic discussion.

aiscott2• 14 years ago

For me, the REPL is the key that makes this interesting. I don't really know much ruby, but I would consider picking it up again just for the interactivity you get with a REPL tied to the app running in the simulator.

This is a step in the right direction, a step toward getting immediate and interactive results when you code.

The piece that I find a tiny bit lacking is disconnect between what you futz with in the REPL and what is your source. By that I mean, all the manual tinkering in the REPL isn't saved anywhere, you have to copy and paste.

Emacs rectifies this sort of thing a little with swank and slime. Maybe there will be a mode for RubyMotion.

tubbo• 14 years ago

Objective-C sucks as a language. It's just awful to look at, isn't really that much more efficient than C++ or even C itself, and realistically the only reason we use it in the first place is because it's the language of iOS.

Sure, it's not hard to learn. But in my spare time, am I really going to work with a language I can't stand to make my iPhone app or am I just going to want to make a web app in Ruby? The latter sounds a lot more fun, but the former is obviously more efficient. The fact that we can now combine both? Holy shit.

fleitz• 14 years ago

It might not be the best but it's good enough. Most of the heavy lifting GUI code is still in Obj-C, it's just going to be hitting ruby for microseconds.

Sure if you're writing the unreal engine it's not going to be the best idea, but it should do fine for a Facebook/Three20 type app.

seclorum• 14 years ago

The point is that compared to Ruby, Objective-C is just aging, bloated, and incomprehensibly loaded with special traps designed to keep you wedded to the platform.

Ruby skills: applicable across a very broad range of computing devices. Objective-C: not so much.

edwardtrunk• 14 years ago

a big different is, now the ruby eco-system is in play. the ability to write DSLs to further enhance the development effort.

toisanji• 14 years ago

How does memory management work with ruby and iOS? I did not find the information on the website.

acangiano3• 14 years ago

From the Features:

"It's Ruby, you don't need to think about managing memory. Ever. RubyMotion will by itself release the objects you create when they are no longer needed. Our memory model, similar to Objective-C ARC in design, does not require any extra memory or processor footprint to allocate and reclaim unused objects."

webjprgm• 14 years ago

I still wonder how they did that. The classic problem with reference counting is correctly releasing cycles, which ARC handles by allowing "weak" references. How does MacRuby know when to insert a weak reference as opposed to the usual "strong" reference? If that could be automatically detected, why does Obj-C ARC not automatically do it for you?

zbowling• 14 years ago

Part of me is happy. Apple pushed MacRuby before Lion and effectively killed it internally going forward after the ARC announcement. MacRuby relies on the GC capability of Objective-C which is incompatible with their new ARC baby. Just a few days ago I wanted to take a backend framework we wrote and build a command line tool to call some of it's methods in MacRuby (lots of command line parsing and Ruby has good facilities for that) but forgot we converted that framework to ARC. No dice.

This looks promising but at the same time I really wish the backend compiler was open sourced and worked on Mac and not just iOS.

hlidotbe5• 14 years ago

Since Laurent Sansonetti is the author of MacRuby AND RubyMotion, he already said feature from RM will be backported (and hence open-sourced) to MacRuby

jballanc10• 14 years ago

I'll simply point you at Laurent's email to the MacRuby-devel mailing list about a month ago. I think re-reading it in light of today's announcement could be...informative ;-)

http://lists.macosforge.org/pipermail/macruby-devel/2012-Apr...

thought_alarm• 14 years ago

It doesn't sound like they're using ObjC garbage collection, which I do not think would be available in iOS anyway:

"Our memory model, similar to Objective-C ARC in design, does not require any extra memory or processor footprint to allocate and reclaim unused objects"

e28eta• 14 years ago

The most exciting part of this for me is the automation and integration with Apple's tools.

For instance, built-in TestFlight rake task, or build and run on device/simulator. I'd love to borrow some of that for a CI build system (which for me is currently a large shell script that could be improved on).

I'm also very interested by the interactive REPL that can run code inside my application. LLDB is good, but falls short for me occasionally.

bherms2• 14 years ago

Just a note, not sure if this is intentional, but the audio on the video is in stereo, but with no right channel.

edit: also, please stop the heavy breathing into the mic. Driving me crazy!! :)

SeoxyS• 14 years ago

I could not watch the video (on headphones) because it is physically painful to do so. That's a HUGE problem.

bherms2• 14 years ago

Exactly.

octopus5• 14 years ago

A suggestion for Laurent Sansonetti will be to release this similarly with the way Xamarin has released Mono for iOS. Basically you should be able to download and use the library for free in the iPhone/iPad simulator and you will need to buy a license if you want to be able to export the app to the actual device. This licensing model has the advantage that is similar with what Apple does for developing apps for iOS.

This will let you, as a developer, try and learn to use RubyMotion before you actually buy a license.

grey-area4• 14 years ago

I'd second this suggestion. I love the idea of using ruby on ios, this looks like a womderful solution, and it looks far more rubyish in syntax than Mobiruby (which isn't there yet anyway), but I would really like to try it out for myself in the simulator and develop a few simple apps before deciding whether I would want to use it professionally. If they could limit it to simulator only for free it would be much easier to tell if it is going to be really useful or more painful than just putting up with obj c. Having a demo might even boost adoption.

A question for the developers - did you consider this option and reject it for some reason?

daemonza• 14 years ago

2nd this, that would be awesome. I am very tempted to give Rubymotion a try, but not sure I am ready at the moment to shell out the cash for it.

anuraj• 14 years ago

Problem in search for a solution? Apple is walled garden - provides the best integrated IDE for iphone development that is a pleasure to use. Language is just a small part of the puzzle. For each task, the best suited environment and language. There is no panacea.

smoody• 14 years ago

"At the end, a RubyMotion app looks pretty much the same as an Objective-C app." ( from bottom of: http://www.rubymotion.com/features/ ).

pretty much the same as an Objective-C app? Anyone have any clue as to why they didn't state apps in the two languages would look identical?

cschneid• 14 years ago

Different compilers will generate different compiled code, even on identical input (ie, clang vs. GCC). So the binary will be different.

elsurudo3• 14 years ago

I think he's commenting on why they wouldn't LOOK identical, as in UI.

UI is a finicky thing, but assuming this allows you to use all Apple APIs, there is no reason you couldn't get an identical-looking UI using this.

sunjain• 14 years ago

Now there is an alternative to Objective-C in iOS development(for Rubyists). This is similar to development of Coffescript. There is nothing wrong with Objective-C, it is just that folks who prefer the elegance and beauty of Ruby have an option. I think this will be great combination - beautiful & elegant language for creating apps on a beautiful platform.

jballanc10• 14 years ago

Be sure not to miss all the sample code: https://github.com/HipByte/RubyMotionSamples

In particular, for those looking for a side-by-side comparison of what it means to use Ruby instead of Obj-C, be sure to check out the GestureTable sample: https://github.com/HipByte/RubyMotionSamples/tree/master/Ges... which was based on the JTGestureBasdeTableView: https://github.com/mystcolor/JTGestureBasedTableViewDemo

typicalrunt• 14 years ago

What's with the price difference between Canada and US orders? It's CAD$152.82 versus US$149.99.

With the Canadian dollar currently worth about 1 cent more than the US, I'm surprised to see that there is a price difference at all.

jamie_ca• 14 years ago

The nominal exchange rate you see has only a passing resemblance to exchange rates charged by CC processors.

tlear• 14 years ago

No interface builder? Depending on what type of apps you make it can be a big issue I think

malyk3• 14 years ago

The problem with interface builder is that it only exposes some properties and others you have to set in your class anyway. Why can't I set the background image of a view in interface builder, for instance?

With RubyMotion you get to roughly lay out your controls, and then you get to use the interactive interpreter for fine-grained adjustments. See around the 5:30 mark in the getting started video for an example.

guynamedloren• 14 years ago

> RubyMotion is built on top of iOS. You have access to the entire set of public iOS APIs and can also use 3rd-party Objective-C libraries or Gems

So this should be compatible with cocos2d right?

octopus5• 14 years ago

cocos2d is writen in Objective-C so in principle it should be compatible with RubyMotion. Not so sure about the ARC integration (last time I've checked cocos2d was only "ARC compatible"). I've seen some work arounds using a cocos2d as a static library (no ARC enabled) linked with a main Objective-C application that uses ARC. It should work ... but I can't give you a final answer.

zealog• 14 years ago

There is already an example project on Github using Cocos2d in a RubyMotion app. https://github.com/anydiem/cocosmotion

robomartin2• 14 years ago

I am not criticizing. This is a perfectly neutral question:

Isn't the issue with a lot of these "look Ma, no Objective-C" approaches in that there are always little nagging issues here and there?

I mean, Apple is constantly moving Objective-C/Xcode/iOS (notice I didn't say "forward"). Isn't it somewhat dangerous to adopt peripheral approaches for development rather than staying (suffering?) with the Apple-provided tools?

Now, if someone has an alternative IDE that truly allows me to record Xcode to a DVD and perform a ritual burning ceremony of said DVD...that would be something.

aiscott2• 14 years ago

I said this in another reply, but I'll reiterate here. It's not the lack of Objective-C that is the big deal here. Afterall you are still interfacing with cocoa, and are stuck with a lot of the verbosity in doing that.

The real key to this is the REPL and interactivity between coding and the running app. Being able to edit bits of functionality and structure in the running app, and immediately see the results is AWESOME!

robomartin2• 14 years ago

I don't know Ruby. Therefore, by my own admission, this comes out of complete ignorance.

I am currently working on a project that uses a genetic solver and some fairly complex state machines driven by fairly involved databases. I can't possibly see how something like this could be made to be interactive in terms of the development process. Generally speaking you are writing a lot of code before you get to compile and see the results. And, personally, I don't have any issues with the compilation process.

What do you mean by "interactive"?

jballanc10• 14 years ago

What you have to keep in mind is that RubyMotion is not "just another wrapper". It is actually implemented on top of the Obj-C runtime. So that means Apple would have to make breaking changes to the runtime (the thing documented here: https://developer.apple.com/library/mac/#documentation/Cocoa...) in order to break RubyMotion.

pepijndevos• 14 years ago

I thought Flash got in trouble for targeting iOS with something not originally written in JS or ObjC, is that still true?

hemancuso• 14 years ago

Anyone know if this comes with the ruby stdlib?

dmarkow• 14 years ago

It doesn't look like it. You need to use the iOS alternatives (in this case, NSDate).

  (main)>> require 'date'
  => #<RuntimeError: #require is not supported in RubyMotion>
  (main)>> Date
  => #<NameError: uninitialized constant Date>

drpancake• 14 years ago

From the screencast it looks like they altered Ruby syntax by adding named parameters to conform with Obj-C's way of specifying prototypes. I guess this is a trade-off for the fact that Obj-C has some unusual syntax that has no real analog in Ruby -- if you've ever tried developing with PyObjC you'll be familiar with how odd it looks.

shapeshed• 14 years ago

There's a reasonably new language called HTML that is a good development platform too. Works on all devices.

d1egoaz• 14 years ago

michael_f• 14 years ago

"Good" and "Works" being relative terms, of course. YMMV, especially amongst devices in the installed base where web views aren't GPU-backed (e.g, on one common platform, that being the vast majority).

riffraff• 14 years ago

anybody understood what rubymotion offers over the standard macruby? edit: got it, static compile and no gc

TheSmoke• 14 years ago

so, we need a mac for this. right?

wmboy• 14 years ago

Yes... "You will need a Mac running OSX 10.6 or higher."

- http://www.rubymotion.com/support/#faq

jstepien• 14 years ago

At the very beginning of the presentation he underlines the importance of the static compiler RubyMotion is based on, yet at 7:30 when he compiles a file with a name error in it the compiler doesn't even file a warning. Such non-existent methods and other similar errors should be caught at compile time if we're talking about solid AOT compilation.

freditup2• 14 years ago

My thoughts: "Hey! This looks pretty neat. Oh it's $150 on sale, forget this. Oh it's only for macs, glad I never bought this piece of garbage."

That being said, it could be great, I have no idea.

chc11• 14 years ago

The iOS SDK itself is only for Macs. It seems like a reasonable requirement for something that depends on the SDK to run on the same platform.

danssig• 14 years ago

I think you've clicked on the wrong site. Digg/Myspace is --------------> that way.

lectrick3• 14 years ago

Maybe that's because Macs don't generally deal with pieces of garbage. Whether that's tools, or users.

freditup2• 14 years ago

If you really think one platform is so superior to another, you're missing the point entirely.

derekorgan• 14 years ago

Looks very promising. I love Ruby and I initially hated Objective-C but I have to admit now I find it very powerful. The biggest missing link here seems to be the Storyboard. Its a really nice option in xCode. Have I missed something, how are layouts defined separately from code?

stephth• 14 years ago

I love writing Ruby code, but today I'm finally at a point where I also feel happy and productive with Objective-C. What made my eyes bulge is this:

http://www.rubymotion.com/developer-center/guides/project-ma...

No XCode. Instead of obscure and impenetrable project files, a convention over configuration Rakefile. Clean and Ruby-like workflows and repositories.

While you can certainly configure an Xcode workspace to program in RubyMotion, we do not provide any support for Xcode out-of-the-box. We do not believe that Xcode makes a good environment for Ruby development (or development in general). Ruby also makes it very easy to write great Domain-Specific Languages that can be used as elegant alternatives to graphical user interface or data modeling tools. [1]

Laurent Sansonetti gets it. I've been writing iOS code for three years and have never been able to figure out how to have a frictionless workflow around XCode, everything about it is convoluted. The idea of automating frequent development tasks with Ruby generators and DSLs sounds exciting and promising.

[1] http://www.rubymotion.com/support/#faq

petercooper5• 14 years ago

Which makes me wonder.. is it possible to rig up such an environment for standard Objective C iOS app development? It could be huge.

Zev4• 14 years ago

Do Makefiles count? Xcode project are largely (not so) shiny wrappers around Makefiles and keeping track of files.

GreySyntax• 14 years ago

For writing iOS apps I tend to use the THEOS makefile framework by DHowett gives you fine grained control over everything :)

lobster_johnson• 14 years ago

It's entirely possible to use Make (or whatever you want) to build a project. There's no magic to Xcode. You just need to invoke to correct compiler and linker (Apple's GCC, usually), include the right flags and frameworks for them, and probably invoke some Apple tools for things like code-signing.

equalarrow• 14 years ago

At first glance, I was skeptical of this. I was immediately thinking "jesus, wtf? yet another way people want to avoid Obj-C?". But last night I decided to take the plunge, bought a license and played around with it.

I dabbled in Obj-C over the years and jumped on the iOS dev bandwagon as soon as the first SDK was available. It was a long journey and coming from Ruby, I was very resistant. Once you're used to succinct syntax, it's really hard to use something as wordy as Obj-C (this was the main reason I never went back to Java). But over the years I came to appreciate Obj-C. I loved the speed and I clearly knew mobile was gonna be the next real fun thing to work on.

And that's where I've been the past 4 years, iOS land. I'm pretty comfortable now with Obj-C and the iOS framework and have worked on a number of projects in the app store. I can really say that I've seen all levels of crappy to great code. But last night when I went thru the samples of the Ruby Motion stuff, I was a little flabbergasted. I'm (now) so used to XCode code completing long method names and when I saw the Ruby equivalent and how condensed everything was, it kinda blew my mind again. I found myself thinking "whoa, that's right, there's no interfaces" when looking at the accessors (omg, so much less code vs. using typical ivar properties) and just all these little Rubyisms that I'm not used to seeing with iOS. It totally made me smile. Oh yah and blocks! They're, like, readable again. :)

Anyway, just to play around with the examples (which are pretty decent) was worth the intro price for me (I can expense it anyway). One big thing that does not yet exist is IB support. A few years back I switched to IB 100% (when possible) and so I'd much rather lay out my ui vs. code it all up. I've included a good Ars link below and in it Sansonetti says they're coming out with a DSL for easily laying out the ui. That will be interesting and it could push me over the edge for using this on a real project. Time will tell.

I kinda feel like I felt the first time I saw Rails. I would recommend anyone remotely interested just check out the Github demos.

http://arstechnica.com/business/news/2012/05/exclusive-build...

daniel_sim• 14 years ago

Should make for some good bridge FU on hypercritical this week...

jgavris• 14 years ago

I don't understand all the hate for Objective-C, and at the same time love for Ruby. Objective-C is far easier to read, with named parameters and types everywhere. Ruby is often so minimal that you need to interpret the whole program yourself to understand what's going on...

sthulbourn• 14 years ago

It's nice, I'm new to using ruby (I've been an iOS dev for a while now), I'd give it ago.

But I assume it uses storyboards in the same way as ObjC, set it in the target and in the Info.plist, and it figures it out... it'd be nice to see it working though.

botj• 14 years ago

I second this.

EternalFury• 14 years ago

I'll say this again: No programming language is fundamentally bad.

Bad programmers have a tendency to move from language to language, blaming their tools for their lack of skill.

This stuff is exciting.

jbrechtel2• 14 years ago

I wholeheartedly disagree. There are bad programming languages. Brainfuck is a good example. I don't mean that as a joke, but only as proof that programming languages can be objectively bad. As an extension of that I'd say that languages can be bad because of their constituent parts (syntax, semantics, constructs, features or lack of, etc..).

Some languages have constituent parts that I'd say are objectively bad. I'll argue all day that Objective-C's handling of nil is stupid beyond belief. Nil/Null itself is bad enough...

davidrupp• 14 years ago

Purchased. Good job, @lrz. Glad to know your departure from Apple and (apparent) distancing from MacRuby were in a good cause.

superalloy• 14 years ago

He did not distance himself from MacRuby, though: http://lists.macosforge.org/pipermail/macruby-devel/2012-Apr...

damian2000• 14 years ago

Sounds awesome - gives me another reason to buy a Mac.

christiangenco3• 14 years ago

I love this. It looks like exactly what I've been looking for since the iPhone SDK was first announced. I've been a web/RoR developer since high school but could never find the motivation to get used to all of Objective C/XCode's quirks. I've tried everything from PhoneGap to Appcelerator to mimicking native feel in a browser, but it was never enough. This is perfect.

But quite frankly, I can't afford it. I'm a college student living on $25/week for food - I can't justify spending 6 weeks of food on an experiment.

If I could try it out? If I could build my killer app first and know that it works? It wouldn't hurt as much, but $150 is still a lot of money.

Zev4• 14 years ago

But you could justify spending 4 weeks food on an experiment? Because you'll need that $100 to put an app on your device, as well.

christiangenco3• 14 years ago

Ahh yes, that's not particularly fun either.

89a• 14 years ago

If you'd sat down and spent all that time on Obj-C you'd be coding away at it by now.

Sometimes searching for an easy way out is a waste of time.

christiangenco3• 14 years ago

Fair point.

ef4• 14 years ago

What annoys the crap out of me isn't objective C, it's XCode.

This looks worth it just to have an XCode-free toolchain.

funkyboy• 14 years ago

I am wondering is anybody asked for a debugger/stepper. Will a dev survive without those? Also, are you ready to write all the code behind xibs?

dmitryso• 14 years ago

I don't remember the last time I was excited about some new technology, but rubymotion is a thing I was looking for since the release of iOS SDK. I was doing ruby for 5 years, and switched to iOS/ObjC half a year ago, and I still can't stand the Objective-C syntax.

cm_richards• 14 years ago

Ruby :

"The limits of my language define the limits of my world" if string =~ /foobar(\d\w)/#

Objective-C :

  NSError *error = NULL;
  NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"foobar(\\d*\\w)"
  options:NSRegularExpressionCaseInsensitive error:&error];
  NSTextCheckingResult *match = [regex firstMatchInString:string
                                                options:0
                                                   range:NSMakeRange(0, [string length])];
  if (match) {
    NSLog(@"The limits of my language define the limits of my world - Wittgenstein")
  }

Enough said?

Reply

RubyMotion - Ruby for iOS

Related Stories