
Apple’s iOS7 Native JavaScript Bridge - bananacurve
http://strongloop.com/strongblog/apples-ios7-native-javascript-bridge/?
======
pflats
"Apple’s iOS7 support of JavaScript inline with your Objective-C code
validates JavaScript as the leading (and only) non proprietary language that
is supported within the iOS development environment by the device
manufacturer."

Since when is Objective-C proprietary? Apple's given it a few non-standard
extensions (i.e. blocks) but that doesn't make it a proprietary language. GCC
and Clang are open source.

~~~
bananacurve
Technically true, but Cocoa is proprietary. Is ObjC widely used for anything
else?

~~~
eonil
Check out Apportable.

And _proprietary_ doesn't mean _narrowly used_. Also _open_ doesn't mean
_widely used_. Bringing Cocoa was a good trial, but doesn't make the text
correct.

~~~
lambda
Well, when people talk about ObjC development on Mac and iOS platforms, they
generally mean ObjC plus Cocoa or Cocoa Touch.

It's true that ObjC itself isn't what's proprietary, but Cocoa and Cocoa Touch
are.

~~~
randomdata
I suppose it is fair to say Objective-C plus Cocoa Touch is proprietary, but
why is Javascript plus Cocoa Touch not proprietary in the same context?

~~~
lambda
You're absolutely right, I had forgotten that that was the original argument.

------
eonil
JSC was always there for years in WebKit source repository, and anybody could
build _native JSC engine_. Well, it needs some extra works, but there're also
some Github repos from other people.

AFAIK, the only difference to Safari was JIT compilation support. Because iOS
doesn't allow executing dynamically generated machine code in 3rd-party apps
for security reason.

Does iOS7 support JIT compilation on JSC embedded in any app? If it supports
JIT, that could be a big news, because it means Apple finally allowed
dynamically generated code in 3rd-party apps, but I don't think the day will
come.

And personally, I don't see any benefit from JavaScript apps. If someone
claims JS or any third party frameworks are better than Objective-C for iOS
app, I would like to ask these things. (could be offensive, but these are
actually how I feel from those claims)

Does it offer better auto-completion? Does it offer better
syntax/semantic/type checks? Does it offer better debugging aid? (like GDB's
execution rollback) Does it offer better accessibility to any platform
features? Can I use new features immediately? Shouldn't I wait for 3rd party
patch? Profiler for device and simulators? How's low-level access? If I have
some trouble, how can I fix it without knowledge for lower-level
(Cocoa/Darwin)? If I want to use C-based DSL? Is it safe for AppStore
approval? What's the benefit of using _open_ language on _proprietary_
platform?

I mean, _what 's better with JS than Objective-C with Xcode_?

If it can't offer any of those stuffs, it means it's at least 10 times less
productive = 10 times more cost.

Well, it could make sense JS app for an Android app because ADT is too sucks
so some extra wrapper can bring extra productivity. But for iOS, JS stuffs
only degrade productivity by extra abstraction, debugging hardness and
inferior toolsets.

~~~
apaprocki
AFAIK they will never allow JIT. It isn't so much banning JIT as it is the
kernel providing no way for applications to mark memory pages executable.
Marking memory executable is how JIT compilers function, but it also prevents
other uses.

~~~
phoboslab
I still have hopes that Apple cares enough and finds a way to whitelist the
JSC lib somehow.

Not sure exactly how that would work, because permissions to allocate
executable memory is given per process on iOS. But I guess they could inspect
the call stack to see if the allocating call indeed comes from the built-in
JSC lib?

~~~
mistercow
They could potentially do it with IPC, running the JS engine (or even the
entire web view) in a separate process. The question then is whether the
communication overhead can be minimized so that it doesn't cancel out the
performance benefits of the JIT.

~~~
eonil
They're doing that for Quartz.

But I doubt what will drive Apple to improve JS performance. Because making
people to use Objective-C is a lot beneficial to Apple.

~~~
mistercow
Interesting. If they're doing it for Quartz, then that pretty much answers the
overhead question. I suspect you are right that Apple feels very little
motivation to improve support for languages and environments that don't lock
you into their system. Or at least, they wouldn't have under Jobs.

But I don't think it is _true_ that this strategy is actually more beneficial
to Apple. Developers want to support multiple platforms, and the least
expensive way to do that is often HTML5. That's why PhoneGap is popular,
despite the poor JS performance. The extra cost of doing separate apps is
ultimately paid not only by third party developers, but by Apple as well. To
make a long story short, encouraging a cross platform environment would allow
good developers to make higher quality apps.

