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]];

  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],
  }];

  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
  })

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];

I'm a Rubyist, it's my primary language and I'd love to use it over Objective-c. But I'm also starting really like Obj-c, and right now it's the best thing out there for iOS because of XCode.

If you want to learn how to make iOS apps, learn Objective-c. Or at the very least learn it first. Trust me, you'll be glad you did.

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
  )
 

(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)

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.

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

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

Was about 45 key presses in Xcode. And this is a fairly short method, take something like animating a view with a block and you're looking at way more typing to do it in Ruby Motion.

http://youtrack.jetbrains.com/issue/RUBY-11039#tab=Comments

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...

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

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

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...

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).

-- EDIT --

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

I can edit the ruby files in vim and then just run the rake task to open up the simulator to test the changes I just made.

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.

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.

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.