RubyMotion Success Story: Basecamp for iPhone

37signals released last month an official iPhone app for Basecamp, their flagship project management software. It is the first iOS app developed completely in-house at 37signals.

As you may have already heard, the Basecamp app is written in RubyMotion. Since Nick Quaranto was speaking at our conference last week, we decided to take advantage of the opportunity to record a quick interview with him about the experience. Check out the video and the transcript below! 

You just announced the motion-layout gem tonight, has it been a long time coming?

(Laughs). Kind of. When we wrote the Basecamp app at 37signals we didn’t really use Interface Builder at all.

There is a new API in iOS6+ that provides auto layout for views, and specifically there is an ASCII-art style format string. It’s really weird that Apple let programmers design ASCII-art languages. So, the gem wraps that kind of verbose API that Apple provides.

So I guess it’s kind of been a long time coming, it has been 2-3 months in the making, it’s really not complicated, it’s just a little gem.

Speaking of the Basecamp app, when did that get started? When did you put that into your bosses’ ears?

That’s kind of an evolution. I started using RubyMotion in June, and RubyMotion came out in May. I basically got that month – I was very lucky to get a whole month to just work on iOS.

I hadn’t done any iOS work before, I had only done Ruby and Rails, and before that, I had a Microsoft background. (Laughs)

You don’t have to admit that here (Laughs)

I feel bad now. (Laughs)

Anyway, the first app we worked on was kind of a prototype. It was to learn how iOS apps worked. That got rejected, we ended up not going forward with that.

How was that initial learning experience?

Good! I feel like I really got a lot from that whole month. I learned how to make an app, how to ship it on TestFlight, I learned gestures and how hard it is to write an app, images and all sorts of other stuff. The different layouts, and how things are supposed to work.

We didn’t go forward with that very specific idea, because we were kind of prototyping the idea, but we kind of merged together two ideas that were coming forward. I had an idea: in that little prototype app we used HTML inside a small part of the app, and it felt very native, and at the same time we were working on web views for Basecamp, so that if you were on Safari on iOS, or Android, or any other browser you could see your stuff in Basecamp, so we kind of decided that, wow this is really native, it felt very native on the phone even if it was HTML.

We had all these views, and we kind of combined these two into an app. It wasn’t Basecamp at the start, we actually started just by solving specific problems, for example just to get an update on your phone when something was happening on your projects.

The app was focused on that at first, then we realized it kind of stinks that this is all you have, and we wanted to jump between things in your projects, and see all your TODOs, or all your files, so it kind of evolved from there and eventually it became the Basecamp app. We didn’t start by saying “we are going to make a Basecamp app”, it was more started like we have these problems when we’re on the run with Basecamp, and we want to fix those.

What did your RubyMotion toolbox and workflow look like?

Pretty normal, we do use a mix of Cocoapods and gems, we use some URL caching, there is just a few others… date formatter stuff that we use as well.

On the Ruby side we use Bubblewrap which is a great resource for anyone that’s starting with RubyMotion, just for iOS development in general, it saves a ton of time.

There are a few gems that I extracted along the path like motion-layout, I also have another one to make settings-bundles, called motion-settings-bundle. So it’s kind of a mix of both, and I think that it’s very healthy that we can get all of these great libraries from the Objective-C world and use new Ruby stuff as well.

You are a very seasoned Rails and Ruby developer, what were the challenges working with RubyMotion? And Laurent won’t hear this. (Laughs)

(Laughs). I didn’t have any big problems with RubyMotion, the challenges were mostly iOS, and I think that’s… you can’t get around it, you have to learn the Apple APIs, you have to deal with that, you have to understand the patterns that are in Objective-C in Ruby, and that was a big source of conflict for me, because there is a conflict between the style we see in Ruby and the style in Objective-C, and they kind of butt heads all the time.

