

On Why I Am Not Buying RubyMotion - funkyboy
http://www.upbeat.it/2012/05/08/on-why-i-am-not-buying-rubymotion/
I like Ruby and the way it is easy to work with. I personally use ruby in many projects, mostly on the server side. I am not a lover of Xcode. Yet, RubyMotion is not for me.
======
runjake
Objective-C isn't the hard part about iOS programming, it's fairly simple and
can be learned in a day by a programmer.

It's the frameworks that are hard, and you have to learn those using
RubyMotion anyway.

And not only that, but you have to rely on objc framework documentation and do
the translation to Ruby in your head. Too many wasted cycles, imho.

On the flip side, I like seeing experimental tools like this to promote new
ways of thinking and coding and it will inevitably foster new features into
the official SDK (ala blocks).

~~~
JackC
I think the potential of RubyMotion is in the "new ways of thinking and
coding" aspect you mention -- the big potential win here is to import a
Rubyish way of thinking about iOS programming.

I'm not part of either the ObjC or Ruby communities, but the impression I get
as an outsider is that Ruby is a language and coding culture obsessed with
elegant and minimalist expression, and ObjC doesn't make those things
priorities. So what I'm hoping to see come out of RubyMotion is an obsessive
drive to wrap the iOS frameworks in libraries that let you do the common
things with no code at all, and the uncommon things with the least code
possible. For people who have only worked in lower-level languages ... well,
the difference over time could be surprising. At least I'm hoping so.

To put it in practical terms: I bet if you follow the sample RubyMotion apps
over the next six months, you'll see the number of lines of code required to
do what they do plummet, replaced by high-level libraries. If I'm right, let's
get back together then and high-five. If not, oh well, it was a fun
experiment.

~~~
funkyboy
Like I said in the post, totally open to change my mind.

------
46Bit
> Whenever I see a third party tool I ask myself: how quickly it will be
> updated to the last SDK version? ... What will I tell to the client? “Oh
> look, we have to wait one week for technical reasons”. For every project I
> have taken on I have never had the guts to run such a risk.

Forget the rest of the article, this sums up why it's not for you.

~~~
colinta
Who is the "you" you're referring to? Me? I hope not, I'm really enjoying
RubyMotion.

Would I recommend it to a company that only does iOS development? heck no. How
about a RoR company that _wants_ to do some iOS development? Now we're
talking. If nothing else, I think it is a great way to learn the
Touch/Cocoa/Foundation frameworks without having Obj-C cruft get in the way of
having a good time.

~~~
46Bit
I don't know who you are, so I assume I'm not. I was referring to the writer
as I'd just quoted.

------
286c8cb04bda
_> ps2: How cool would it be to have a REPL console like the one in RubyMotion
on the Xcode console?_

You can!

Every time it comes up, I'm going to repeat this suggestion: Use Nu[1] as a
REPL for iOS[2] and OS X[3].

[1] <http://programming.nu>

