Hacker News Reader

Comment by alexyoung | Hacker News Reader

"Given all of this, I think that if you want to develop OS X apps without moving away from Ruby..."

I've written a lot of both Ruby and Objective-C/Cocoa over the last few years, and as much as I enjoy working with Objective-C Ruby really would save a lot of effort. It's not like I have a problem "moving away" from Ruby, but I'd like the option to sell apps made with it through their service.

If Apple ships MacRuby pre-installed in Lion, with Xcode integration and documentation, I think it would be huge.

View on HN

Hopefully Apple does include MacRuby pre-installed.

I just wrapped up a MacRuby app. MacRuby is a very cool system. However, if you are distributing the app, you either have to include all of MacRuby, or go through a complicated and error-prone process of excluding portions of the stdlib. This is a black art at the moment.

Even without most of the stdlib, the bundled app is much larger than the equivalent Cocoa app.

The larger app size could become a concern on machines like the Air with smaller SSDs. It also seems tasteless to have multiple apps each with their own MacRuby distro bundled up with the app. A pre-installed MacRuby would solve both of these problems. Then again, it would also make creating Mac apps almost too easy... how will I compete?

If Lion came with MacRuby installed on it you wouldn't need to bundle MacRuby to distrubte the app ... for Lion users? But what about for those of us who are on Leopard/Snow Leopard (or Tiger for that matter) - while Apple users seem to adopt the newer tech much quicker than others it still seems like you'd be cutting out a large group of potential customers/users.

What kind of package size are we talking here? I see MacRuby is 30MB, surely the whole thing isnot required.

Yes, the whole thing is required. In fact, my app is 34MB, the majority of which is MacRuby + the stdlib.

I cobbled together a process using information found on a number of blog posts and mailing list archives which let me exclude the parts of the stdlib I wasn't using. This got the file size down to 14MB. However, I don't have any QA resources so I'm not sure if this has introduced any instability in the app.

In contrast, the pure Cocoa version of this app is 4.5MB.

I think the newer version of macruby, with greater bridgesupport, should help this out: http://www.macruby.org/blog/2010/10/08/bridgesupport-preview...

When I'm installing even reasonably simple Mac apps, I often see the progress bar talking about sizes in the mid double digits. This sucks but is common.

Why does this matter?

MacRuby packages itself inside the .app, so you have a self contained package (can distribute the app without requiring MacRuby on client machine)

[Edit: as noted by rdouble, package size is an issue]

I agree. But I guess it depends on the succes of the OS X app store. If becomes popular quickly, it does not make sense to use a non-exclusive technology, while it could attract a lot of developers otherwise.

Though, I think it will require inclusion of MacRuby, or an exception in the OS X App store terms. It's not that likely that they will accept a bundle-wrapped MacRuby given that they also do not accept programs that use deprecated technologies (Java, Rosetta).

I think the "deprecated" clause is only in there so that apps don't rely on parts of the operating system that are deprecated and likely to disappear, not frameworks you link in (of which there are thousands out there).

The clause makes sense in this respect because if you rely on OS X's Java or Rosetta and Apple removes them, your app breaks. Something linked into your .app file? That can't be "deprecated" by Apple.

The clause says deprecated and optional technologies will be banned. So sorry but if MacRuby is not part of the OS, then it is pretty clear it is optional so it will not be allowed on the appstore.

And it is completely useless to think about what makes sense or doesn't when talking about the appstore. The iOS app-store forbids apps that were made with particular compilers even if they are submitted in app-store allowed form. Does that make sense?

The clause says deprecated and optional technologies will be banned. So sorry but if MacRuby is not part of the OS, then it is pretty clear it is optional so it will not be allowed on the appstore.

In such a liberal interpretation, all third party libraries could be banned, but no-one's going to entirely write apps that only use Apple's frameworks. That's not even the case with iOS. You can include extra "optional" frameworks into iOS apps no problem. The main reason MacRuby hasn't made it to iOS yet as an including framework is due to its reliance on garbage collection functionality not present in iOS.

I think you might have missed the update on that story from a month ago. Straight from Apple's mouth:

  In particular, we are relaxing all restrictions on the 
  development tools used to create iOS apps, as long as the 
  resulting apps do not download any code.

One of a few articles about it: http://arstechnica.com/apple/news/2010/09/apple-relaxes-rest...

We are not just talking linking here. Including a Ruby interpreter, and a part of the Ruby library, or a Java virtual machine and class library if you will. I don't think Apple will go for that.

Why not? They could have said so in the rules if they wanted to forbid it. They forbade deprecated system components, not bundled class libraries.

FWIW, they already allow Lua to operate in a similar manner on iOS since the third-party development tools policy change in September.

I think Apple relaxed the rules because it's all too hazy. Linking in a PDF "interpreter" that calls out to various image decompression libraries is structurally little different than how MacRuby could roll.

Reply on news.ycombinator.com