Apple’s iOS7 Native JavaScript Bridge(strongloop.com)
strongloop.com
Apple’s iOS7 Native JavaScript Bridge
http://strongloop.com/strongblog/apples-ios7-native-javascript-bridge/?
16 comments
Technically true, but Cocoa is proprietary. Is ObjC widely used for anything else?
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.
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.
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.
It's true that ObjC itself isn't what's proprietary, but Cocoa and Cocoa Touch are.
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?
You're absolutely right, I had forgotten that that was the original argument.
No it does not make the text correct, people often conflate ObjC and Cocoa. Thanks for mentioning Apportable.
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.
Cocotron [1] is another alternative that can target Windows and even Linux with some exceptions.
[1] http://www.cocotron.org
[1] http://www.cocotron.org
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.
Or, for that matter, C and C++
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.
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.
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.
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...
Even more exactly, there are ways but if you use them there is no way to publish on the App Store, because private API.
There is no reason not to have JIT or WebGL in a WebView other then apple not wanting you to, even though this was the original vision of the platform.
There is no reason not to have JIT or WebGL in a WebView other then apple not wanting you to, even though this was the original vision of the platform.
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?
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?
They might be able to support JIT by moving webkit out of process. I believe they do this now with the Mail UI. For more info see:
http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/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.
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.
But I doubt what will drive Apple to improve JS performance. Because making people to use Objective-C is a lot beneficial to Apple.
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.
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.
Can't predict the future -- but I do not think they will ever do it after talking to @radian at JSConf.EU.
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.
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.
Though I have used Eclipse for a while a few years ago, now I really can't go back to there.
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.
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.
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.
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.
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
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.
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.
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
[1] http://impactjs.com/ejecta
[2] https://itunes.apple.com/us/app/x-type/id597488149?mt=8
Yes I meant to come back to this comment and explain why people should watch it. What you said!
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.
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.
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.
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.
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
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
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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...
Sounds very similar to http://www.cycript.org/
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.
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.
Does anyone have benchmarks about JIT vs non-JIT Javascript on iOS 7? I'm interested, but haven't been able to locate any.
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.
http://iao.fi/myposts/uiwebview
The author is claiming the difference would be about 5x. I think that's reasonable.
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.
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.
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.
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.
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.)
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.)
Thank you for clarifying what to "surface" an object means. I'd never heard that before.
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...
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...
To 'surface' something (in this context) means something like "to expose", or "to bring to attention". It's related to the more literal meaning of the verb, which is roughly "to come up to the surface of the water (or other medium)", as in "the submarine surfaced after a week long dive". He's just using it to describe exposing objects and functions in Objective-C to the JavaScript context.
Because the author is a bad writer, a very very bad writer :(
Appcelerator cannot use v8 because v8 has no non-jit mode. Ios apps cannot jit...
Whitelisted Apps can. Mobile Safari for instance uses the JavaScriptCore JIT; Chrome however does not, despite using Apple's built-in WebView.
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.
An entitlement.
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.
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.