So I think that that was the hardest part for me, understanding and internalizing the patterns that are in Objective-C and all over Cocoa and libraries, such as delegates, the list goes on an on, like constants and enums, the list doesn’t end, you have to know all these things, you have to be fluent in both to be useful, but I did it (Laughs).

So I think it’s definitely possible to come from basically zero iOS knowledge and do an app with RubyMotion.

Is there anything that you learned along the way – I am sure there are some things! – so when you start you next app, what are the things you learned that will make you start quicker?

I am going to start testing more (Laughs). I need to admit that I didn’t do any good job at all and we are definitely going to fix that, because the Basecamp app is something that we care about and we need it to last for years. So that’s a big thing I wished I looked into sooner.

Another thing… I always learn this lesson again and again: test on the device sooner! Obviously if you are making a mobile app you should be, but it’s very easy to be tricked thinking that the simulator is the real thing, when it’s not. There are performance problems that you see on the device that aren’t in the simulator, and I feel like I got reminded of this on a weekly basis.

Was there anything from the conference that just finished that you were excited about? You mentioned testing…

Yeah there were lots of great testing talks, a lot of crazy things came out, people really showed stuff I was impressed by.

One of the later talks was about Cocos2d, which is a game wrapper called Joybox, and it’s really neat, the guy basically made an Angry Birds clone in like 10 minutes in front of us, it was kind of crazy!

There was a testing talk about Calabash, which is really neat. Despite using Cucumber (and I have written a lot of Cucumber code), so I understand how difficult it is and how people’s opinions vary on it, but the coolest thing was that internally you had this nice API to do testing. You could drag things, you could look inside of web views, which is a big deal for us, you can do all sorts of stuff, and it’s backed by cucumber but beneath it is this cool Ruby thing that I need to look into!

I was really impressed by the quality level of talks and the stuff people showed off.

If you were starting your next app, how would you convince your boss to use RubyMotion?

Well, that’s really a good question. (Laughs)

Luckily I didn’t have to do too much convincing. Showing them how much easier it is is always a good thing, like the before and after, here is how it is in Objective-C, and here is the much-improved-less-verbose version in Ruby.

Another thing, that I think is the biggest win, especially for people that are coming from Ruby and Rails background, that if you’ve already got a team of people who know Ruby on Rails, the jump is a lot smaller to this new brave world, right, because you can leverage all of the toolchain that they know, they can use whatever they have been using in Rails, it’s the same language, there are maybe a very little differences but it’s still Ruby, you get all of the awesomeness that is Ruby, but you can’t get around learning the iOS APIs.

So I guess that if you are coming from a Ruby and Rails side, that’s it. If you’re coming from an iOS team I guess it’s probably a bit of a harder sell. Since personally I don’t have experience with that it’s harder to speak on, but I hope that if you are an iOS developer looking at RubyMotion you get a solid look at the code, like the comparison, how much easier it would be, and especially all the new things that are coming along that help you make a RubyMotion app, and that you can’t really use in Objective-C. So I hope that you give that a look if you’re trying to convince your boss.

Are there any tools, any tricks that you would like to see come down the pipeline?

It would be really nice if every-gem-ever worked, that’s very unrealistic, but I like Ruby gems a lot, so it would be very cool, it’s also a hard problem and it’s definitely been an MVP-style thing for the RubyMotion team. Just the fact that already we can make these really awesome things without having the bulk of Ruby gems available is a really good sign.

Besides that, Laurent mentioned code reloading in the roadmap, if that worked that would be a huge win. I went through a lot of links with one of the first prototype apps I made, to completely reproduce my web workflow, to the point where I remapped shake device in the simulator to Command+R, to get a reload, so if there is a better workflow for that, where you can basically say, here is what you’re used to, and here is the awesome new way of doing this, that supports the same thing, because I run rake and reload my app countless times, I should’ve kept a count, that would make a huge difference, that would make me a lot faster. Because you don’t have to wait! It’s just there. That would be huge.

Thank you Nick!