
WKWebView, an Electron alternative on macOS/iOS - ingve
https://holtwick.de/blog/2018-12-20-web-technologies
======
anaisbetts
This is literally what Slack moved from years ago, because it was very
problematic, let me tell you why since I'm the one who did it.

* Adding new APIs was a huge pain in the ass, you had to write all of this ugly bridge code in Objective C, and the APIs ended up being super unnatural on the JS side. As a result, desktop integration wasn't done much since it felt like a "Black Magic" type thing. Writing new APIs in Electron is Just JavaScript, so you can make something much more natural.

* We could literally do fuck-all for people running old versions of macOS - you _can 't_ upgrade Safari on old machines, you just Get What You Get. For awhile, every YouTube video on older macOS versions had a pink shade to it. Users write in, "This is clearly wrong!" "Yep, but we can't fix it. Sorry."

* And big spoiler - WKWebView uses _basically_ the same amount of memory give-or-take a few MBs as Chromium. It's the _content_ that sets the memory usage bar, not the host.

~~~
briandear
Why doesn’t Slack write an actual Mac app in Swift? For small companies with
limited resources, I understand the attraction of “cross platform,” but it
would seem that performance and uasability would be vastly improved by writing
actual native applications — especially for a billion dollar company that can
afford to do it and especially since Slack is one of those apps that is
constantly open and performance and efficiency have a real benefit.

~~~
TeMPOraL
They've cornered the market and don't have to care anymore.

A lot of Slack's audience is captive - employees, contributors to open source
projects that chose Slack as their social outlet, etc.

~~~
Despegar
The only way this will change is if Apple starts using more "stick"
approaches. Marzipan and whatever other technologies they're working on are
the "carrot".

------
tiborsaas
If you throw out cross platform support it's hard to call it an alternative :)

~~~
saagarjha
It’s pretty cross-platform, if you swap out “WKWebView” with “your platform’s
native web view”.

~~~
rasengan
Just use gtk WebKit or qt WebKit and you’re good to go.

For the record, WebKit originated from KDE[1].

[1]
[https://en.m.wikipedia.org/wiki/WebKit](https://en.m.wikipedia.org/wiki/WebKit)

~~~
amyjess
Should be QtWebEngine now, as QtWebKit is deprecated.

~~~
sime2009
QtWebEngine embeds Chromium as its web engine, which means it is going to have
the same performance and disk size costs as Electron. The circle is now
complete and you might as well just use Electron.

~~~
abrowne
Agreed except each app won't need a copy of QtWebEngine on disk.

------
bunnycorn
It would be nice to have an Electron 100% compatible framework (drop-in
replacement) that instead of using Chrome, it would use Apple's webviews that
are of course based on WebKit.

It would be faster and take much less RAM, specially when multiple Apps are
open and they could use the shared library.

Also, now that Chromium is going to be part of Windows, the same would also be
a good idea, I think.

~~~
tokyodude
So, every time Apple updates WebKit your app breaks. We've gone through this
in the past. There are multiple reasons Electron is a win.

1\. It's cross platform

    
    
       Don't have to deal with the fact that Safari is missing these 12 APIs or has different edge cases
    

2\. It's stable after shipping

    
    
       Users get a new version only when you ship. If you use the native widget then users get a new (often broken) version on every update by a 3rd party (Apple/MS/Google). Example: chrome just deprecated autoplay. If that bubbled into apps your app just broke. Electron could do the same but if you're testing like a good dev that break wouldn't make it to users. You as a dev would find it locally, deal with it, and only after ship to users.
    

so, no personally I don't want a shared widget. that sounds like going back to
DLL hell or worse, just broken stuff.

~~~
heywire
Doesn’t stable after shipping also mean that if a critical vulnerability is
found in the version of electron/chromium that you’ve bundled, the user is
vulnerable until you are able to issue a fix? What if the app itself is no
longer updated?

~~~
tokyodude
How is that different than any native app? All native apps have that issue.

~~~
watermelon0
Native apps can benefit from using shared libraries, which can be updated in
such case. Using WKWebView ensures that vulnerabilities are patched as part of
OS updates.

On OSes with sane package managers (e.g. Linux distributions) native apps can
share all dependencies, so there is no need to recompile/redistribute each
application using affected library.

Sadly, there is no such thing on MacOS (excluding brew/port) and Windows (or
even iOS/Android), and even native Linux applications are moving towards
bundling all dependencies in a single package.

------
gok
This reads like someone hired a consulting firm to send out surveys asking why
people don't like Electron apps, without really understanding the problem.

None of the four bullet points actually address real issues. The security
problem isn't that Google is bad at security (they're among the best really).
The problem is that Javascript code is generally written with the expectation
that it will run in a web browser's highly locked down security context.
Performance is really the same issue: web apps are authored wastefully. For
use cases where you visit a web page for a few minutes then leave that's fine,
but when you then let that code run for hours with no sandbox you will
inevitably hit perf issues.

