My guess is that this would be fast enough to build almost any Mac app and many iOS apps. The bigger question for me is, how gross would it be to deal with the "Objective-C-ness" of the Cocoa APIs through JavaScript?
On iOS, developers have had to compile their own version of JavaScriptCore to use this API. That's the basis for HTML5 game engines like Impact [2], and some HTML5-to-Objective-C middleware platforms.
Unfortunately, until Apple says otherwise, this version of JSC is still subject to Apple's App Store review guidelines [3]. Thanks to guideline 2.8, you can't have your app, running JSC, execute any JavaScript that doesn't ship within the bundle of your app.
I'd like to see that rule change, someday. Exposing this Objective-C API in a future iOS release isn't going to change the status quo.
[1] - http://developer.apple.com/library/mac/#documentation/Carbon...
[2] - http://impactjs.com
Should make it easier for developers to build their own middleware platform without getting too deep into reams of C boilerplate.
[1] - https://developer.apple.com/library/ios/#documentation/Cocoa...
In Foundation, [NSBundle mainBundle] returns a reference to an object representing your application's root directory, and the code and resources found within. Roughly the same bits that you'd find within an unpacked IAP file.
That said, all of the bridges I've seen were to classical-OO languages. It is possible that Cocoa won't translate as well to prototypal-OO languages like JavaScript. It will be interesting to see how Apple navigates that paradigm shift.
This has already been done with Mozilla's Rhino (JavaScript or Java) and it turns out the be pretty easy to work with Java classes in that context.
Speculation is my own, derived from: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-...
So I wouldn't take this as necessarily the sign of a shift in anything.
They were able to solve this in C by inventing Blocks and GCD.