Apple Shows Love for HTML5 with iOS 8

We were as excited as everyone else with last week’s Apple iOS 8 release announcement. We have only had the iOS 8 GA bytes for a few days, but we wanted to do as quick and complete a write-up as we could to give the global web developer community an in-depth look at Apple’s latest release. There’s no doubt we’ll see a few items we missed in the next couple of weeks and months, but for now we wanted to run our battery of benchmarks and tests and share what we’ve already uncovered.

This post documents our performance and technical breakdowns of the current state of HTML5 as iOS 8 becomes the baseline for Apple devices. For a similar review of iOS 7 for web developers, please see our blog post from last year.

New iOS 8 Features Will Further HTML5 Development

Let’s begin by taking a look at some features that have been added with this upgrade.


Though all of these features are great and help further HTML5 development, the big ones that clearly stand out are:

WebGL – 3D Canvas Graphics

Hardware-accelerated 3D Graphics support — no question this is a huge feature for web developers. Though we will likely see this feature used heavily in gaming, there are a lot of additional uses, especially in the areas of animations and transitions. To get a quick peek at what is possible, fire up this WebGL Sprite Particle Demo.

CSS Shapes Level 1

This rarely seen feature was really only available to us in Chrome, Chrome for Android and Opera, but it has finally busted into the big time with prefixed support in iOS 8. CSS Shapes allows for much more dynamic text layouts that can make your application feel more like a magazine than a web page. To see some examples of this at work, check out Shapes from Adobe.

HTML Templates

One of the foundational elements in Web Components is now available in the latest Android and iOS browsers. This is a big step towards making a truly modular web and opens up a lot of potential with one less polyfill required.

Navigation/High Resolution Timing APIs

Though superficially not an extremely popular end user facing feature, having a streamlined performance timing API will allow for much better cross-platform benchmarking and performance testing.


Even though WebSQL has been, and still is, available for Android and iOS, we currently have no support for IE. To make matters even worse the Web SQL Spec is no longer maintained and will likely be dropped in a future version. Luckily for us, IndexedDB is now available across iOS, Android, Chrome for Android, Safari, IE Mobile and has partial support in Blackberry 10 and IE 10/11.

SVG Fragment Identifiers

This feature sneaks in under a very cryptic name, but trust us, it’s a powerful one. Currently available in IE 10, 11 and Mobile, iOS 8 Safari and Chrome for Android, SVG Fragment IDs allow for very powerful vector spritesheets. Not only will this be very important for web gaming but also more dynamic icons and other UI elements.

As mobile web developers, you are already used to working with the latest browser versions and features. We all know that Apple has a fantastic upgrade system that will allow iOS 8 to reach all of its users very quickly. If your application is targeted specifically at iOS devices, you can easily start using features like IndexedDB, SVG Fragments or benchmarking with the new Timing APIs. For those looking to keep parity with iOS 7 and/or develop for multiple platforms (Android, Windows Phone, BlackBerry), you can scope down these new features with Sencha Touch built-in OS detection. Sencha Touch will allow you to use the new features in your application now and phase out your older code over time.

The All New WKWebView

With the release of iOS 8, we are both blessed and cursed with a bit of fragmentation. iOS 8 ships with two native webviews built in. The first is the good old “UIWebView” that we know and love. It currently is kept for legacy purposes, but lucky for us Apple did not simply smash the older iOS 7 “UWebView” into iOS 8, they have upgraded the core WebKit code to be on parity with their brand new webview, “WKWebView”. “WKWebView” will be the place to get your hybrid app, as we move into iOS 8. It has the Nitro JS engine, which we have tested and measured to have at least 4x the performance of “UIWebView”. This has the potential to be a huge win for hybrid apps. However, at this time, there are some significant bugs that impact just about everyone. More on that later in this post.

The good news is that the new high performance “WKWebView” is a step in the right direction from a Web development perspective. Even though JavaScript is rarely a bottleneck for applications as we typically see more issues with animation or DOM repaints, we believe that with substantial boosts to the Dom Core, the “WKWebView” will help Sencha Touch applications see huge performance improvements.

Performance Gains Across the Board

Performance testing is always a must, and this time around we have some rather interesting results. Overall, it looks like going to iOS 8 will be a win for everyone across the board. There are a few octane scores that were slightly lower in iOS 8, along with Base64 and Code Eval. So let’s dive into some charts and try to figure out what all this means.

