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?
Functionally, this appears to be identical to JavaScriptCore's longstanding C bridge [1]. If Objective-C isn't your preference, there's nothing stopping you from calling into the C bridge from C++ or just plain C.
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.
All good points. The big difference with the bridge going to Objective-C, though, is that I believe it is now possible to build a native UI by calling right from JavaScript to Objective-C. Impact is interesting for games and canvas-like rendering, but what I'd love is to be able to build the models and controllers of a highly performant, native-UI iOS app using JavaScript and UIKit. Sort of like Appcelerator with a layer removed.
That's fair. This does save one ugly, extra step that I didn't mention, which would be to call into the Objective-C runtime's C API [1] to dispatch messages and introspect Objective-C classes.
Should make it easier for developers to build their own middleware platform without getting too deep into reams of C boilerplate.
You should be able to to run code downloaded as part of IAP also. But this is one of the major things I wish they would change, and also one of the major reasons I'll be switching to Android.
Which is what I meant by "within the bundle of your app." That may have been a bit too iOS developer-centric, I apologize.
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 depends on the state of the bridge. Previous language bridges by Apple have generally bridged the gaps pretty well, with the main "Objective-C" relic being really, really long method names.
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.
> 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.
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.
On iOS it won't be that quick: you don't get anything more than the JS interpreter, as you cannot allocate any executable memory on iOS, so any JITing compiler is out of the question.
No, it applies per process: whether or not it came from a dynamically linked library distributed as part of the system is irrelevant. This is why UIWebView is slower outside of Safari.
It's important to remember that Apple shipped both the Ruby and Python Objective-C bridges in ~10.5 era OS X. You can (and I have) written OS X native software in Python; it wasn't super pretty, but the concepts mapped across reasonably well.
So I wouldn't take this as necessarily the sign of a shift in anything.
Also, people at Apple like Objective-C and its Smalltalk influences. For those of us who've been in the NeXT/Apple ecosystem a long time, it's clear that employees at Apple see Ruby as more interesting than say Javascript because of the Smalltalk influences. If any shift were to occur, money is on Ruby. But Apple likes Objective-C and no shift seems likely and we also saw what happened with MacRuby and the author leaving to do RubyMotion.
And they've invested a lot in the tooling and environment. It's not like they're just running a stock gcc toolchain; they've put a lot of very smart people on very hard problems in the language space.
Agreed. And another problem is that all these interpreted languages are terrible at exploiting parallelism which is a problem as we get more processor cores.
They were able to solve this in C by inventing Blocks and GCD.