Much as I dislike Apple these days, the difference between iOS and Android is
such that I have trouble maintaining a straight face when I hear them
compared. They don't need to compete on app availability.

------
nilliams
There was a great talk on this at Cascadia JS, 'JavaScript as a first-class
citizen on iOS7':
[https://www.youtube.com/watch?v=y-nodF6Cp1Y](https://www.youtube.com/watch?v=y-nodF6Cp1Y)

~~~
tehwebguy
Just watched the entire thing, very cool.

Near the end he sets up a scene, physics and tap events to create new objects
on the screen with a few lines of JavaScript. All of the heavy lifting is
handled natively in iOS SpriteKit and it runs at 60 fps.

~~~
phoboslab
You might be interested in Ejecta[1] then. X-Type[2], a game I made with it,
easily draw hundreds of sprites with 60fps.

[1] [http://impactjs.com/ejecta](http://impactjs.com/ejecta)

[2]
[https://itunes.apple.com/us/app/x-type/id597488149?mt=8](https://itunes.apple.com/us/app/x-type/id597488149?mt=8)

------
georgemcfly
Objective-C isn't a proprietary language, as this author annoyingly suggests
several times. Regardless, the new JavaScriptCore framework is pretty
impressive. It would be nice if there were some official Apple docs beyond the
one WWDC video, though.

~~~
mattschmulen
I agree, it was a bit tough to find good docs and references. If anyone has
other good references I would love to check it out.

~~~
lazerwalker
It might not be that helpful, but you can actually download the JavaScriptCore
source directly from the WebKit trunk
([http://svn.webkit.org/repository/webkit/trunk/Source/JavaScr...](http://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore/)).

It's worth noting that there are some discrepancies between that codebase and
the actual behavior of the public iOS 7 framework, but if you're not doing
anything too crazy it probably won't be an issue.

------
riq_
Shameless plug here: In case you need to use JS on older iOS versions, I
created JavaScript bridge for Objective-C (and C).

It is a command line tool that parses Objective-C header files (using llvm)
and generates the needed intermediate "bridge" files. Internally it uses the
SpiderMonkey VM (instead of JavaScript Core) The source code and the
documentation can be found here:
[https://github.com/ricardoquesada/jsbindings](https://github.com/ricardoquesada/jsbindings)

------
sjtgraham
I've been working with JavaScriptCore to facilitate the optional code-on
demand constraint of REST, e.g. A client requests a JS representation of a
resource, which includes what fields a valid resource has, type hinting so the
client can dynamically build a UITableView with the most appropriate controls
for each field, and validation functions allowing the client to validate a
field when it changes or when its UITextField resigns first responder status.

I just had a horrifying thought: Aren't apps that download code banned from
the App Store? If so, would this include JS downloaded at runtime to be
evaluated with JavaScriptCore? What's the conceptual difference between this
and a UIWebView opening a page that has <script> tags embedded?

~~~
cpleppert
3.3.2 An Internal Use Application may not download or install executable code.
Interpreted code may only be used in an Application if all scripts, code and
interpreters are packaged in the Application and not downloaded. The only
exception to the foregoing is scripts and code downloaded and run by Apple's
built-in WebKit framework.

I take this to mean that the javascript has to be downloaded by the
webkit/uiwebview as part of an web page and you can't supply the javascript
externally if you get if off the network.. There is a lot of confusion online
on this point(some people disagree) but that is my understanding.

~~~
sjtgraham
Thanks, JSC is part of Webkit so I hope it is allowed. I've emailed John
Geleynse (the contact listed at the end of the WWDC talk) to get a concrete
answer from Apple. It would be such a terrible waste if they disallow this.

It looks like there is a way to get the JavaScriptContext of a UIWebView using
KVC, but it's not clear if that is "undocumented" and therefore private,
because the whole framework is basically undocumented.

------
pdenya
That syntax for passing obj-c blocks to javascript is nice. I've never been a
fan of titanium/phonegap but this might make it easy and fast enough to be
worthwhile. Ideally I could use html for some complex interfaces seamlessly
and keep native components (scrollviews, etc) elsewhere.

------
cwp
I wonder if Apple would approve an app that downloads and executes Javascript
using the bridge. Historically, Javascript has been an exception to the
blanket rule against downloading code, but outside of a web view, that might
not hold.

~~~
interpol_p
Interestingly, a few apps seem to download code and run it.

GamePress, a drag-and-drop game editor does this. Featuring an "Arcade" where
you can download others' games.

And Editorial, a Python-based writing tool allows one to download and execute
"workflows," which include Python scripts.

We were asked by Apple to remove code sharing features from our own app. I am
hoping that they are no longer enforcing this policy.

------
tylerlarson
The iPad app that I've been working on was partially built with Ejecta, which
uses the JavaScriptCore to eval JavaScript and pairs this with OpenGL ES to
implement the Canvas and WebGL APIs. You can see it here if interested
[https://itunes.apple.com/us/app/paperless-post-
invitations/i...](https://itunes.apple.com/us/app/paperless-post-
invitations/id489940389?mt=8)

------
martin_
Sounds very similar to [http://www.cycript.org/](http://www.cycript.org/)

------
United857
Very cool -- but would be nice if they could tie this into the DOM and JS
context of a UIWebView, so we could have true HTML5/hybrid native apps.

------
comex
Incidentally, on my retina MBP in Safari, the entire text of this post somehow
manages to appear scaled up and blurry. Doesn't happen in Chrome.

------
stevejohnson
Does anyone have benchmarks about JIT vs non-JIT Javascript on iOS 7? I'm
interested, but haven't been able to locate any.

~~~
eonil
This is not JSC, and just using UIWebView, but would be good enough to
estimate approximated difference.

[http://iao.fi/myposts/uiwebview](http://iao.fi/myposts/uiwebview)

The author is claiming the difference would be about 5x. I think that's
reasonable.

------
Zelphyr
I recognize this is pedantic but why does he keep using "surface" as a verb?
Is there some new programming nomenclature I'm just now getting exposed to? If
so, what does this mean?

It reminds me of a Java programmer I used to work with who constantly said he
was "hydrating" his objects. I kept wanting to tell him he wasn't sounding as
cool as he thought he was.

~~~
alexandros
Surface is a legitimate verb, just like any other. Perhaps the author isn't
native, and is using a different verb than the one you'd like. Or perhaps
that's how he feels like expressing himself. But it is shocking you'd think
this is a worthwhile comment and others would upvote you on it.

It's quite sad that this comment is currently the top comment, in an article
that raises quite an important topic for the JS and iOS developer communities.
As much as I loathe the "hn is turning into reddit" crowd, this is much worse.
HN is turning into a criticism machine that when it can't find anything
worthwhile to criticise, will literally criticise anything at all rather than
elevate a positive comment to the top.

~~~
pflats
On the second half of your post:

I feel like this happens when people find the basic idea of the article (JS is
now a first-class language on iOS!) interesting enough to upvote, but the
article itself isn't anything exciting beyond that. The top comments are
people's reaction to the articles. Right now, they're "the article keeps
calling Obj-C proprietary, but it's totes not"; "that's cool and all, and
here's some history, but how is this better than Obj-C"; and "here's a talk
about it on youtube".

If there's more interesting conversation to be had, someone would have
submitted it. You could have submitted it! I read through every other top-
level comment, and didn't find any of them were particularly interesting. Is
there some conversation that you think is worth having?

(But yeah, surface is a totally legit verb, makes sense in this context
(bringing an Obj-C object into JS), and it was only used twice anyway.)

~~~
Zelphyr
Thank you for clarifying what to "surface" an object means. I'd never heard
that before.

------
general_failure
Appcelerator cannot use v8 because v8 has no non-jit mode. Ios apps cannot
jit...

~~~
phoboslab
Whitelisted Apps can. Mobile Safari for instance uses the JavaScriptCore JIT;
Chrome however does not, despite using Apple's built-in WebView.

~~~
CodeWithCoffee
I would be interested to know how that whitelist is implemented. I would
suspect that the default apps (Safari, Mail, iTunes, etc) are compiled to use
a custom implementation of UIWebView that uses JIT (which would completely
prevent Chrome from using JIT), but it would be interesting if there is a
switch (perhaps by a plist key) that Apple could flip, so a few selected apps
could get access without the need to do compile against private libraries.

~~~
bdash
An entitlement.

------
AsymetricCom
If you're reading this and picking up new information (besides strongloop's
Titanium pitch) you're really in the dark about what's going on.