[2] [http://groups.google.com/group/programming-
nu/browse_thread/...](http://groups.google.com/group/programming-
nu/browse_thread/thread/e8592ef8128245fd/68e83fa4a5306446?lnk=gst&q=#68e83fa4a5306446)

[3] <https://github.com/timburks/nu/blob/master/nu/console.nu>

~~~
pssdbt
Sounds interesting... I was just looking into F-script
(<http://www.fscript.org/>), is this similar?

~~~
286c8cb04bda
Aye, pretty similar. F-Script has some features that Nu does not (like the
object explorer), while Nu is the only one that works on iOS.

The big difference is heritage: F-Script is Smalltalk and Nu is Lisp.

------
igorgue
The funny thing is; That's not listing any of the major issues I have with
RubyMotion. One of them would be that I bought the software and I can't
integrate one external library I need, but, one of the greatest thing about
RubyMotion is that it has been getting updated every day. So I bet you they'll
update it with any new version of the SDK before it gets released.

The reason you should be excited about RubyMotion is that it's just easier to
read that ObjC since it has a lot less noise, and lot of goodies you just
"get" from Ruby's core. And the debugger is fantastic!

~~~
mmisu
What about user support ? Can you write and get an answer from the author in a
reasonable amount of time ?

~~~
smtm
When I bought ruby motion I was a bit in provisioning_profile hell. I shot off
a support Ticket and got an answer within 4 minutes from Laurent Sansonetti.
When I told him in a second Mail that I'm not too chummy yet with Xcode he
came up with some really useful links half an hour later.

By now there is a very active Google Group.Wrote a question yesterday and had
an answer within 10 Minutes. Very friendly vibe, mostly Rubyists dabbling into
Xcode, but also some very nitty gritty in depth topics.

Also the BubbleWrap repo (<https://github.com/mattetti/BubbleWrap>) is
chugging along nicely, cool for a young project... So, yes: you can get help.

------
rouss
Great write up, although not all the points are strictly speaking valid
(epecially the one regarding future ios versions; since all the pre-release
iOS firmwares are available for developers, there are chances RubyMotion will
be updated in a timely fashion).

My take on this is the following: using RubyMotion, overhead will be tremedous
- while debugging, you will need to make sure and double check that it's you
who screwed things up and not RubyMotion's author(s). This alone is a major
downside of the whole thing.

------
amir
Although updates to the last SDK version in a timely manner is a valid
concern, but does one really rebuild his application with a new major iOS
version after a week of the release?

~~~
jonny_eh
You might want to if there's a killer new API feature available, or if there's
a new iOS device with a different resolution that requires a rebuild to
support.

~~~
securingsincity
And the new sdk versions usually coincide with the release of a new device.

------
julian_t
I'm hoping they bring out a trial version... Ruby is not my main language, and
while I'd like to give this a try, I'm not $149 keen on seeing if it is
something I'd use.

------
macuenca
This looks very promising, but are there any examples of real applications
written with RubyMotion and submitted to the AppStore? Everything I see is
just stand-alone examples, but can all the pieces be glued together and turn
into a functional app?

And second, maybe this is a dumb question, but is there any possibility that
Apple blocks apps submitted using third party tools like this?

~~~
chc
There are apps written in MacRuby (RubyMotion's desktop sibling) in the Mac
App Store, and there are apps written in other alternative languages in the
iOS App Store, so it's hard to see what the problem would be. The RubyMotion
FAQ agrees with this assessment.

------
nicwise
I've got a little rebuttal to this here:

[http://www.fastchicken.co.nz/2012/05/11/so-many-straw-men-
so...](http://www.fastchicken.co.nz/2012/05/11/so-many-straw-men-so-little-
time/)

You have a good point, but mostly, I think it's a strawman argument.

------
spobo
It's the whole discussion of CoffeeScript vs pure JavaScript imo. Except that
RubyMotion doesn't play nice with existing libraries. Or does it?

Just make up your own mind. I'm thinking about just learning Objective C just
because I would definitely use those nice existing libraries.

~~~
evilduck
RubyMotion should be able to invoke any existing Obj-C library. It already has
documented support for CocoaPods.

New iOS SDK release support is a valid concern, but I don't think library
usage is a big problem.

------
adelevie
OP makes good arguments, but they seem out of place considering he's already
dependent on the Apple approval process.

~~~
jazzdog
What IOS developer isn't dependent on the Apple approval process?

~~~
adelevie
Kind of my point. OP's dependency arguments boil down to a matter of comfort.
Discomfort with depending RubyMotion seems at odds with discomfort with
depending on maintaining good favor with Apple.

I find both dependencies are well worth it.

------
VeejayRampay
Change. It scares people.

------
batista
> _Whenever I see a third party tool I ask myself: how quickly it will be
> updated to the last SDK version? Say Apple releases a iOS6 today. Will an
> aligned version of the tool be ready today? If not, when? One day would be
> fine, one week would not._

Really why? I don't even update my original XCode straight from Apple that
often.

When you sell to customers (for profit), you want to target previous versions
of the iOS, not the latest, and surely not within a week.

~~~
funkyboy
I had this issue with an iCloud-based app. A client wanted it to be ready on
the iOS5 release. I agree, it's living on the edge, but sometimes it is
required to have access to beta stuff and work on that. Not every third party
tool allow that.

~~~
batista
Well, if you're doing client work maybe it makes sense.

I was mostly talking about one's own work.

------
smacktoward
Light gray text on dark gray background! Great choice.

 _> Using a third party tool is like gambling: you might win or loose_

"Loose"? AAAAAGH

~~~
cleverjake
neither statements make for a useful conversation. please avoid them in the
future.

~~~
quanticle
To be fair, the "light grey text on a grey background" criticism is valid.
Your blog should be readable in most browsers and on most monitors. This blog
fails that test. I've looked at it on both Windows and Linux and on a couple
of different monitors. It's hard to read in all cases. I shouldn't have to
fire up Readability to read a blog post.

~~~
chc
It's a valid criticism, but it's not interesting or on-topic for the
conversation here. Cesare has an email address and a Twitter — those would be
better media for a comment like this.