Write native apps. If you can't afford that, just make a web page.

~~~
izacus
Electron also has a lot of hardening features from chromium disabled as is
strongly discouraged by Google as unsafe to use for apps.

~~~
smaddock
This seems to be changing as of recently this year. There have been many
security-related changes including making options such as Node integration
disabled by default [1]. Support for renderer process sandbox is also
available [2].

[1]
[https://github.com/electron/electron/pull/14284](https://github.com/electron/electron/pull/14284)

[2] [https://electronjs.org/docs/api/sandbox-
option](https://electronjs.org/docs/api/sandbox-option)

------
shubhamjain
MacGap framework [1] builds on the same idea. In fact, it predates Electron
and was being used by Slack. The size of the compiled binary would be just
~350KB.

[1]:
[https://github.com/MacGapProject/MacGap2](https://github.com/MacGapProject/MacGap2)

~~~
Void_
Wow, I used this in 2012. I think it was originally written by Alex MacCaw of
Clearbit.

------
vidanay
I still live in the world of heavy desktop native apps (WinForms & WPF) and
one thing I've never been able to understand about all of these Electron
discussions is what benefit does Electron bring in the first place? Why not
simply run the application and connect to it using the local browser instance?
For convenience a link can be placed on the users desktop.

~~~
arcticwombat
It sells the dream of using web developer skills on the desktop, for those who
want to develop native apps but don't want to learn new tools/languages.

Square peg, round hole. Electron just gives you a hammer to make it fit anyway
:)

~~~
todd3834
It also sells the dream of writing an app that works on multiple platforms.
The web is good at this but depending on what your app does you might need
more. For instance, in Electron you have access to Node. This lets you do
things that you wouldn’t be able to do in the browser. It would let you do
lots of things but for example: access local file system, use SQLite or some
other storage without requiring a network connection, add an icon to the menu
bar or taskbar on Mac/Windows, you could even control a users mouse for
something like screen sharing.

~~~
arcticwombat
I write native applications, cross platform (I generally make releases for
Windows, Mac, and Linux), and cross-compiled using FPC + Lazarus.

No trickery, no hidden browser windows, just normal native executables.

Java also solves the cross-platform issue, though it's GUIs tend to not look
native (As opposed to Lazarus above, which is native).

If you're impressed by a webserver being able to interact with the OS for
things like accessing files or databases, your mind will be absolutely BLOWN
when you learn real native development.

~~~
todd3834
You’re making an assumption I haven’t already learned real native development
but that’s besides the point.

Java does solve part of this but some people would rather use JavaScript than
Java. Even if they know how to use both believe it or not.

However, if one of your platforms is the web browser, nothing is going to work
better than a web view if you want a cross platform solution. Slack for
example works almost exactly the same in my web browser as it does in
electron. If you want a solution that works on Linux, MacOS, and Windows AS
WELL as the web browser then the web view approach is pretty obvious.

Lastly the JavaScript web development experience is great with hot module
relacement and Chrome’s developer tools. Not to mention the JavaScript open
source community is amazingly strong and there is a lot of innovation going
on. To simply dismiss all of this because of personal reasons is fine by me
but I don’t agree with your view.

~~~
eschaton
“It works the same on the desktop as it does in my web browser” is an
indictment, not a feature. People use cross-platform toolkits because they
don’t want to do the work to fit in with the platform their user chose, not
because they confer any advantages to the user.

~~~
todd3834
That is certainly one way to look at it. I'll propose another way to see it:
There are always trade offs. For example, you could hire enough people to
simultaneously work on a Mac OS version, a Windows version, an iOS version, an
Android version and a web version of your product. Of course this is going to
cost a lot of money and this cost will be passed on to the users. If the users
prefer the subtle differences between the UI in platforms so much that they
would prefer to pay more for a product than that would be an advantage.
Otherwise that is a disadvantage. Potentially a really big disadvantage. There
is also a case to be made that some people would definitely want the product
to work the same in the web browser as it does on their desktop. Slack is a
good example of this. I don't want to learn a new user experience for the
moments when I'm on another machine without Slack installed and I just want to
respond to a comment quickly, I'm very happy the web experience and the
desktop experience are similar.

Making absolute statements about why people make certain choices or believing
them can definitely lead to false conclusions. People don't only use cross
platform toolkits because they do not want to do work. Sometimes it is the
best solution given the features and constraints. I like to think of it as
being pragmatic.

------
lazyjones
The web and its technologies are far from stable, cheap and simple to learn.
And browser-based UIs are pretty much where native UIs were 30 years ago, just
a bit slower.

Cross-platform: yes, if you ignore the fact that there are only 2 browsers
left, both being buggy and incomplete (as they've been for many years) and
with no other implementation in sight, or even remotely feasibly for small to
medium-sized companies or teams. Also they're so bloated and isolated from the
native environment that you might just as well install a Linux virtual machine
and call it a cross-platform UI.

No, thanks. I'll wait for a better cross-plattform UI solution.

~~~
diminish
> pretty much where native UIs were 30 years ago,

In reverse, I would argue, Hundreds of "Native UIs", most of them obsolete or
dead, have shown to be incapable to express cross-platform, flexible layout
capabilities of 1990s HTML/CSS combo.

The most recent, yearly updated mobile OSes appear to be cooler, however we'll
see in 10 years how they will end up.

~~~
lazyjones
> In reverse, I would argue, Hundreds of "Native UIs", most of them obsolete
> or dead, have shown to be incapable to express cross-platform, flexible
> layout capabilities of 1990s HTML/CSS combo.

But most haven't. If you want the capabilities of the HTML versions unable to
even center vertically or requiring invisible images to format tables, there
are plenty of UI to choose from. Qt, Wx are extremely capable nowadays.

------
tbrock
I don’t understand why the entire browser engine needs to be bundled with each
app.

Why not have libchrome or a libelectron that moves more slowly than chrome six
week release cycle (maybe do 6 months) then have apps build to it and share
the library.

~~~
lcnmrn
Developers target a runtime with very specific APIs. If the runtime changes
developers wouldn't even bother to write the apps.

If Electron apps would specify requirements instead of bundling the whole
runtime, you will have to wait for the runtime to be downloaded the first time
the app runs. You will still end up with multiple versions of the same runtime
running on your system.

~~~
tbrock
Is it possible to stabilize the runtime or is it moving too quickly?

~~~
DonHopkins
Not for all applications, but for enough applications to make it well worth
it.

------
interfixus
The most obvious Electron alternative on _any_ platform is of course doing
things the way we sort of used to: Get your toolkits and compilers out, your
hands dirty, and your integrity clean and code some honest to God desktop
applications.

If you absolutely need to do web primitives inside your app, well then, html
engines used to come in a few megabytes and no external deps. If your webcode
needs the entire Chromium monstrosity bundled in order to run, someone has
been doing something entirely wrong.

~~~
outadoc
The most obvious counter-argument: one shared codebase vs. your five.

Native is awesome when you have the money.

~~~
arcticwombat
Meh, I write cross platform applications, single code base, and compile to
native executables on Windows, Linux, and Mac with no problem and no extra
Chromium bloat.

FreePascal + Lazarus.

~~~
cztomsik
I've done delphi in the past but I haven't heard about it for a while. How big
is the community nowadays? What about libs? Package manager? Dependency-hell?
Unit-testing frameworks and other toolings? How easy is it to stop the whole
application and inspect everything, evaluate some code in parent stack and see
if the issue was resolved so that you know exactly what to do?

It's not only about GUI designer and fast cross-platform compiler.

~~~
arcticwombat
Online package manager can search, download, and install packages.

I have libs/packages for everything I need, dunno about your needs.

Not sure about the community size but it's plenty big and plenty helpful, lots
of cool new stuff going on.

Plenty of debuggers available and you can pause things and inspect stuff.

Lazarus has seen loads of updates the last few years, it's worth taking the
time to set it up to fit your needs and learn the shortcuts.

------
arcticwombat
Let's move away from hiding browsers in windows and pretending they're not
browsers hiding in a window.

FPC + Lazarus, native executables, cross platform.

~~~
throwahoy
You’ve mentioned this several times now as though it’s some magic sauce that
everybody is missing.

But it’s not like FPC/Lazarus is the only portable GUI solution — Qt, Fox,
Swing, SWT, Gtk etc. also exist, and don’t require a fringe language (and I
say that as someone who did Turbo/Borland Pascal and Delphi development for
more than a decade). What Lazarus offers is a Delphi-type form builder tool,
but that seems a lot less interesting in this day and age of heavily
customized UIs that aren’t static grids of square components — in particular,
we increasingly rely on responsive layouts and smooth animations between them.

Moreover, I’ve yet to see a FPC app (or any app for that matter that isn’t
Electron or web) that doesn’t look like an old fashioned Windows-style GUI
app. Do you have any examples?

~~~
arcticwombat
It's not magic sauce, it's a counter-point to the "Electron gives you cross
platform deployments" argument.

Yes, there are many GUI toolkits, the LCL creates native applications while
some others do not, but it's certainly not the only one.

It's the one I prefer so I use it as an example over QT, Swing, JavaFX, etc.

Lazarus form builder let's you create forms very quickly and easy, and OS
themed design.

If you want other types of GUI designs you can do that too, though personally
I prefer standard OS design.

As far as static grids and square components, I think you're looking at old
stuff..

You can make things as squiggly as you like, and of course you can always use
images and colors to design your GUI and let your imagination run wild, and
it'll look entirely non-native.

Responsive design isn't that challenging either, use anchors and smart design.

I don't have any examples of desktop applications I've made, that look like
web-apps, no, but I might make some after you giving me this idea, and I'll be
doing it with FPC/Lazarus.

~~~
throwahoy
I’m still not convinced that it’s relevant to the discussion — it’s an old-
school GUI builder, Electron isn’t, and it’s a bit of an apples-to-oranges
comparison.

People gravitate to Electron not just because you can’t build cross-platform
apps in it, but _because the underlying UI tech is just the web_. You can even
do as Slack did, which is to offer the exact same app in the browser. You
can’t do that with FPC/Lazarus. The latter is geared towards fairly static
layouts, not the kinds of snappy, fluid, single-window apps that Electron is
used to build. It’s just a very different world.

Nobody is doubting that you can build decent Windows-style apps with
FPC/Lazarus, just as they’re not doubting that you can do it with Qt.

~~~
arcticwombat
It's arguably the most advanced gui builder available.

As for snappy, fluid, single-window apps that is 100% doable and up to the gui
developer.

It's not hard to use groups and switch between views, and make things
dynamically resize or move around.

------
SiDevesh
Recently there has also been some interest in making chrome usable as a
runtime to load web content as/in native apps, especially since with native
webview the experience would vary across different platforms (windows 10 below
will try to load it on ie!), i was working on
[https://github.com/SiDevesh/Quark-Go](https://github.com/SiDevesh/Quark-Go)
using the cool
[https://github.com/zserge/webview](https://github.com/zserge/webview)
library, recently started redoing it with
[https://github.com/GoogleChromeLabs/carlo](https://github.com/GoogleChromeLabs/carlo)

------
bunnycorn
The author is wrong in one point, Electron is not based on Chrome, it's based
on Chromium, and you don't need to trust Google because it's 100% open source.

~~~
___alt
By default, Chromium still integrates heavily with Google services. See
project ungoogled-chromium for details: [https://github.com/Eloston/ungoogled-
chromium](https://github.com/Eloston/ungoogled-chromium)

~~~
hannasanarion
Since when does electron make you log in with Google?

~~~
pritambaral
Integration with Google services does not require logging in to Google
services.

For a benign example: using Google search

For a less benign example: your browser/device/network being tracked for ads
when using Google search

~~~
hannasanarion
Electron is not a search engine or a browser, and it does not serve ads.

~~~
pritambaral
Google Play Services (on Android) is not a search engine or a browser, either.

Google Home does not serve ads, either.

My original comment's grand-parent did not claim if Electron was a browser or
a search-engine, or if it showed ads, just that it is not necessarily
independent of Google services just because it's built from Chromium.

------
ori_b
The problem with electron isn't electron -- it's the standards that it's built
on. Replacing one flavor of it with another doesn't move the needle
significantly.

------
PascalW
I posted this earlier in an Electron discussion, but there are a couple of
libraries that take this approach cross-platform, like zserge/webview [1] and
Tether [2].

[1] [https://github.com/zserge/webview](https://github.com/zserge/webview)

[2]
[https://github.com/quadrupleslap/tether](https://github.com/quadrupleslap/tether)

------
mgliwka
Rails Turbolinks utilizes this technique for iOS:
[https://github.com/turbolinks/turbolinks-
ios](https://github.com/turbolinks/turbolinks-ios)

Video explanation/demonstration:
[https://youtu.be/SWEts0rlezA](https://youtu.be/SWEts0rlezA)

------
mdhughes
Cross-platform is the key problem.

If I want to write a Mac-only app, I can do that in Objective-C/Cocoa, and be
quite happy.

For Linux, native means fighting with primitive C and X11 or Gtk, etc., which
I can do but I loathe it.

For Windows, I have no idea, C# maybe? I'd rather eat broken glass than
install Windows and find[ed.] out.

So if I'm doing cross-platform, my current working choices are Electron, Java,
FreePascal/Lazarus, or Scheme.

Electron's easy to build all three platforms on, performance is OK despite the
bloated example of Slack.

Java would need to bundle the JRE everywhere, and I've been largely Java-clean
for 10 years.

Lazarus is semi-broken on Mac currently, only 32-bit like stone age tools,
Cocoa port is unfinished. Maybe they'll get their shit together someday, I
like it when it works.

Scheme native binaries are hard and experimental, but getting better.

Using a WKWebView on Mac, then writing a completely different wrapper on Linux
& Windows, is unacceptable for my uses.

So my actual shipping code is Electron.

------
see-ya-99
Electron and other wrappers are just shit in my opinion as these consumes a
lot of precious resources.

Maybe devs instead of being lazy suckers could start to worry about this
aspect.

~~~
aaaaaaaaaab
Give it a few years. We’re at the limits of what’s photolitographically
possible with silicon. As soon as Moore’s law halts all this wasteful crap
will go down the shitter.

------
Entangled
This is perfect for writing compact and portable web apps. I built a basic
chrome that runs an index.html page and everything linkable after that and all
I have to do is inspect myweb.app file and change whatever html, css or js I
want. Simpler impossible. And with a little help from Swift I can have all the
power of macOS in my hands.

It is neither a hammer nor a nail, it just works for some specific purposes.

------
ynniv
This is how Apache Cordova (previously PhoneGap) works.

[[https://cordova.apache.org/](https://cordova.apache.org/)]

------
DonHopkins
WkWebView is a huge improvement over UIWebView on iOS or WebView on macOS.

However on macOS it is missing one important feature (to me at least) that
used to work with WebView:

You can't capture the image of the web browser window any more.

You used to be able to go something like:

    
    
        NSBitmapImageRep *bitmapdata = [view bitmapImageRepForCachingDisplayInRect: bounds];
        [webView cacheDisplayInRect: bounds toBitmapImageRep: bitmapdata];
    

Or:

    
    
        [NSView cacheDisplayInRect:(NSRect)rect toBitmapImageRep:(NSBitmapImageRep *)bitmapImageRep] 
    

But that's a synchronous API, and since WkWebView runs in another process, it
requires a remote procedure call, so Apple simply returns a blank image from
that call now.

[https://stackoverflow.com/questions/31969950/wkwebview-
cache...](https://stackoverflow.com/questions/31969950/wkwebview-
cachedisplayinrect-screenshot-in-os-x)

I think the iOS way of capturing a screen snapshot from WkWebView still works,
though, but I can't remember off the top of my head...

However, Apple added a new method to Safari, but last time I checked it was
only in the beta Safari and not supported in the version installed on the
operating system. (When you make a WkWebView it uses some specific framework
that's not necessarily the latest beta version of Safari you've installed.)

//iOS func takeSnapshot(with snapshotConfiguration: WKSnapshotConfiguration?,
completionHandler: @escaping (UIImage?, Error?) -> Void)

//macOS func takeSnapshot(with snapshotConfiguration:
WKSnapshotConfiguration?, completionHandler: @escaping (NSImage?, Error?) ->
Void)

But the problem with this method is that it takes a totally different
rendering path ("this is a software painted snapshot"), so some stuff may look
different, and WebGL stuff doesn't appear, and it's a whole lot slower than
cacheDisplayInRect used to be).

[https://stackoverflow.com/questions/46842384/wkwebkit-
takesn...](https://stackoverflow.com/questions/46842384/wkwebkit-
takesnapshotwith-snapshotconfiguration-not-working-on-ios-device)

This bug describes the problem and the issues and the less-than-ideal
solution:

[https://bugs.webkit.org/show_bug.cgi?id=161450](https://bugs.webkit.org/show_bug.cgi?id=161450)

Summary: [Cocoa] No reliable way to get a snapshot of WKWebView

~~~
ken
I hear a lot that WKWebView is an improvement, but all I see are some pretty
significant limitations compared to WebView:

\- no screenshots

\- no printing

\- no user stylesheets

\- no cmd-F find

\- no delegate method for hover-over-link

\- no access to container NSScrollView (on macOS)

\- harder to customize context menu (AFAICT)

\- ignores URLProtocols (10.13 added a new way to implement custom protocols
for WKWebViews with a completely different interface than
NSURLProtocol/WebView)

I'm dreading the day when Apple is going to require me to 'upgrade' my WebView
to WKWebView.

All I want to do is supply a byte stream containing HTML, and have it
displayed in an NSView, with standard features. This doesn't seem like an
obscure case, or a difficult problem. I don't understand why none of Apple's
web views ever had simply a load(stream:NSInputStream) method. This was hard
with WebView, and WKWebView made it a lot harder.

~~~
DonHopkins
Yes, it's a mixed bag with some things better and others worse. But having a
great JavaScript engine with the JIT enabled is pretty important for many
applications.

But breaking up the browser into different processes and communicating via
messages and sharing textures in GPU memory between processes (IOSurface,
GL_TEXTURE_EXTERNAL_OES, etc) is the inextricable direction of progress, what
all the browsers are doing now, and why for example Firefox had to make so
many old single-process XP-COM xulrunner plug-ins obsolete.

IOSurface:

[https://developer.apple.com/documentation/iosurface?language...](https://developer.apple.com/documentation/iosurface?language=objc)

[https://shapeof.com/archives/2017/12/moving_to_metal_episode...](https://shapeof.com/archives/2017/12/moving_to_metal_episode_iii.html)

GL_TEXTURE_EXTERNAL_OES:

[https://developer.android.com/reference/android/graphics/Sur...](https://developer.android.com/reference/android/graphics/SurfaceTexture)

[http://www.felixjones.co.uk/neo%20website/Android_View/](http://www.felixjones.co.uk/neo%20website/Android_View/)

~~~
pcwalton
Chrome and Firefox with WebRender are going the opposite direction and just
putting all their rendering in the chrome process/"GPU process" to begin with.

~~~
DonHopkins
Yes I know, that's exactly what I meant by "breaking up the browser into
different processes". They used to all be in the same process. Now they're in
different processes, and communicate via messages and shared GPU memory using
platform specific APIs like IOSurface. So it's no longer possible to write an
XP/COM plugin for the browser in C++, and call it from the renderer, because
it's running in a different process, so you have to send messages and use
shared memory instead. But then if the renderer crashes, the entire browser
doesn't crash.

------
yakubin
> It is cheap

And so the results look cheap.

------
jbverschoor
Emm... nativescript?

~~~
DonHopkins
NativeScript is cool -- I really like it.

But as far as I understand it, there's a bit of a fatal problem going forward
on iOS, last time I looked at it a year or so ago (I'd be thrilled if they've
come up with a way to address this problem):

The iOS NativeScript bridge uses the old deprecated UIWebView and
JavaScriptCore's Objective C integration stuff that lets you directly call
back and forth between Objective C and JavaScript.

However, that Objective C bridging stuff is not supported on WkWebView, since
it runs in a separate process, and has a different way of sending messages to
the web browser, but not calling native code directly or passing pointers to
objects or buffers in memory.

Why would you want to do that? To get direct access to an array of binary
floating point numbers, or the pixels of a canvas or WebGL texture, instead of
converting to and from JSON, or serializing images as data urls with base 64
encoded png files, for example. (Yech!)

You can send messages back and forth to WkWebKit, but that's vastly less
performant than the direct calling UIWebKit JavaScriptCore bridging stuff,
which operates in the same process and memory space.

And the NativeScript iOS integration layer is totally dependent (built on top
of) on the way the JavaScriptCore bridging stuff works, and would have to be
completely rewritten from scratch (and be much less efficient and require a
lot more plumbing on both sides), in order to support that kind of out-of-
process messaging to WkWebKit.

The great thing about NativeScript is that gives you has such an efficient
high bandwidth interface to native code from JavaScript. But it just
necessarily uses an old crappy JavaScript engine with no JIT.

One of the best thing about using WkWebKit is that the Just In Time compiler
is enabled, so it's blazingly faster than running JavaScriptCore in the same
process (which has it disabled, since non-Apple apps aren't allowed to write
to code memory).

Of course it depends on how much of your application is written in JavaScript
and would benefit from the JIT, and how much it depends on calling and sending
data back and forth between native code and JavaScript. But the NativeScript
way of doing things makes many assumptions that would make it very slow with
RPC messaging instead of direct calling.

PhoneGap/Cordova is fine using WkWebKit because it uses a JSON messaging
interface in the first place, not the more efficient higher bandwidth
Objective C bridging stuff. It's JavaScript/Objective C bridge is much simpler
than NativeScript, and people don't use it the same way that NativeScript is
designed to be used.

NativeScript, as cool and amazing as it is, is deeply tied to old technology
on iOS, JavaScriptCore and UIWebKit.

