Skip to main content

Working natively with JavaScript in iOS and Android without WebView

Using JavaScript code from native code without using a WebView (sic!) can be really useful to

  • introduce dynamic functionality that was updatable without need of updating the app
  • shorter iteration cycles
  • share code between backend and native iOS and Android apps
You can have business logic provided by a JavaScript that then controls the app that inject native functionality in the JavaScript context.
You could even write an A/B testing framework based on this approach.


iOS
iOS offers the native JavaScriptCore:
Evaluate JavaScript programs from within an app, and support JavaScript scripting of your app.

So you can evaluate a script and read its return value natively:

context.evaluateScript(myLib);
let result = context.evaluateScript("myFunction();")
let myFunction = context.objectForKeyedSubscription("myFunction");
let parametrizedResult = myFunction.invokeMethod(...)

Or you can inject a native object into the JavaScript engine:
@objc protocol MyJSProtocol: JSExport {
    var myVar: String {get set}
}

@objc class MyObject: NSObject, MyJSProtocol {
   dynamic var myVar: String
}

...
context.setObject(MyObject.self, forKeyedSubscript: "MyObject")

Documentation JavaScriptCore


Android
For Android there are methods to inject native objects into the JavaScript context in a WebView; but you always have to initiate a WebView which is pretty heavy-weight.

There are third party libs that fill this gap:

  1. J2V8, a Java wrapper around Google’s V8 JavaScript engine.
  2. JS Evaluator for Android, based around the native Android WebView.
  3. AndroidJSCore, a Java wrapper around the WebKit JavaScriptCore engine.
  4. Duktape Android, the Duktape embeddable JavaScript engine packaged for Android.
Most stable and best performing candidate proved to be J2V8.

Comments

  1. An Android app in JavaScript sounds like a fascinating approach to mobile development. Leveraging JavaScript allows developers to utilize their existing web development skills and tools, potentially streamlining the process. However, I'm curious about performance and native device integration. How does the app handle hardware features? Security concerns also come to mind. Nonetheless, it's an exciting prospect that opens up new possibilities. I'd love to see a detailed comparison with traditional Android development to better understand its benefits and limitations. Great post!

    ReplyDelete

Post a Comment

Most Favorite Posts

Google Drive versus Dropbox

MacWorld: Online Storage Face-Off: Google Drive vs. Dropbox

CloudApp

CloudApp allows you to share images, links, music, videos and files. Here is how it works: choose a file, drag it to the menubar and let us take care of the rest. We provide you with a short link automatically copied to your clipboard that you can use to share your upload with co-workers and friends. Additionally you can view, track and delete files right from your menubar. CloudApp

Server-driven UI (SDUI): Meet Zalandos AppCraft and AirBnB Lona

A short WTF: Joe Birch:  SERVER DRIVEN UI, PART 1: THE CONCEPT Zalando seems to follow the SDUI principle as well - defining a common design language and construct the screens on the backend while displaying them natively on the clients. They even go one step further; they implemented a mighty toolset to enable non-technical stakeholders to define their own native app screens Compass: Web tooling to create screens and bind data Beetroot: Backend service that combines the screen layout definition with the data Lapis/Golem: iOS/Android UI render engines Crazy cool! Good job, guys (when you do an open-source release?) To even move faster a Flutter based UI render engine implementation was great! See also AirBnB Lona SDUI approach Building a Visual Language Why Dropbox sunsetted its universal C++ mobile project and AirBnB its React Native implementation

CFPropertyList

The PHP implementation of Apple's PropertyList plist can handle XML PropertyLists as well as binary PropertyLists. It offers functionality to easily convert data between worlds, e.g. recalculating timestamps from unix epoch to apple epoch and vice versa. A feature to automagically create (guess) the plist structure from a normal PHP data structure will help you dump your data to plist in no time. github

j2obc - A Java to iOS Objective-C translation tool and runtime

What J2ObjC Is J2ObjC is an open-source command-line tool from Google that translates Java code to Objective-C for the iOS (iPhone/iPad) platform. This tool enables Java code to be part of an iOS application's build, as no editing of the generated files is necessary. The goal is to write an app's non-UI code (such as data access, or application logic) in Java, which is then shared by web apps (using GWT), Android apps, and iOS apps. J2ObjC supports most Java language and runtime features required by client-side application developers, including exceptions, inner and anonymous classes, generic types, threads and reflection. JUnit test translation and execution is also supported. J2ObjC is currently between alpha and beta quality. Several Google projects rely on it, but when new projects first start working with it, they usually find new bugs to be fixed. Apparently every Java developer has a slightly different way of using Java, and the tool hasn't translated all possib...

App Indexing

A better search experience for apps and users with linking to in-app content. Google is working with app developers and webmasters to index the content of apps and relate them to websites. When relevant, Google Search results on Android will include deep links to apps. App Indexing

In-App Purchase Receipt Validation on iOS

A vulnerability has been discovered in iOS 5.1 and earlier related to validating in-app purchase receipts by connecting to the App Store server directly from an iOS device. An attacker can alter the DNS table to redirect these requests to a server controlled by the attacker. Using a certificate authority controlled by the attacker and installed on the device by the user, the attacker can issue a SSL certificate that fraudulently identifies the attacker’s server as an App Store server. When this fraudulent server is asked to validate an invalid receipt, it responds as if the receipt were valid. iOS 6 will address this vulnerability. If your app follows the best practices described below then it is not affected by this attack. iOS Developer Library In-App-Klau jetzt auch im Mac App Store ( Heise )