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

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

Judo App - Server Driven UI out of the box

Judo App Judo brings server-driven UI to your iOS and Android apps. Build user interfaces visually in a fraction of time and publish them instantly without submitting to the app store. Build Experiences - With No Code The Judo app for macOS, available through the App Store, is built for design professionals with common keyboard shortcuts and familiar concepts like canvas, layers and inspector panel. Workflow is streamlined with the ability to drag and drop media files directly into your experiences and manage your own Judo files in Finder. Manage Creative Execution A Judo experience is interactive and can include text, images, video and buttons. An experience may be part of a screen, a single screen, or more typically multiple linked screens. Judo supports screen transitions, carousels, horizontal scrolling and modals. Clients can add custom fonts and define global colors and these are updates applied universally. Effortlessly Deploy Judo Cloud syncs your experiences with your iOS and ...

Xamarin and MvvmCross

Xamarin Create Native iOS, Android, Mac and Windows apps in C# Xamarin delivers high performance compiled code with full access to all the native APIs so you can create native apps with device-specific experiences. Anything you can do in Objective-C or Java, you can do in C# with Xamarin. Xamarin MvvmCross for Xamarin This project provides a cross-platform mvvm mobile development framework built on top of: Silverlight for WP7, WP8 Mono for Android (or Xamarin.Android) MonoTouch for iOS (or Xamarin.iOS) the WinRT XAML framework for Windows 8 Store apps. WPF Mono for Mac (or Xamarin.Mac) This project makes extensive use of Portable Class Libraries to provide maintainable cross platform C# native applications. GitHub

The End of the Apps as we now them

The experience of our primary mobile screen being a bank of app icons that lead to independent destinations is dying. And that changes what we need to design and build. The idea of having a screen full of icons, representing independent apps, that need to be opened to experience them, is making less and less sense. The idea that these apps sit in the background, pushing content into a central experience, is making more and more sense. That central experience may be something that looks like a notification centre today, or something similar to Google Now, or something entirely new. Intercom.io

Alpha Apps vs. App Unbundling

Aktuell wird viel über das Modell der "Alpha Apps" und "App Unbundling" gesprochen. Hier kurz eine Übersicht und meine 5 cents: Alpha Apps Die chinesische App WeChat geht noch weiter: Neben einem Messenger, vergleichbar mit WhatsApp, bietet sie einen Lieferdienst à la Lieferando, die Möglichkeit etwa das eigene Konto zu checken (wie sonst bei der Bank-App) und gleichzeitig die Chance etwa Promis zu folgen, wie es Twitter bietet. Solche Alpha-Apps können dadurch verschiedene Aspekte und Möglichkeiten des Internets verbinden und werden so zum idealen Zugangsportal zum Netz – so wie traditionell der Browser am Computer. Den Tod des Browsers bedeutet das aber noch lange nicht. Der Browser ist tot, es lebe der Browser! Wirtschafts Woche App Unbundling Unbundling steht für das Unterteilen von Apps oder verschiedener Funktionen in mehrere, eigenständige Applikationen. Aber nicht jede Unbundling Aktion wird positiv von Usern aufgenommen. Facebook Messenger ...

iPad HTTP Debugging with Charles

After noticing that the caching in iPad Safari seemed a little funky, I made an effort to decipher some of the logic used by the browser cache. I didn’t get very far, but in the process I figured out how to route my iPad HTTP traffic through a web debugger on my laptop. It turns out it was very easy to do (although I’m sure there is a more complicated way to go about it). What follows is a simple step-by-step for connecting your iPad to an HTTP debugging proxy. The main requirement is that your desktop/laptop and iPad be on the same wireless network. Then it’s just a matter of telling your iPad to use your desktop as an HTTP proxy. iPad HTTP Debugging with Charles

Android with Kotlin, iOS with Swift, Kotlin Native, flutter.io, React Native, PWA, Xamarin, Hybrid - which way to go?

Currently there are tons of frameworks how to get your business model to the user... and in the app store Full Native Android with Kotlin, iOS with Swift Deepest integration Single way to make sure that you have no lock-in effect with a framework, and you are f**ed, when Apple or Google disallows the usage of a specific technology... Two teams required 2x code PWA (Progressive Web App) Write offline- and push-capable PWA with web-technologies only Some native features might require hybrid native development and bridging (like In-App purchases, AR, ...) In best case: One web team only for website and app Maybe some native specialists for special features Kotlin Native Develop a shared framework with or without UI using Kotlin Native Additional native code will most probably be required Big Android team, small iOS specialists flutter.io (React Native | Xamarin | ... ) One codebase (flutter: Dart, React Native: JavaScript, Xamarin: C#) Additional native code ...