The main (very welcome) advancement seems to be that they've pushed this capability down from WebKit into JSCore. Today you can basically already do everything that's being shown in OP I think, you just were required to create an invisible WebView to host your JavaScript environment. You can easily expose classes to WebKit/JSCore (using KVC), and interact with JS objects from ObjC, and arrays, strings, etc. are auto-converted. The WebKit requirement is pretty annoying though, and as V8 has shown us, having a drop dead simple way of throwing JS into an app has some huge benefits.
Good catch, I hadn't seen that before. It definitely looks like WebScript and the new JavaScriptCore API are strongly related. It's interesting how hard the WebScript stuff is to find without knowing the name, it didn't turn up in any of my Googling when researching the post.
The fact that it's a refactoring (even a very nice one, as it seems to be) rather than a brand new API does make it less likely that Apple has any particular future plans for the API, which in turn make much of the speculation in the post even more speculative. I'm going to make an update to the post with a link to WebScript as well as a bit of additional commentary.
Totally agree it's more like an evolution, and I doubt it will be exposed on iOS at all, which means the same developer rules will apply and downloaded JS will have to be running inside a UIWebView.
The fact is that after thinking about the iOS developer rules and what is currently available in iOS, it's totally doable to write a true Javascript bridge that respect all the requirement from the iOS rules and still let your JS code access all the ObjC runtime, in a totally transparent way aka I am able to write the following:
var userName = userNameTextfield.getText();
var helloMsg = "Hello " + userName;
messageLabel.setText(helloMsg);
The first line will directly get the text value of a UITextField (no callback used here), and it will end up calling directly the 'text' property on the UITextField. So the JS bridge works transparently where JS code call native ObjC code directly (without using callback) and obviously ObjC can directly access the JS side... there are a few gotcha but the full system works beautifully and surprising enough performance are quite good. It took me a few years to come up with the cleanest solution and implementation.
I am currently working on integrating such piece of code into some of my apps and have them released on the AppStore. In fact if anyone good in JS is interested I would really appreciate some help to get that bridge off the ground since I truly believe there is a lot of great opportunities with a JS bridge to ObjC that respect all iOS rules.
My contact info are my HN profile.
The main (very welcome) advancement seems to be that they've pushed this capability down from WebKit into JSCore. Today you can basically already do everything that's being shown in OP I think, you just were required to create an invisible WebView to host your JavaScript environment. You can easily expose classes to WebKit/JSCore (using KVC), and interact with JS objects from ObjC, and arrays, strings, etc. are auto-converted. The WebKit requirement is pretty annoying though, and as V8 has shown us, having a drop dead simple way of throwing JS into an app has some huge benefits.