AFAIK the only way Apple can enable Nitro for 3rd party apps without enabling executable memory pages generally is by separating JavaScriptCore (and WebKit render engine) into separate processes (ala WebKit2 / Chrome) which are allowed to create executable memory pages.

Then, of course, there is no way to create bindings between your code and the JavaScript interpreter (at least not without the overhead of IPC, which would probably negate any benefits of enabling Nitro).

So yeah, I wouldn't hold my breath.

I am super glad he has released this. He is not joking about compiling javascript core for iOS being painful, I dumped many hours into it. It would have been nice of him to release the project files just for jsc under MIT or something, but I guess people have to make money somehow.

Since JavaScriptCore is LGPL, you could probably demand them from him after buying some app that uses this.

"For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library."

So we could demand the project files to build it for iOS directly from Apple then? :)

Anyway, I will tidy up and release the project files and patches for JSC in a couple of days. My selling point is the game engine and the OpenGL Canvas abstraction, not JSC.

> So we could demand the project files to build it for iOS directly from Apple then? :)

Yes?

http://opensource.apple.com/source/JavaScriptCore/JavaScript...

It's from iOS 4.2 (http://opensource.apple.com/release/ios-42/), as JSC's source in iOS 4.3 is marked as "coming soon" (http://opensource.apple.com/release/ios-43/).

helpful, thanks.

Appcelerator's Titanium uses JavaScriptCore as well to create native bindings to UIKit. Titanium is not a UIWebView wrapper per se, although that is one of many UIViews you can create and embed web apps. The result is a much more "native" experience and tighter integration to platform capabilities.

also see ngcore, a JavaScript gaming framework that uses OpenGL under the hood. It's maintained by ngmoco:)

Also Game Closure: http://www.gameclosure.com/ http://techcrunch.com/2011/02/17/game-closure-makes-it-a-bre...

This is commercial though right? I mean it's not open source that I can just dl an Xcode project and play around with, it's hosted by them or something like that?

It is commercial, but it is also open source. If you have a license for the game engine, you will get the whole source code for the project and can do whatever you want with it.

> Which leaves me to wonder why the JavaScriptCore library that comes with iOS is private in the first place.

Because the JavaScriptCore library is not finalized? I don't understand what there is to wonder about. Other than that point, I still think this is really awesome.

The API for JSC has stayed unchanged for years. JSC is a public library on OSX and there are thousands of Apps that rely on it.

The only reason it's not public on iOS is that Apple doesn't like scripting languages on a mobile device, as they are potentially slow and energy hungry. At least that's my guess.

However, it's possible to compile and use JSC as an interpreter, which is Even slower.

They won't let you use the private dynamic compiler, though, most probably for se urity reasons.

What on earth does that mean, "not finalized"? How is JavaScriptCore on iOS less "finalized" than the same library on every other platform?

I'm hoping he releases a guide (or at least the project files) for bundling JSC.

Correct me if I'm wrong: Titanium compiles to Objective-C.

This is, of course, different since it runs actual JavaScript code. Does Apple prohibit use of Titanium? Sorry I wasn't following this for some time.

Titanium uses JavaScriptCore as a runtime interpreter to bind to native Obj-C, which is in full compliance with Apple's policies regarding interpreted code (section 3.3.2).

Neat.

...but it's still violating the iOS developer agreement. Specifically the no interpreter rule except those provided by Apple. They probably didn't notice but blogging about it may get the apps pulled.

Take it from someone that has been on Apple's bad side: this is a bad idea and will probably get you pulled. They also don't like braggers that figured out ways around the rules.

I've dealt with these things. There are few options though. Compiling to native (in a AOT style) is one way, (ala MonoTouch and Adobe's Flash Convert tools). The other is just embedding a UIWebView somewhere (even if it's not visible) and IPCing over stringByEvaluatingJavaScriptFromString and URL change notifications.

The rule you reference no longer exists. You can run an interpreter as long as the code you're going to interpret is part of the app you submitted for review (i.e. you aren't allowed to use JavaScriptCore to run scripts off a web page, but your app can use any kind of interpreter it wants internally). The rule was horribly misguided and never really enforced — many of the top apps have always embedded scripting languages.

Interesting... You're correct. I wonder when that changed. THIS CHANGES EVERYTHING

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

The rule was however enforced. My own app was pulled for it a year ago for embedding an little tiny Lua interpreter for handling a few game logic changes.

The question is still interpreted code that is not included with the app but written by the user in the app. I used to work for TI programming graphing calculators a couple jobs back. I always wondered if we could do a port of one of the later generation calculators to iPhone but I always stopped at TI-Basic or if our CAS engine could be considered an interpretor. Now given the rule change, would user entered code still be considered against the rules. It wouldn't be code shipped with the app... but still.

Code written by the user is still forbidden, though Apple are really sketchy as to what they consider "external interpreted code" versus just "a document." To a large degree, it seems like a question of marketing. If the feature feels like writing a program, the reviewers will reject it. I am not sure how sophisticated the calculator you're thinking of is. It's possible Apple could see it as just storing formulae, which they'd be OK with. Tough to say.

(And for anyone who thinks I'm splitting hairs: The line between "document" and "program" really is fuzzy. For example, Little Big Planet's game engine turns out to be Turing-complete, so you can build a working computer in the level editor out of game objects. See here for more: http://forums.xkcd.com/viewtopic.php?f=12&t=57034 )

No, it's not. iScheme is in the store and its only purpose is to evaluate code entered by the user. (http://itunes.apple.com/us/app/ischeme/id395305584?mt=8)

Also Pixie Scheme ( http://web.mac.com/Jay_Reynolds_Freeman/My/Pixie_Scheme_III.... ) - which has the notion of a persistent "world", but does not allow code to be loaded from external files.

That's very odd. I was sure I remembered somebody getting rejected very recently for running code written by the user. I must have been dreaming. Thanks for the correction.

iOS[1] is Apple's mobile operating system. IOS is Cisco's Internetworking Operating System[2]

[1] http://en.wikipedia.org/wiki/IOS_(Apple)

[2] http://en.wikipedia.org/wiki/Cisco_IOS

HN autocapitalizes the first letter of submissions. So it's most likely not the submitter's mistake.

Huh, didn't know that, thanks.