Live data from Hacker News

Why I loved building Basecamp for iPhone in RubyMotion

37signals.com

51–60 of 60 posts

Re: Why I loved building Basecamp for iPhone in RubyMotion

#51
post #48

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 s…

>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.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#52
post #48

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 s…

> 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.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#53
post #48

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 s…

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!)

Re: Why I loved building Basecamp for iPhone in RubyMotion

#54

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…

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.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#55
post #9

Earlier quoted context omitted.

http://www.rubymotion.com/support/#faq 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.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#56

Earlier quoted context omitted.

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 : educational@rubymotion.com

Re: Why I loved building Basecamp for iPhone in RubyMotion

#57

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…

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?

Re: Why I loved building Basecamp for iPhone in RubyMotion

#58
post #16

Earlier quoted context omitted.

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.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#59
post #48

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 s…

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.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#60
post #49
post #48

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 s…

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.

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.
Post reply on HN