Apple’s iOS7 Native JavaScript Bridge

http://strongloop.com/strongblog/apples-ios7-native-javascript-bridge/?

by bananacurve • 13 years ago

116 62 13 years ago

nilliams2• 13 years ago

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

tehwebguy• 13 years ago

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.

nilliams2• 13 years ago

Yes I meant to come back to this comment and explain why people should watch it. What you said!

phoboslab3• 13 years ago

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

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

pflats2• 13 years ago

"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.

bananacurve2• 13 years ago

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

eonil6• 13 years ago

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.

mattschmulen3• 13 years ago

True on proprietary. I don's know of any impactful use cases for ObjC. However there are some good things about this. The spec can move fast, focus on success in use cases, and also make it easy to conform to 'nice' HIG. In many cases it's nice to not have to worry about these things and just focus on the end app use case. In the end when it comes to iOS and OSX its still Steve Jobs word were just playing in it.

ketralnis2• 13 years ago

Does OpenStep count? It's a clone of NeXTstep, which is what Cocoa is itself a descendent of

mikestew• 13 years ago

Cocoa isn't ObjC, it's an Apple-specific framework. Granted, that's a bit of a nit-pick considering the answer to your 2nd question. But ObjC was around before NeXT showed up.

mmariani• 13 years ago

Cocotron [1] is another alternative that can target Windows and even Linux with some exceptions.

[1] http://www.cocotron.org

chrisdevereux• 13 years ago

Or, for that matter, C and C++

blub• 13 years ago

It's not really, but there is no point in using it outside Apple platforms. I mean I spent time learning the thing and those skills are completely useless when not working on iOS and not really needed on the Mac in my case.

duaneb• 13 years ago

Well "not being used elsewhere" is different from "proprietary."

georgemcfly• 13 years ago

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.

mattschmulen3• 13 years ago

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• 13 years ago

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...).

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.

eonil6• 13 years ago

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.

apaprocki2• 13 years ago

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.

phoboslab3• 13 years ago

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?

antimagic• 13 years ago

More exactly, the kernel does provide a way for applications to mark memory pages as executable (which is exactly what Safari does, after all), but you need to have the right permissions to use the API, and App Store apps don't have those permissions...

general_failure2• 13 years ago

Agree with your comment mostly except for the android remark. I found iOS and cocoa terribly hard. Xcode is unusable and honestly the terms used in programming g like first responder are arcane. Android was much more approachable for me and java is quite sane compared to obj c.

eonil6• 13 years ago

It seems obvious that we have different linguistic taste.

Though I have used Eclipse for a while a few years ago, now I really can't go back to there.

untog• 13 years ago

I mean, what's better with JS than Objective-C with Xcode?

Cross-platform portability, for one. I know it's a long way off, but being able to use JS as a first-class language on all mobile platforms would be a fantastic step forwards.

eonil6• 13 years ago

IMO, it would be better to hire another Android developer with saved cost.

And why should we step to a language which cannot offer any benefit? Even if it happen, it seems just a huge step backward.

For portability, I don't think JS is portable. Because portability doesn't come from a language. It comes from implementations by platform vendors. It's purely up to how platform vendors support the compatible language and feature set implementation. JS itself has nothing special in portability. Though all the browser vendors are supporting JS, it doesn't mean native platform vendors are interested in JS.

For the real serious portability, I think the only choice are C/C++ which are the CURRENTLY AVAILABLE de facto portability layer on ANY platform while keeping most of the benefits I mentioned. Including mobiles, desktops, servers, game consoles, embedded devices and even on web-browsers. And also for any new unknown future platforms. C/C++ support is virtually promised due to its superior range of existing portability.

And intermixing them with Objective-C is literally natural, and far easier then JS.

general_failure2• 13 years ago

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

phoboslab3• 13 years ago

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

CodeWithCoffee• 13 years ago

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.

martin_• 13 years ago

Sounds very similar to http://www.cycript.org/

comex• 13 years ago

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• 13 years ago

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

eonil6• 13 years ago

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

http://iao.fi/myposts/uiwebview

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

cwp• 13 years ago

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• 13 years ago

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.

pdenya• 13 years ago

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.

sjtgraham2• 13 years ago

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• 13 years ago

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.

sjtgraham2• 13 years ago

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.

riq_• 13 years ago

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

tylerlarson• 13 years ago

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...

United857• 13 years ago

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.

Zelphyr3• 13 years ago

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• 13 years ago

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.

pflats2• 13 years ago

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.)

Zelphyr3• 13 years ago

It wasn't the top comment. 1 point. You just got lucky.

And I wasn't criticizing. At least that wasn't my intention. Though now I'm amused that you lament HN turning into a criticism machine by criticizing my inadvertent criticism ;)

I was just trying to understand what the author meant by "to surface" an object. Still wondering...

mattschmulen3• 13 years ago

Because the author is a bad writer, a very very bad writer :(

AsymetricCom• 13 years ago

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.

Apple’s iOS7 Native JavaScript Bridge

Related Stories