Why I loved building Basecamp for iPhone in RubyMotion(37signals.com)
37signals.com
Why I loved building Basecamp for iPhone in RubyMotion
http://37signals.com/svn/posts/3432
18 comments
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.
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?
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?
> 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.
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.
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.
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.
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.
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.
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.
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.
Objective-C is dynamically typed.
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.
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.
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.
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.
Core Data lets you set up a schema progammatically. There no real need to design a .momd schema with the Xcode editor if you don't want to.
I heartily recommend Core Data. It just works the way you expect it to: it's transactional, it's got undo, it fits right into the bindings system, it supports custom serialization, extensive validation, persistent objects are real ObjC objects, and so on.
I heartily recommend Core Data. It just works the way you expect it to: it's transactional, it's got undo, it fits right into the bindings system, it supports custom serialization, extensive validation, persistent objects are real ObjC objects, and so on.
What is the tradeoff between the two?
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.
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.
You shouldn't make such assumptions when you don't fully know how to use a tool, specially when you have such large audience.
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.
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.
It's one of those long-running holy wars of programming that goes back way further than iOS development.
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.
A lot of people period, don't bother to use the analyzers and instruments.
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.
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.
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.
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... (6/7 of these don't apply...testing is something I need to work on though!)
http://nshipster.com/nil/ (wat)
http://ashfurrow.com/blog/seven-deadly-sins-of-modern-object... (6/7 of these don't apply...testing is something I need to work on though!)
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 :-)
RubyMotion is a huge win for me because of the super low friction toolchain. I don't ever have to load XCode and I can automate the build process however I like because it's all command-line based.
I was convinced the moment I checked out https://github.com/HipByte/RubyMotionSamples and just started typing 'rake' in each directory not ever having to setup directory paths for xcode project settings.
I was convinced the moment I checked out https://github.com/HipByte/RubyMotionSamples and just started typing 'rake' in each directory not ever having to setup directory paths for xcode project settings.
XCode is all command-line based too.
https://developer.apple.com/library/mac/#documentation/Darwi...
https://developer.apple.com/library/mac/#documentation/Darwi...
The bigger reason to use RubyMotion is not a different syntax - you do end up using very similar code anyway, although lack of header files is a nice thing - but different tools. Objective-C is not the barrier. Xcode is.
No argument here, XCode sucks. RubyMotion seems like a heavy-handed answer to that, though.
After many attempts at getting started with Xcode and Objective-C had fizzled...it was an absolute joy trying RubyMotion and getting setup as an iOS Developer last night.
I can't wait to learn more, and it's wonderful being able to develop in Sublime, use RubyGems, Git, etc.
I can't wait to learn more, and it's wonderful being able to develop in Sublime, use RubyGems, Git, etc.
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.
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.
I really agree about the storyboarding stuff - I've had a hard time getting into it. That said, I'm a very experienced iOS dev, and I use XIBs as extensively as possible. I started writing apps before Interface Builder supported iOS in the summer of 2008, and those projects are completely, utterly crippled by the fact that there are thousands of lines of code that create and position views. None of it can be easily redesigned for iPad or enhanced for the 4" display. It'd take forever.
Using XIBs is also great for universal apps. I can instantiate the same controller with one XIB on iPad and another XIB on iPhone, and the layouts can be tailored to the platforms. It's wonderful when a client comes to you asking for an iPad version of their app, and you can duplicate the XIBs, scale them up, resize controls and swap out assets and go home early.
One thing that does suck about XIBs is that they ALWAYS cause merge conflicts. That part sucks and really needs to be addressed (at this point, Apple would probably have to write a diff tool for XIBs!)
Using XIBs is also great for universal apps. I can instantiate the same controller with one XIB on iPad and another XIB on iPhone, and the layouts can be tailored to the platforms. It's wonderful when a client comes to you asking for an iPad version of their app, and you can duplicate the XIBs, scale them up, resize controls and swap out assets and go home early.
One thing that does suck about XIBs is that they ALWAYS cause merge conflicts. That part sucks and really needs to be addressed (at this point, Apple would probably have to write a diff tool for XIBs!)
> 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.
It's really variable. XIBs have issues with source control, but they can be very useful for bringing in assets without needing a load of boiler-plate image loading code. iPhoto, for example, is laid out programatically but most of the controls are coming in from XIBs.
It's really variable. XIBs have issues with source control, but they can be very useful for bringing in assets without needing a load of boiler-plate image loading code. iPhoto, for example, is laid out programatically but most of the controls are coming in from XIBs.
I agree about experienced iOS devs doing everything programmatically. IB is really, truly awful, and just about impossible to use in a team with CM. From most tutorials though, you'd think it was required. Not only is it not required, but it's easier and more powerful to not use it at all.
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.
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.
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.
>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.
No, not at all. Especially in iOS.
No, not at all. Especially in iOS.
As cheap as it may sound, I would love to try/use RubyMotion if I didn't have to pay for it.
The price is a pretty big barrier to entry. I understand why, but an eval option would be nice.
http://www.rubymotion.com/support/#faq
Discount for students/academics.
Discount for students/academics.
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.
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.
I am old enough to remember having to pay for all my development tools.
Open source is cool, but developers need to buy food.
Open source is cool, but developers need to buy food.
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.
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.
If youre comparing Interface Builder to Visual Basic, you just dont get it.
Ruby Motion is amazing, mostly due to it working in my existing setup. I can use VIM and Rake to do everything :)
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.
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.
I've dipped my toes in RubyMotion and it's a lot of fun.
How does this compare to phone gap? I wouldn't know about rubymotion since I can't afford it.
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.
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?
I love ruby, but is that the only business case for rubymotion?
Does something simular to RubyMotion, but in Python exist?
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.
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...
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...
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.
I don't think RubyMotion exists because like Obj-C it was inspired by SmallTalk. Well maybe it is, but that doesn't mean it's an insurmountable barrier that would render a similar project in python impossible or "un-python like". C#/.NET got the treatment a long time ago, http://xamarin.com/. It's just that (it appears) no company or OS developer has taken on the challenge of creating the tooling for python.
Objective-C has tons of language bindings out there. The only languages I'm absolutely sure have made it onto iOS are Lua, Ruby and Javascript.
If you're an OS X user you can check out PyObjC: http://pythonhosted.org/pyobjc/
If you're an OS X user you can check out PyObjC: http://pythonhosted.org/pyobjc/
holy mother of awfulness - $200?
A small price to pay considering what you could create with such a tool.
For a student who wants to explore Ruby for iOS apps instead of going through the whole Xcode-ObjC learning curve? I think not.
There's a discount possible for students : [email protected]
nice.. downvote anyone who complains about cost
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.