Note: All these tests were done on a 5th generation iPod Touch in the hopes that, compared to all of the iPhone 5s and soon iPhone 6s out there, these score will help you find your lowest threshold for iOS development.


Unfortunately, at the time of testing, Google Octane v2 crashes iOS 8 Safari for us, so we were unable to run any new tests. Regardless, this gives us a pretty good overview.

We can see that iOS 8 wins out in pretty much every test except CodeLoad. CodeLoad measures how quickly the JavaScript engine can start running after pulling in a very large JavaScript file. It’s worth mentioning the code for this test is based on Closure and jQuery, but one would have to agree that it’s a pretty good benchmark for this kind of thing.

For applications built with Sencha, we might see a slightly longer delay in application startup, as compared with iOS 7, because these applications tend to have larger JavaScript loads upfront instead of incremental loading. For all other tests, iOS 8 is either very close or a clear winner over iOS 7.


The Dom Core test from Dromaeo is actually much better than what the chart shows. The fact that Query shows such a huge improvement, overshadows the improvements in Attributes, Modification and Traversal. Looking at the raw numbers, we saw a 122% improvement in Attributes, 65% for Modification, 48% for Dom Traversal and a whopping 308% boost for Dom Query.

This is great news for Sencha developers as dom query is used a lot by Sencha frameworks.


After seeing dramatic improvements in the DOM Core tests, we looked at the CSS selector performance boosts at the framework level. Ext JS Selector times improved by 126% by simply moving to iOS 8 Safari.

Note that these CSS Selector tests currently use Ext JS 3.x and the framework has improved dramatically with the release of Ext JS 5.x. As a result, the actual improvements will be even better.


Moving on to some pure code tests, we’re looking at some fundamental JavaScript functions that almost every application would use. We can see there’s a bit of a performance dip when working with Base64 strings and code evaluation via new Function and eval. We did however get some dramatic gains in Arrays, specifically in Array construction. Developers shouldn’t be too concerned, as we already discussed in our Fastbook post, JavaScript is plenty fast for creating most any application. GPU compositing is much more important than the JavaScript for creating fluid apps nowadays. Which brings us to our next benchmark focused on GPU interactivity.


The chart here pretty much speaks for itself. We see a huge 78% increase in fps (frames per second) by simply switching to Safari in iOS 8 vs iOS 7. It’s obvious that Canvas got a number of updates, and the results are really showing up in our WebGL examples.


Now, this is a bit of a bittersweet chart, as we can easily see the vast improvement in “WKWebView”. But if you skip ahead to the bug area, you will see that there are some challenges today that are keeping us from using the “WKWebView” in hybrid apps.

If anything, we hope these numbers push more developers to head over to Apple and push to get these “WKWebView” bugs fixed ASAP, so we all can start taking advantage of these performance improvements in all our applications. Once again, the Dom Query overshadows all the other numbers. For the record, with “WKWebView”, Attributes is 208% faster, Modifications are 37% faster, Traversal is 249% better, and Query is a whopping 358% improvement over the old “UIWebView”.


Although the Sunspider test results are not nearly as dramatic, we still see some improvements. iOS 8 Safari came in about 14% ahead of iOS 7 Safari and the “UIWebView” jumped up about 5%. Small gains, but all positive, and they show that everything is moving in the right direction.



In this chart, we’re looking at the raw score from HTML5 Test, and it’s easy to see iOS 8 Safari has a nice boost in supported features over iOS 7. However, to properly interpret these results, we need to discuss some changes under the covers that have a big impact on these statistics. So let us boil it down for for you with a few bullet points:

  • Seamless iFrame was removed in iOS 8
  • IndexedDB was added to iOS 8 Safari and “WKWebView”
  • IndexedDB is not available in iOS 8 “UIWebView” or Home screen apps
  • Objectstore ArrayBuffer does work in iOS 8 Safari and ”WKWebView” (Note: This test fails on the HTML5 Test site even though the feature is working. If this was properly detected, iOS 8 Safari would score a 440.)
  • Objectstore ArrayBuffer is not available in iOS 8 “UIWebView” or Homescreen apps
  • WebGL 3D Graphics were added to iOS 8 in Safari, “WKWebView”, “UIWebView” and home screen apps
  • The userAgent for “UIWebView”, “WKWebView” and a Homescreen app are identical

