
Why I loved building Basecamp for iPhone in RubyMotion - johnmwilliams
http://37signals.com/svn/posts/3432
======
sandofsky
I spent four years developing Ruby full time. The last few years, I've been
doing iOS full time, and there's no way I'd add a third-party layer to my app.

If you want to ship a high quality iOS app, you need to understand Objective-C
inside and out. If you are using RubyMotion to avoid learning Objective-C, you
will ship at the the cost of massive technical debt.

If you already know Objective-C, Ruby gives you a more concise syntax. Having
used both languages for a while, and now that ARC exists, I'm comfortable
using Objective-C as a high level language. Objective-C is wordier than Ruby,
but when I return to the code a year later, I can still understand what it
does.

As much as I hate Xcode, Apple expects you are using it. Sometimes features
land in Xcode a version ahead of the command line tools.

For the handful of benefits I see from RubyMotion, I see a mountain of risks.
Will Apple change its policy on accepted languages? Will the translation layer
blowing up when you need to ship a hot fix the day before the iTunes store
shuts down for Christmas? Will someone acquire the RubyMotion team and sunset
the product?

Maybe I'm a different target audience. If an industry-changing platform
appeared, I wouldn't leverage what I already know to dabble in it. I would do
things the idiomatic way. Even if it takes longer to ship my first app, I
think it's the faster path to mastery.

~~~
hlidotbe
If you spent a few minutes to read RM's doc you'd have seen that RubyMotion
runs on top of the Objective-C runtime. The only thing it "replaces" is the
language, the syntax if you will. API, calls, parameters, ... all is native.
This is not Adobe Air, it's Ruby on top of the Objective-C runtime. There's no
translation involved, no interpretation.

~~~
sandofsky
I understand what RubyMotion is.

RubyMotion is another layer. You can argue it is minimal. That doesn't change
that it is a dependency, out of your control, and unsupported by Apple.

Let's say the RubyMotion team is acquired, and the product sunsetted. What do
you do?

------
stcredzero
_> Respect the Style

RubyMotion is Ruby, which is normally succinct, short, and sweet. The iOS APIs
stick out like sore thumbs amongst what is normal Ruby code: camelCase usage
is pervasive and reallyFreakingLongParameterNames can’t be tuned out._

When I first read the above paragraph, I was afraid this was going to be a
case of someone using a great tool to enable willful ignorance, but:

 _> So far, I’ve ended up with staying in Objective-C style. All of the API
calls you make into the various iOS frameworks need to be in that style, and
seeing the different opinions of variable and method naming clashing ended up
hurting my head._

I commend the author for being perceptive and pragmatic. There is also a
reason why things are the way they are in iOS and Cocoa. Long Intention
Revealing names document what's going on, and reduce the incidence of unwanted
name collisions. It has a heritage from Smalltalk, so it's been around and
developing for something like 40 years! That puts it in the same league as
Lisp as a way of doing things with merit that stands the test of time.

------
FuzzyDunlop
The major concern I have with something like RubyMotion is that Objective-C -
the language it stands in for - is _not_ a difficult language. The
Cocoa/CocoaTouch API and its verbosity is the real problem, and I think that
trying to map the extensive documentation written in Objective-C to a Ruby
equivalent runs the risk of adding too much mental overhead. That it requires
a paid-for license means that Ruby specific documentation will be
comparatively thin on the ground, and the same applies to the resources found
on StackOverflow.

I'm a Ruby developer, and I find Obj-C a nice language to work with (though I
do prefer the s-expression style in favour of the more recent dot notation). I
still haven't managed to justify using Ruby in place of Objective-C.

The only major benefit I see is the REPL that ties into the simulator, and
losing the dependency on X-Code, but again, I feel that the verbosity of the
APIs is the fault for that.

~~~
qrush
It hasn't been that hard for me to translate Objective-C code into Ruby. The
hardest thing has been APIs that have varargs that end in nil for some reason.

Recently the RubyMotion team published this yardoc that translates all of the
existing APIs for you into Ruby:

<http://www.rubymotion.com/developer-center/api/index.html>

But I didn't refer to that for the majority of the development since it wasn't
around yet...I was knee-deep in the Apple docs for most of it.

~~~
FuzzyDunlop
I think that's an issue of moving from Objective-C (and pure C), to what is
normally a dynamic language.

