[Development] V8 on iOS
ian at mediator-software.com
Fri Mar 30 14:24:46 CEST 2012
The first tentative steps for getting iOS support into Qt5 have been made (
really it's only a few small patches to get the build working - there's nothing
run through their engine - which is only available as part of their browser
implementation), but let's ignore that for now and just concentrate on the
technical issues... There's also not much value in pursuing "jail break"
solutions, so let's ignore any solution which would be "jail break" only.
The iOS platform (as shipped to end-users) has a high level of security, with
applications needing to be signed, provisioned etc. before the shell will even
load them. Once loaded, the app runs at a reduced priviledge level (as the user
'mobile' IIRC). One of the priviledges which the app is not granted is the
ability to execute memory that has been marked as 'data', nor is it able to
allocate memory for 'code'. There is an iOS function 'mprotect' which can be
used to change execution priviledges for 'data' memory. Unfortunately, the
default provisioning for the app does not give it rights to call 'mprotect'. It
is possible to hack the provisioning (when packaging the app) to allow
'mprotect' to be called, but it's very unlikely that Apple would allow such an
application into the App Store (as mprotect is considered to be a private API,
and the hacked provisioning would be suspicious to them too).
There is another (possibly even bigger) issue in the ARM BI used by Apple on iOS.
It's not EABI (which AFAIK V8 on ARM is written for), and it's not even
documented AFAIK, so even though it's similar to EABI (from what I've seen so
far), it's not the same, which means that it may not even be feasible to port
V8 to iOS anyway (even without the priviledge issues).
As this is a bit of a show-stopper as far as I'm concerned (as a widget-only
version of Qt5 doesn't add any value over a widget and QML version of Qt4.8),
I'm not seeing any point in doing a Qt5 port to iOS if V8 is a hard requirement
(unless the above issues can be resolved somehow).
So I guess the question is: Is there any plan in place for platforms that are
not (for whatever reason) able to use V8 (which AFAIK would rule out QML2 and SG)?
Or maybe some way to use the interpreter from Qt4.8?
Please excuse any mistakes in terminology etc., I haven't been looking into
porting V8 to iOS that much yet (although I've done the preliminary steps which
enable it to build, it would probably crash and burn if run due to the memory
protection and ARM BI issues).
There's no platform plugin yet either, so no way to even test V8 on iOS AFAIK.
If anyone knows a way to test V8 without GUI, Declarative or OpenGL, then that
may be a starting point at least, because IMHO there's no point in starting a
platform plugin until this issue is resolved.
Thanks for your input,
More information about the Development