Even though Apple has done a pretty solid job of keeping “WKWebView”, “UIWebView”, Safari and Home Screen applications at the same level of functional capabilities, the differences may cause some frustration for Sencha developers. Developers now need to be a little more aware of the context in which their application is going to run. Example: “UIWebView” and Home Screen applications do not have IndexedDB or Objectstore Array Buffer support. Because the browser User Agents are the same, there’s no easy way to scope down your application based on where it’s being served, which means developers will need to feature detect these things individually.

The Bugs

We all know that no release of any software is bug-free, and of course iOS 8 has a few worth mentioning. So far, we have uncovered what we consider to be three major bugs that are going to potentially affect HTML5 developers and therefore, Sencha customers. Now, that being said, these bugs are not specific to Sencha apps and will actually affect the development efforts of many developers for the next couple of months. If you wish to help, please check out the radar link below each bug and head over to the Apple Bug Reporter. There, you can duplicate our bug and submit it, and the more hard data and test results we provide proving the bug’s impact, the faster (we hope) they will be seen and then fixed.

WKWebView Local File Loading Bug

Remember that amazing new WebView I was just telling you all about? The one with the super fast Nitro JS engine and shiny new everything. Well, its broken… The bug here is a security issue which does not allow “WKWebView” to load files from the local filesystem. So what this means is that your embedded index.html is not accessible to the “WKWebView”. This is a blocker for PhoneGap and Cordova applications that are using offline/local files to serve up an application. So currently, if you would like to use “WKWebView” in your application, you must load your files from a remote server. For example, loading “index.html” will not work, but loading “” will work just fine.

Radar Bug Report:

XHR Local File Access

Currently, anything using the new “WKWebView” code has a broken XHR Local File issue. This includes Safari, homescreen apps and any embedded apps inside a “WKWebView”. If you’re using Cordova or PhoneGap, you will still be locked into the older “UIWebView” which does not suffer from this bug. The bug itself simply does not allow the XHR object to send local files off the phone. So, if your application currently is using the photo gallery or camera to grab an image and then via AJAX send it to the server, you are sadly out of luck in iOS 8. What you”ll see is that your application will hang with no response after calling “send.”

Radar Bug Report:

Home Screen Apps Lose Timing Functions After Lock/Wake

If your application is being used as a homescreen web application, you’ll find yourself in a sorry state. Of course, any web app can be converted into a home screen app by the user, so I guess technically this affects anyone making a remote web application. This bug is easily reproduced by simply calling setTimeout(callback, 1) or requestAnimationFrame(callback) via some button or event. When you first open your application, you’ll notice all timing functions are working fine. However if you lock your phone and then unlock to return to your application, you’ll see none of the timing functions can call callbacks anymore. They are simply broken at a native level. There is no reset, no bringing your application back to life, it’s a kill it and restart situation. These timing functions are crucial to the Sencha Touch and Ext JS frameworks along with pretty much every other JavaScript framework/library ever made. Definitely head over to Apple as soon as you can, and let them know that you would like to have all of your JavaScript functions, all the time.

Radar Bug Report:

There is some good news here, because so far we’ve only uncovered issues that affect “WKWebView” applications. If you are one of the many people that have tried or are using Sencha Space, there is absolutely no impact because your application is safe — with Space, you are inside a managed web runtime that includes a secure browser. If you haven’t tried Sencha Space yet, you should check it out here.

Things to Come

Overall, with the release of iOS 8, we’re very pleased with where Apple iOS is heading, because the performance improvements and new features are only going to improve user experiences for apps built on the iOS 8 platform. However, we certainly hope Apple addresses the bugs very quickly that we discussed, because their presence impairs the full realization of the power of iOS 8 for web developers — whether they use Sencha frameworks or any number of other popular alternatives.


If we look further into the future, we can expect to see a crossover between iOS 8 and Chrome for Android with great features such as CSS Shapes, srcset atrribute, and SVG fragment identifiers. Though not shown in the above image, Chrome for Android already has partial support for WebGL 3D Canvas graphics and really the partial is more about older devices that are capable of running Chrome but just don’t have what is needed to power WebGL 3D.


iOS 8 is certainly an exciting release for Web developers with amazing new features and huge performance boosts that will further help HTML5 cross-platform development.

At Sencha, we’re always looking to help developers stay at the forefront of the next generation of web development. We are focused on bringing the best and most complete cross-platform solutions to our users, so they can deliver amazing application experiences to every device. We can’t wait to see what you all will invent with us. Thanks for tuning in, until next time.