Introducing ProMotion, a Full-Featured RubyMotion Application Framework | Hacker News Reader

Introducing ProMotion, a Full-Featured RubyMotion Application Framework

blog.rubymotion.com

84 pointsmarkrickert25 comments

I've never seen a better tool for rapid prototyping a working iOS app... and it plays nice with teacup, pixate, all the friends!

Reminds me somehow of Sinatra - e.g. Promotion : Cocoa :: Sinatra : Rails

Don't be modest...Motion-Xray[1] is a pretty awesome prototyping tool as well.

[1] https://github.com/colinta/motion-xray

"Sinatra for iOS dev" would literally be the answer to my dreams. I have a license for RubyMotion but havent had time to play with it. This looks very promising!

I'm on the fence about this and RubyMotion in general. By far the most time consuming part of app development is getting the visuals and animations looking right, and I don't see how this helps. The basic scaffolding (setting up view controllers, transitions and talking to the backend) is the easy bit.

On the other hand, I'm a Python guy and I've never fallen for Objective-C (although recent sugary additions have made it far more pleasant).

Can anyone who has made the jump enlighten me?

Visuals and animations are infinitely easier to get "looking right" when you can modify parameters directly in a running app via REPL. That's possible with RubyMotion. In particular, check out https://github.com/rubymotion/sugarcube#repl-view-adjustment... .

I second this. I demoed the Sugarcube repl for our mobile team (I'm primarily a JavaScript dev who has fallen in love with RM) and everyone was universally blown away. It's the most useful thing ever -- well that, combined with Teacup.

This looks like it could be the thing that tips me over into buying RubyMotion. Well done guys.

I hope this isn't Metrowerks CodeWarrior all over again. Hopefully, there won't develop a significant "underclass" of developers who simply won't venture away from the parts of iOS that haven't been given a "Ruby-like" facade. Right now, Apple has a wonderful situation where over 90% of the devs and users adopt the newest versions of the OS. They should hate to lose that.

(I am all for choice, though. I wish Apple had a way of "blessing" frameworks and languages that have automated and/or inherent ways of absorbing additions to iOS, and was specific about this.)

There's pretty much nothing you can do in Objective-C that you can't in RubyMotion.

RubyMotion exposes 100% of the Objective-C runtime with virtually no performance penalty. They are very on top of new iOS releases (released full iOS 6 support within a week).

In fact, I think that the RubyMotion community adopts new iOS technologies faster since it's new and doesn't have a lot of legacy code.

There is a significant difference between APIs that are named/structured in a Ruby-like way, and APIs that are named according to Objective-C/Smalltalk conventions. This can be a cause of significant pain. (For example, while refactoring, you have to search for all the ways a method could be called.)

RubyMotion is doing the right things. Much of the result also depends on community. It's a bad sign when supposedly smart programmers disdain a technology or a set of tech conventions simply because it's different. Especially when that tech has a great track record. It's really weird when they disdain the very thing they're building on. I've met some RubyMotion programmers like this, however. I hope they're just an aberration.

It would be great if Apple up and acquired RubyMotion. As it stands I'm hesitant to invest serious time in a system that isn't a first class citizen of the platform I'm building for, especially since there are things I actually like about Objective-C (despite coming from a Ruby and Python background).

I'm only a few days into using RubyMotion so I haven't formed a complete opinion yet, but my current concern is that I will end up becoming skilled at using a set of gems instead of becoming skilled at using the platform.

So, where I'm getting a bit confused is the difference between RubyMotion and MacRuby. I gather it's a superset of MacRuby functionality? Having a "stupid day".

I'm wanting (aiming toward needing) to learn Ruby but trying to justify the cost without actually knowing the language is a bit tough.

MacRuby is an implementation of Ruby 1.9 built on top of Cocoa. It's also OS X-only. See http://macruby.org

RubyMotion is fully compiled, and built on top of LLVM. See http://www.rubymotion.com/features/

They are both compiled and built on top of LLVM. RubyMotion is a fork of MacRuby, not a different design.

And as of last week, with the 2.0 release, you can now build desktop apps using RubyMotion as well. I kind of think that was the nail in the MacRuby coffin, for better or for worse.

RubyMotion is derived from MacRuby. MacRuby hasn't seen much development in some time, I would recommend investing your time in RubyMotion instead.

You can learn Ruby for free; you don't need RubyMotion or any other paid software for that.

FWIW there is a 30 day money back guarantee for Ruby Motion (which my company may make use of if we decide to stick with Objective-C).

I'm not following this at all. Justify the cost of what? There's no cost to learn Ruby.

He's talking about the cost of RubyMotion - $200

This is really awesome, so awesome that I'd like to pay for it!

https://www.gittip.com/jamonholmgren/

I know it is early days for RubyMotion's OSX development support, but I will ask anyway: anything like ProMotion for the OSX side of the house?

Trying it out now and it seems pretty awesome. Does anyone know of a great tutorial about connecting a new RubyMotion app to an existing ruby app?

Unfortunate choice of name: http://www.cosmigo.com/promotion/index.php

Different industries, full featured desktop application vs. a software library. Windows software sold as a package versus a free development library for iOS that only runs on Macs.

I don't see there being much trademark confusion here.

Reply on news.ycombinator.com