MacRuby and the Mac App Store
rubyinside.com
rubyinside.com
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.
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?
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.
[Edit: as noted by rdouble, package size is an issue]
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).
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.
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.
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?
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.
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?
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.