

A review of RubyMotion - mdemerson
http://samsoff.es/posts/rubymotion-review

======
kenferry
One of the ObjC examples could be more concise. He writes:

    
    
      id navigationBar = [UINavigationBar appearance];
      [navigationBar setBackgroundImage:[UIImage imageNamed:@"nav-background.png"] forBarMetrics:UIBarMetricsDefault];
      [navigationBar setTitleTextAttributes:[[NSDictionary alloc] initWithObjectsAndKeys:
        [UIFont cheddarFontWithSize:24.0f], UITextAttributeFont,
        [UIColor colorWithWhite:0.0f alpha:0.4f], UITextAttributeTextShadowColor,
        [UIColor whiteColor], UITextAttributeTextColor,
        nil]];
    

which could be

    
    
      id navigationBar = [UINavigationBar appearance];
      [navigationBar setBackgroundImage:[UIImage imageNamed:@"nav-background.png"] forBarMetrics:UIBarMetricsDefault];
      [navigationBar setTitleTextAttributes:@{
        UITextAttributeFont : [UIFont cheddarFontWithSize:24],
        UITextAttributeTextShadowColor : [UIColor colorWithWhite:0 alpha:0.4],
        UITextAttributeTextColor : [UIColor whiteColor],
      }];
    

as compares to the Ruby,

    
    
      navigationBar = UINavigationBar.appearance
      navigationBar.setBackgroundImage(UIImage.imageNamed('nav-background.png'), forBarMetrics: UIBarMetricsDefault)
      navigationBar.setTitleTextAttributes({
        UITextAttributeFont: UIFont.cheddarFontWithSize(24.0),
        UITextAttributeTextShadowColor: UIColor.colorWithWhite(0.0, alpha:0.4),
        UITextAttributeTextColor: UIColor.whiteColor
      })
    

Also kind of wondering where he got "cheddarFont". :-)

~~~
barrym
I didn't know about the new @{} syntax for dictionaries -
[http://blog.ablepear.com/2012/02/something-wonderful-new-
obj...](http://blog.ablepear.com/2012/02/something-wonderful-new-
objective-c.html) \- very nice.

~~~
samsoffes
You can't use that unless you're running Mountain Lion and you can only submit
apps to the store with a released version of Xcode. The new syntax is amazing
though!

------
ricksta
Objective C classes and methods are designed to be long and mostly typed by
Xcode's autocomplete. With RubyMotion, I will end up typing out all those
verbose methods, which I don't know if it's something I feel too big about.

The example author made here feels like I will end up typing about twice as
much with RubyMotion than objective C.

Ruby: @window = UIWindow.alloc.initWithFrame(UIScreen.mainScreen.bounds)
@window.makeKeyAndVisible

Objective C: self.window = [[UIWindow alloc] initWithFrame:[[UIScreen
mainScreen] bounds]]; [self.window makeKeyAndVisible];

~~~
subwindow
The real benefit with Ruby is the creation of DSLs that make working with
these UI elements much easier.

It's only a matter of time before someone creates a DSL that looks something
like:

    
    
      window = screen.main.new_window(
        frame: true,
        key: true,
        visible: true
      )
     

Or something like that. I'm not an iOS developer, so I'm not really sure what
parts of the insanely-verbose method calls are actually necessary.

(As an aside, I have Vim rigged up to do autocompletion with Ruby. I'm sure it
would work with these Cocoa libraries as well)

~~~
stcredzero
_I'm not an iOS developer, so I'm not really sure what parts of the insanely-
verbose method calls are actually necessary._

It's called "Intention Revealing Names." Names are long to provide the
programmer information, so shortening them would have a negative impact.

 _As an aside, I have Vim rigged up to do autocompletion with Ruby. I'm sure
it would work with these Cocoa libraries as well_

If someone writes the necessary plumbing.

~~~
286c8cb04bda
Somebody already did once[1], though it's gotten a bit out-of-date. It needs
to be manually revised every time a new SDK comes out, so it's going to keep
falling out-of-date.

[1]: <http://www.vim.org/scripts/script.php?script_id=2674>

------
EzGraphs
As someone who uses ruby for the sheer joy of it (and finds ObjC a bit
clunky), I want to be more excited about this. I am just not seeing the
benefit yet.

Ruby syntax is nice, not having autocomplete available is a problem,
especially since a good deal of time is spent figuring out the appropriate
calls to underlying libraries. Maybe this will be remedied in future releases.

I tend to like command line / REPL interactive development... but does this
really add any significant benefit when making iPhone Apps? I would imagine if
you have a lot of calculations or String manipulations involving non
GUI/device interaction this could be handy. But every actual test of code is
going to involve running rake and the emulator, which is not an advancement
from running make (by clicking a button in XCode) and the emulator.

Finally, what about running an interactive debugger or memory management
tools? XCode/ObjC has a number of benefits that eliminate some of the need to
be intimately acquainted with some of the underlying painful details. There is
not a lot of appear in trying to write an App in Ruby, backing out and
rewriting it in ObjC/XCode, and then porting it to Ruby.

Still, it was just released. Perhaps improvements in these areas will be
forthcoming in the future...