Using nil as a final argument (also called the 'sentinel') is fine for C to
mark the end of a variable length array like it expects with 'strings' (so it
doesn't stretch into the next unrelated block of memory), but you'd expect
Ruby to handle that for you. Because in any other circumstance, it does.

~~~
bdittmer
Objective-C is dynamically typed.

------
kranner
I'm a fairly experienced iOS developer and a Ruby beginner. I bought a license
just to play with and learn about Ruby in a familiar context. But one thing I
did not find mentioned is how slow the RubyMotion build-deploy cycle is.

For small changes, on a 2011 MBP, Xcode takes a few seconds to rebuild and
deploy to the simulator. RubyMotion takes ages, easily exceeding one minute
(single-core process?). Repeated a few times, it's enough to shift my thinking
from play-mode to plan-mode. At this point I'm still too uncomfortable to
begin new projects with RubyMotion, just because the slowness is so annoying.

------
flixic
Oh what a joy it is to read this! My experience with RubyMotion is very
similar, and I am very happy to see major, high-profile app made with
RubyMotion.

However, I was somewhat disappointed to see that they use BubbleWrap
persistence instead of true CoreData. I've been struggling to use CoreData
without Xcode with RubyMotion for a while and haven't found a great solution
yet.

~~~
michaelbuckbee
What is the tradeoff between the two?

~~~
flixic
CoreData is a very powerful object store with many libraries that support it.
I haven't tested BubbleWrap much, but it's a very simple system, without
searching, indexing, migrations and other CoreData features.

------
eduardordm
I liked the post and the general message, but the 'Avoid Xcode' part is
rubbish.

You shouldn't make such assumptions when you don't fully know how to use a
tool, specially when you have such large audience.

~~~
bengotow
I agree with this point. A lot of RubyMotion fans seem to be trying to build
an app for iOS while learning as little as possible. While that's great if
you're on a tight deadline and want to play to your strengths, Xcode is an
incredibly powerful tool and features like the static analyzer, visual
debugger and core data visualizer shouldn't be thrown out because some command
line utility will let you Build & Run.

~~~
ef4
It's not a question of learning something new. It's that there's a
fundamental, philosophical split between people who hate IDEs and people who
love them.

It's one of those long-running holy wars of programming that goes back way
further than iOS development.

~~~
gte910h
A lot of people who use Xcode don't realize you can use many of those tools
without it

A lot of people period, don't bother to use the analyzers and instruments.

------
taybenlor
I got into iOS development via RubyMotion. I was a Rails developer for a few
years, now I'm an iOS developer (using Objective C). I've only really started
with Objective C and XCode. Objective C isn't a huge barrier, but Cocoa and
XCode definitely are. That's one of the reasons I really enjoyed RubyMotion.

If I could choose (and wasn't working with other people) then I would go with
RubyMotion. The toolkit is a lot less mature than XCode. But the productivity
is definitely higher and there's much more room for improvement via the OSS
community.

RubyMotion side-bonus: you don't have to merge (basically) binary files when
you're working entirely with code for UI.

------
cozykozy
At face value, I like the idea of RubyMotion, but I can't help but feel like
it's a crutch to avoid picking up a few subtleties in Objective-C. The article
even points out that RubyMotion doesn't hide much of the API from you, so in
some ways it feels like 6 in one hand, half a dozen in the other. I'm not
trying to be a naysayer, but I don't think the barrier to entry is as high as
some make out to be.

~~~
qrush
Call it my crutch, but I got an app shipped without having to worry about a
lot of the baggage that comes with Objective-C as a language. Here's two of my
favorite examples of things I didn't have to worry about:

<http://nshipster.com/nil/> (wat)

[http://ashfurrow.com/blog/seven-deadly-sins-of-modern-
object...](http://ashfurrow.com/blog/seven-deadly-sins-of-modern-objective-c)
(6/7 of these don't apply...testing is something I need to work on though!)

~~~
bengotow
You're definitely right — nil / NSNull is confusing to newbies, but Ruby is
just as bad. The way it handles UTF8 is somewhat backwards, and the fact that
symbols and strings are different (but sometimes used interchangeably) can
cause 'gotchas' for newbies too. I'd argue that your language of choice is
really dependent on which set of baggage you've internalized :-)

------
austinl
I think there's a disproportionate amount of beginner's material that involves
the use of storyboarding and Interface Builder, which gives the impression
that iOS development is a lot like it is in Visual Basic.

Perhaps other iOS developers can weigh in on this, but I feel like it's fair
to say that the most qualified developers do everything programmatically.

I've been doing everything exclusively programmatically since I've started,
and I've never had any problems with XCode - to the point where I was
surprised when I heard people complain about it for the first time.

From that point, the only downside I see to using Objective-C over Ruby is
verbosity, but that seems pretty inconsequential given some of the benefits
sandofsky mentioned above.

It's nice that there's something out there for experienced Ruby developers
though.

~~~
pjmlp
It always baffles me the amount of developers that prefer to endure designing
GUIs with code instead of GUI designers.

This doesn't scale when doing projects where the UI tends to be redesigned
every few days.

In a few hours it is possible to design UIs that some require days to do it.

~~~
josephhainline
Interface Builder doesn't let you do anything very dynamic (moving panels,
things that animate, etc) anyway. In my experience, a person experienced at
programmatic view creation is a bit slower on initial creation, but a lot
faster at refactoring or changes. A few well placed variables, for example,
gives you a lot of instantaneous visual control.

------
ceeK
As cheap as it may sound, I would love to try/use RubyMotion if I didn't have
to pay for it.

~~~
purephase
The price is a pretty big barrier to entry. I understand why, but an eval
option would be nice.

~~~
swanson
<http://www.rubymotion.com/support/#faq>

Discount for students/academics.

~~~
purephase
For non-student/non-academics that just want to try it out and see if it works
for them, it is a very steep price to pay. I strongly support paying for the
tools you use, but $200 for a feet-first dive is steep.

~~~
panzerboy
That's one of the reasons I like Xamarin's approach with MonoTouch. You can
use it and target the Simulator for free, but if you want to run your app on
the device, you need to pay for a license. Seems fair to me. I wish RubyMotion
would offer this as well. I bet a lot of developers (myself included) would
then try it out. But like purephase, I can't justify paying $200 just to try
something out.

------
tferris
What I like about coding is that you learn every day and starting a new
language is always inspiring and broadens you views. I just don't get those
who like to approach everything with just one language.

Rubymotion won't hide the Objective-C API anyway, so people have still to
learn and understand all of the Objective-C libs. There's no single reason to
use Rubymotion. This paired with the all the typical fanboyism around Ruby,
Rails, 37Signals is kind of annoying. Sorry to be harsh, but I don't care how
a client for an aged app (Basecamp) is built with a cumbersome layer of
abstraction.

------
visualR
If youre comparing Interface Builder to Visual Basic, you just dont get it.

------
danielsju6
Ruby Motion is amazing, mostly due to it working in my existing setup. I can
use VIM and Rake to do everything :)

------
beebs93
Nice article - easy-to-understand analysis of the benefits of RubyMotion.

I went the JS route with Titatium Appcelerator for our iPad app, but I've
followed RubyMotion since it appeared and always wanted to give it a try.

------
programminggeek
I've dipped my toes in RubyMotion and it's a lot of fun.

------
hayksaakian
How does this compare to phone gap? I wouldn't know about rubymotion since I
can't afford it.

~~~
robterrell
Night and day different. Phone gap wraps html inside a web view in an app --
you write your app logic as you would any dynamic web page. Rubymotion buils a
true native app. You write your app logic like you would in objective-c, using
cocoa and foundation classes.

~~~
hayksaakian
Would you say it was worth it though? If I was going to go native, I might as
well go full on obj.c otherwise I'd do phonegap.

I love ruby, but is that the only business case for rubymotion?

------
anderspetersson
Does something simular to RubyMotion, but in Python exist?

~~~
flixic
Put simply: no. RubyMotion works because Ruby and Objective-C are very similar
internally, both being inspired by SmallTalk and sharing almost all "core"
language features - it allows to run ruby code on Objective-C Runtime. In this
regard, python is a very different language, that would be extremely difficult
to port, and it wouldn't really feel like python.

~~~
objclxt
Well, sort of. I wouldn't really call it running "ruby code on the Objective-C
runtime". Your Ruby code is effectively being converted to Cocoa API calls
during the compilation process. RubyMotion has a number of Objective-C
subclasses that match back to Ruby objects (for example, strings in RubyMotion
aren't NSStrings, but a subclass of them). If you dump the headers out of a
RubyMotion app you can pretty clearly see this.

Ruby and Objective-C definitely _aren't_ that similar internally - as someone
else has suggested, there's no technical reason you couldn't do something
similar for Python. It just happens that Ruby to Cocoa bindings have been
around for a while (for some time with Apple support), and as a result there
has been generally more interest in carrying it forward.

I've probably failed to adequately explain how it works, but the MacRuby
source is available on GitHub, and Laurent Sansonetti has done a run through
how RubyMotion does it's thing here: [http://rubysource.com/laurent-
sansonetti-on-rubymotion-inter...](http://rubysource.com/laurent-sansonetti-
on-rubymotion-internals/)

~~~
flixic
Thanks! I knew most of this, but for some reason had an impression that ruby
was in particularly nice spot to subclass Obj-C classes. I have to agree, you
are right, and other languages could follow RubyMotion's model.

------
rogerchucker
holy mother of awfulness - $200?

~~~
CoachRufus87
A small price to pay considering what you could create with such a tool.

~~~
rogerchucker
For a student who wants to explore Ruby for iOS apps instead of going through
the whole Xcode-ObjC learning curve? I think not.

~~~
flyingbeaver
There's a discount possible for students : educational@rubymotion.com

