cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tommy-carlos williams <to...@devgeeks.org>
Subject Re: [iOS 8] Status of WKWebView work
Date Wed, 10 Sep 2014 00:41:55 GMT
Generally speaking, JS performance is not a problem for most iOS Cordova apps. Certainly I
never had a problem until recently.

Sadly, I now work with a JS privacy (crypto) lib called Crypton[1] that works pretty damn
good on Android, decently on BB10 and even pretty good on FxOS… but takes like 2 MINUTES
just to log in on an iPhone 5 :(

And that’s only using 1000 rounds of PBKDF2 for SRP authentication (less than we would like).

Luckily, my use case is not the norm… but it does mean I am making apps that are unusable
on iOS, which makes me sad.

1. https://crypton.io

On 10 September 2014 at 10:20:21, Andrew Grieve (agrieve@chromium.org) wrote:

That's great news.  

JS execution speed honestly hasn't really been a problem for Cordova  
apps that I've heard of anyways.  

On Tue, Sep 9, 2014 at 7:01 PM, Shazron <shazron@gmail.com> wrote:  
> Some interesting findings - iOS UIWebView and WKWebView have the same  
> user-agent value, and both score 440 on html5test.com.  
>  
> Which makes me think they use the same engine (renderer and js), but  
> UIWebView has nitro turned off. WKWebView seems to be about 4x faster on  
> the Sunspider benchmark.  
>  
> On Tue, Sep 9, 2014 at 3:58 PM, Shazron <shazron@gmail.com> wrote:  
>  
>> UIWebView iOS 8 scores 440/555 points on html5test.com, and yes it  
>> supports indexedDB  
>> Full results: http://html5te.st/f16d892273bbe5bd  
>>  
>> On Tue, Sep 9, 2014 at 1:33 PM, Andrew Grieve <agrieve@chromium.org>  
>> wrote:  
>>  
>>> :(  
>>>  
>>> Hopefully UIWebView will still get some updates though? E.g. IndexedDb?  
>>>  
>>> On Tue, Sep 9, 2014 at 4:18 PM, Tommy Williams <tommy@devgeeks.org>  
>>> wrote:  
>>> > That's pretty disappointing.  
>>> >  
>>> > Especially with not even a comment from apple.  
>>> > On 10 Sep 2014 05:50, "Shazron" <shazron@gmail.com> wrote:  
>>> >  
>>> >> Well, bad news. I just installed the iOS 8 GM firmware on an iPhone
5  
>>> and  
>>> >> used Xcode 6 GM, and the file:// url "bug" (assuming it is a bug and
 
>>> not by  
>>> >> design) is still there.  
>>> >>  
>>> >> http://www.openradar.me/radar?id=5839348817723392  
>>> >>  
>>> >> On Fri, Sep 5, 2014 at 12:48 PM, Shazron <shazron@gmail.com> wrote:
 
>>> >>  
>>> >> > Clarification:  
>>> >> > When I said "The bridge works great, and plugins work great." this
 
>>> was  
>>> >> > for loading a html page and plugins using the file:// protocol
using  
>>> >> > WKWebView (as the title of the report implies). The bug I reported
 
>>> was on  
>>> >> > Device (> iOS beta 4), on Simulator it is *fine* (this info
was in  
>>> the  
>>> >> bug  
>>> >> > report as well).  
>>> >> >  
>>> >> > *Nothing* has been done using the local web server and proxy (at
 
>>> least  
>>> >> > nothing checked in). An implementation on how the proxy works can
be  
>>> seen  
>>> >> > in the PhoneGap Developer App:  
>>> >> > https://github.com/phonegap/phonegap-app-developer  
>>> >> >  
>>> >> > See CB-7043 for progress on tasks regarding this.  
>>> >> >  
>>> >> >  
>>> >> >  
>>> >> > On Fri, Sep 5, 2014 at 11:40 AM, Shazron <shazron@gmail.com>
wrote:  
>>> >> >  
>>> >> >> I figure I will write this all up before the official release
of  
>>> iOS 8  
>>> >> >> next week (probability high) and everyone asking about support.
 
>>> >> >>  
>>> >> >> It has stalled because the WKWebView cannot load files using
the  
>>> file://  
>>> >> >> protocol since iOS 8 beta 4.  
>>> >> >>  
>>> >> >> This bug has been filed with Apple weeks ago:  
>>> >> >> http://www.openradar.me/radar?id=5839348817723392  
>>> >> >>  
>>> >> >> I even checked WebKit check-ins if there was any progress,
so far,  
>>> no:  
>>> >> >>  
>>> >> >>  
>>> >>  
>>> http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/API/Cocoa?order=date&desc=1
 
>>> >> >> (but it's entirely possible the loading code is in another
part of  
>>> the  
>>> >> >> tree).  
>>> >> >>  
>>> >> >> The alternative is to run a local web server, which works great.
 
>>> >> However,  
>>> >> >> this will open up a can of worms possibly with Apple, I'm not
sure.  
>>> >> >>  
>>> >> >> The other interesting tidbit is, with WKWebView, for locally
loaded  
>>> >> files  
>>> >> >> using the file:// protocol, cross-domain restrictions now apply,
 
>>> unlike  
>>> >> >> UIWebView's behaviour. To have the same behaviour as UIWebView,
we  
>>> would  
>>> >> >> need to proxy these requests (modify xhr.open to go to our
proxy,  
>>> which  
>>> >> >> requires the local web server).  
>>> >> >>  
>>> >> >> The bridge works great, and plugins work great.  
>>> >> >>  
>>> >> >>  
>>> >> >>  
>>> >> >>  
>>> >> >>  
>>> >> >  
>>> >>  
>>>  
>>  
>>  


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message