~~~
286c8cb04bda
_> I tend to like command line / REPL interactive development... but does this
really add any significant benefit when making iPhone Apps? I would imagine if
you have a lot of calculations or String manipulations involving non
GUI/device interaction this could be handy._

You could certainly us it for GUI interactions. Take the MacRuby equivalent
to:

    
    
        [[[[[[[UIApplication] sharedApplication] delegate] window] rootViewController] view]
    

That gets you the main view on screen, to which you could add or remove
elements at your pleasure.

~~~
EzGraphs
Thanks - that is a benefit.

------
Arcanum-XIII
It's not a real review — it's a guy having fun with a new toy, which is nice.
I'm still not more informed about the real advantages or disadvantage of this
solution, nor its speed... But to be honest, this soon, I wasn't expecting
much.

Still, as other, I'm perplexed with the difference. It all seem to boil down
to syntax (and I must confess I like the objective C one, it being my second
language after C) — and syntax is not that important, it's the concept behind.
XCode is not a good IDE, but not that bad for its purpose. Is there an
equivalent for Ruby, especially to debug the app ?

Alternative is good, but it need to add something to be really differentiated.
I'm not sure using ruby syntax is enought...

~~~
Argorak
The differentiator is the console-based development flow and the REPL, which
is not an afterthought but a prime feature.

The REPL is basically your debugger.

Also, while the Ruby stdlib is not running on rubymotion, I see a chance for
sharing Code between rubymotion/ruboto environments (ruboto is Jruby for
Android).

~~~
Arcanum-XIII
Does the REPL work on the live application ? Otherwise I'm not sure it's that
usefull — but I'm more of compiler/breakpoint guy at the moment so feel free
to prove me wrong !

\-- EDIT --

Ok, I've read the review from ArsTechnica, and yes you can do that. Now I'm
curious to try it !

~~~
jeremymcanally
Yup it does. There's a screencast on the Pragmatic Bookshelf site that shows
it off. You can change things live in the app (e.g., label text, state,
whatever). It's incredibly cool.

~~~
smartgoat
But you can already do that in gdb and lldb.

------
blt
What is the advantage? I'm neither an iOS or ruby developer, please enlighten
me. It seems like this gives you a different language syntax to access the
same libraries with no additional abstraction. It doesn't seem like it would
speed up development much.

~~~
anko
The interactive REPL looks fantastic. It's one of the things I love about
developing in ruby - you can try things without going through the compile or
even save/execute process. There is a lot to be said for a short/instant
feedback loop.

------
sthulbourn
The only clear win I can see from this is the REPL.

Everything else is down to preference... I'd rather write native Obj-C code,
but the guy next to me would rather write in ruby.

It's very subjective and down to coder preference, I can only hope that the
ruby world has a great work around for the very verbose selector names in the
iOS SDK; I was expecting some sort of wrapping for the iOS SDK to make it
simpler.

~~~
poutine
REPL seems to be a crutch for not having a visual interface builder. His
example in the video wouldn't have been an issue in Xcode as you'd have
positioned and named the label correctly to begin with, and would have seen it
in context too.

------
poutine
As a long time Ruby and Objective C developer who loves both languages I'm not
impressed.

Sure the REPL stuff is neat, but I would position my UI elements correctly in
interface builder to begin with. I'm also not keen on typing out the code to
assign properties that were done with the GUI before. There doesn't seem to be
any support for Storyboards which are awesome as segue transitions save a ton
of code that you'd normally have to type. Storyboards provide a visual layout
and ease of inserting steps in a flow or changing connections.

Once you have proficiency in Objective-C your coding method in XCode really
consists of typing 3-4 characters, hitting tab, a couple more characters, a
variable name and so forth. Code completion rocks and works quite well in
particular with Objective-C. I would expect all of the examples given there
would be many fewer keystrokes in Objective-C than Ruby.

I find the side by side code samples somewhat humorous. I expect to see
something like coffeescript to javascript which is visually obvious which one
is more concise. Instead I see roughly the same code expressed differently.
Sure Objective-C turns people off who don't know it, but once you do it's
really not a big deal.

Xcode also gives you great tools for refactoring code that due to the nature
of Ruby simply are not possible. This is pretty important for large projects.

The tough part of making non-trivial IOS apps is learning the API and the best
practices in using it. That can take months or even years.

------
vlucas
I took a look at RubyMotion and came away pretty disappointed. It seems like
the target market is for people who already write apps in Objective-C, but
want to write them in Ruby instead. The larger and more lucrative market is
for people who want to write apps without touching Objective-C at all or
knowing anything about it (i.e. using their existing knowledge of web
technology to write apps).

Compared to other abstraction frameworks on the market like Titanium, the
RubyMotion code is way too verbose and obtuse, and is really only obvious to
those who have already worked with Obj-C. On top of that, you don't get the
autocompletion and hinting because people don't typically write Ruby in IDEs.
I love the idea of using Ruby in this manner though, and hopefully people will
begin to build frameworks on top of RubyMotion so I can use it with a single
helper method call and a dictionary of options, like Titanium or a jQuery
plugin.

