15 ms·

Just use JavaScript. Javascriptcore is a lightweight way to execute JavaScript on iOS and you can use V8 context or duktape on Android. This way you can also u

Just use JavaScript. Javascriptcore is a lightweight way to execute JavaScript on iOS and you can use V8 context or duktape on Android. This way you can also update code in your app without an app store update.

auggierose 7y ago
which is not allowed on iOS ... Edit: Sorry for being unclear, was only referring to the updating JS on the fly and circumventing App Store part. Obviously (facepalm) ... ️
- jaredsohn 7y ago
  Which part isn't allowed? A project I worked on did this a few years ago.
  - mcraiha 7y ago
    I think there is some confusion around this. You can use Javascript with iOS if you use Webkit + JavaScript Core, and ship all your features in the binary that your app uses. 2.5.2 "Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps." and 4.7 " your app must use WebKit and JavaScript Core to run third-party software and should not attempt to extend or expose native platform APIs to third-party software"
- robjan 7y ago
  What specifically is not allowed? Microsoft provide CodePush as a service which allows you to push updated JavaScript bundles to Android and iOS apps.
- lultimouomo 7y ago
  It is totally allowed on iOS. Perhaps your thinking about downloading such JS code at runtime from your servers, thus escaping Apple's control on the app, which was indeed forbidden (it is now ok as long as you don't drastically change the app) Bundling JS in the app and running it has always been just fine.
je42 7y ago
Supporting a JS Engine is non-trivial. See React Native and Native Script. For example stacktraces etc. With C++ in both Android Studio and X-Code you can put break points in the same IDE. With JS you would use the browser to debug JS code, and Android Studio and X-Code to debug the native code. That split can be annoying. I guess if the team that supports the JS engine is sufficiently large, i guess you can get more out shared JS code. The majority of the devs should be able to focus on JS development only. And a couple of specialists deal with "JS engine issues".

auggierose 7y ago

which is not allowed on iOS ... Edit: Sorry for being unclear, was only referring to the updating JS on the fly and circumventing App Store part. Obviously (facepalm) ... ️

jaredsohn 7y ago
Which part isn't allowed? A project I worked on did this a few years ago.
- mcraiha 7y ago
  I think there is some confusion around this. You can use Javascript with iOS if you use Webkit + JavaScript Core, and ship all your features in the binary that your app uses. 2.5.2 "Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps." and 4.7 " your app must use WebKit and JavaScript Core to run third-party software and should not attempt to extend or expose native platform APIs to third-party software"
robjan 7y ago
What specifically is not allowed? Microsoft provide CodePush as a service which allows you to push updated JavaScript bundles to Android and iOS apps.
lultimouomo 7y ago
It is totally allowed on iOS. Perhaps your thinking about downloading such JS code at runtime from your servers, thus escaping Apple's control on the app, which was indeed forbidden (it is now ok as long as you don't drastically change the app) Bundling JS in the app and running it has always been just fine.

je42 7y ago

Supporting a JS Engine is non-trivial. See React Native and Native Script. For example stacktraces etc. With C++ in both Android Studio and X-Code you can put break points in the same IDE. With JS you would use the browser to debug JS code, and Android Studio and X-Code to debug the native code. That split can be annoying. I guess if the team that supports the JS engine is sufficiently large, i guess you can get more out shared JS code. The majority of the devs should be able to focus on JS development only. And a couple of specialists deal with "JS engine issues".