5 ms·

IOS games using JavaScriptCore without WebKit

141 points by joehewitt 15y ago

jonbro 15y ago
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.
- comex 15y ago
  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."
  - phoboslab 15y ago
    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.
    - gord 15y ago
      helpful, thanks.
    - pluies_public 15y ago
      > So we could demand the project files to build it for iOS directly from Apple then? :) Yes? http://opensource.apple.com/source/JavaScriptCore/JavaScriptCore-621.1/ http://opensource.apple.com/source/JavaScriptCore/JavaScript... It's from iOS 4.2 (http://opensource.apple.com/release/ios-42/ 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/ http://opensource.apple.com/release/ios-43/).
zbowling 15y ago
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.
- chc 15y ago
  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.
  - zbowling 15y ago
    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.
efnx 15y ago
I'm hoping he releases a guide (or at least the project files) for bundling JSC.
tlrobinson 15y ago
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.
richcollins 15y ago
also see ngcore, a JavaScript gaming framework that uses OpenGL under the hood. It's maintained by ngmoco:)
- swix 15y ago
  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?
  - phoboslab 15y ago
    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.
- tlrobinson 15y ago
  Also Game Closure: http://www.gameclosure.com/ http://www.gameclosure.com/ http://techcrunch.com/2011/02/17/game-closure-makes-it-a-breeze-to-build-multiplayer-cross-platform-games/ http://techcrunch.com/2011/02/17/game-closure-makes-it-a-bre...
tzm 15y ago
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.
NSMeta 15y ago
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.
- tzm 15y ago
  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).
Locke1689 15y ago
iOS[1] is Apple's mobile operating system. IOS is Cisco's Internetworking Operating System[2] [1] http://en.wikipedia.org/wiki/IOS_(Apple) http://en.wikipedia.org/wiki/IOS_(Apple) [2] http://en.wikipedia.org/wiki/Cisco_IOS http://en.wikipedia.org/wiki/Cisco_IOS
- wahnfrieden 15y ago
  HN autocapitalizes the first letter of submissions. So it's most likely not the submitter's mistake.
  - Locke1689 15y ago
    Huh, didn't know that, thanks.
alanfalcon 15y ago
> 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.
- chc 15y ago
  What on earth does that mean, "not finalized"? How is JavaScriptCore on iOS less "finalized" than the same library on every other platform?
- phoboslab 15y ago
  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.
  - pygy_ 15y ago
    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.

141 points by joehewitt 15y ago

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.

comex 15y ago
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."
- phoboslab 15y ago
  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.
  - gord 15y ago
    helpful, thanks.
  - pluies_public 15y ago
    > So we could demand the project files to build it for iOS directly from Apple then? :) Yes? http://opensource.apple.com/source/JavaScriptCore/JavaScriptCore-621.1/ http://opensource.apple.com/source/JavaScriptCore/JavaScript... It's from iOS 4.2 (http://opensource.apple.com/release/ios-42/ 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/ http://opensource.apple.com/release/ios-43/).

zbowling 15y ago

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.

chc 15y ago
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.
- zbowling 15y ago
  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.

efnx 15y ago

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

tlrobinson 15y ago

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.

richcollins 15y ago

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

swix 15y ago
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?
- phoboslab 15y ago
  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.
tlrobinson 15y ago
Also Game Closure: http://www.gameclosure.com/ http://www.gameclosure.com/ http://techcrunch.com/2011/02/17/game-closure-makes-it-a-breeze-to-build-multiplayer-cross-platform-games/ http://techcrunch.com/2011/02/17/game-closure-makes-it-a-bre...

tzm 15y ago

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.

NSMeta 15y ago

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.

tzm 15y ago
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).

Locke1689 15y ago

iOS[1] is Apple's mobile operating system. IOS is Cisco's Internetworking Operating System[2] [1] http://en.wikipedia.org/wiki/IOS_(Apple) http://en.wikipedia.org/wiki/IOS_(Apple) [2] http://en.wikipedia.org/wiki/Cisco_IOS http://en.wikipedia.org/wiki/Cisco_IOS

wahnfrieden 15y ago
HN autocapitalizes the first letter of submissions. So it's most likely not the submitter's mistake.
- Locke1689 15y ago
  Huh, didn't know that, thanks.

alanfalcon 15y ago

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

chc 15y ago
What on earth does that mean, "not finalized"? How is JavaScriptCore on iOS less "finalized" than the same library on every other platform?
phoboslab 15y ago
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.
- pygy_ 15y ago
  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.