JavaScript in the Enterprise – Your Questions Answered

JavaScript in the Enterprise - Your Questions AnsweredIn last week’s webinar, Analyzing the ROI of JavaScript in Enterprise Software Development, we discussed the requirements for building enterprise applications and highlighted some of the challenges commonly faced by our own customers. We also examined how choosing a JavaScript framework can impact the long-term economics relating to development, maintenance and operational processes.

To view the webinar, please visit the Sencha Channel on BrightTalk

To learn more, join us for our upcoming webinar - Analyzing the ROI of JavaScript in Enterprise Software Development

At the end of the presentation (~56:00) we received a few interesting questions that we simply didn’t have the time to answer. We promised to follow-up on these questions — so here are our responses:

Upgrading JavaScript Frameworks

How mature is any Javascript framework (and Ext JS in particular) in terms of supporting upgrades? Transition from Ext JS 3 to 4 was relatively a big effort compared to a Java 5 – 6 upgrade. Do you consider a better upgrade transition supported by JavaScript frameworks in the future?

This was one of the major concerns we raised during the presentation. As you point out, many other enterprise technology platforms (e.g. Java) have far longer release cycles compared to web technologies. In fact, Wikipedia cites roughly two years between the major versions J2SE 5 and Java SE 6.

With the explosion of HTML5 in recent years, web technologies (specifically JavaScript) have enjoyed an incredible amount of innovation as browsers continue to implement new HTML5 capabilities. The downside to the innovation is that the technology changes so fast that we currently see a huge difference in functionality between legacy browsers (e.g. Internet Explorer 8) and the latest versions of Chrome.

During the webinar, we spoke about how some widely popular micro-frameworks (AngularJS and jQuery, among others) have completely abandoned legacy browser support in their most recent versions. This is of great concern to enterprise organizations who must continue to support older browsers for the foreseeable future — and to your question, many JavaScript frameworks are not “mature” in their support for upgrades in this sense.

Sencha however has firmly aligned itself with the needs of the enterprise, and we learned a lot from the experience of our customers during the Ext JS 3 > 4 migration. First we made sure that our latest release (Ext JS 5) offered a smooth upgrade from 4.x. Second, we kept support for the legacy browsers our enterprise customers still require. Third, based on our customer’s upgrade experiences, we have made upgrade paths and backward/forward compatibility a standard roadmap item.

While it’s hard to say if all JavaScript frameworks will mature into longer, more stable and smoother release cycles, we believe that Ext JS is the clear leader in this area.

Browser Support

What rule/commitment does Sencha have on supporting older browsers? For example, when will you stop supporting IE8?

The only rule Sencha has for deciding which browsers to support comes from what our customers tell us they need.

When we first released Ext JS 4.0 in 2011, the browser landscape looked a bit different than it does today. Internet Explorer 6 still had significant market share, and Chrome had only just begun its shorter 6-week release cycles. Mobile browsers were far from mature, and at the time, few enterprise companies had mobile strategies.

The browser landscape today is much different, as are the requirements for enterprise web applications. While the need to support Internet Explorer 8 is clearly still a priority for our customers, only a few organizations require anything older (and for those customers, we are supporting them via customized extended support programs). On the other hand, many of our customers also specifically asked us to begin supporting mobile browsers — particularly for use on tablets. Therefore, Ext JS 5.0 (released earlier this year) evolved with the needs of our customers.

When will we stop supporting IE8? Certainly not in the immediate future. The majority of our enterprise customers tell us they still need to support IE8, and this aligns with research from Net Market Share that legacy Internet Explorer still commands a sizeable chunk of IE usage.

Legacy browser support is truly one of the features that sets Ext JS apart from our competition — so while we plan to continue innovating with new features, we also plan to continue evolving with (and not away from) our customers.

Legacy browser support is truly one of the features that sets Ext JS apart from our competition — so while we plan to continue innovating with new features, we also plan to continue evolving with (and not away from) our customers.

Code Specialization

Micro-frameworks are specific. How can Sencha guarantee best-in-class features for each specialization?

I mentioned in the webinar that micro-frameworks, by definition, only strive to implement a subset of the functionality needed by enterprise applications. This isn’t necessarily a bad thing — as you point out, micro-frameworks can provide best-in-class features by specializing in their area of expertise.

Taking that point on its own, you might argue that it can be difficult for Sencha to compete with micro-frameworks that specialize in certain areas. One example might be charting and visualizations: Ext JS ships with charting and visualization packages, but how can Sencha guarantee ours are “the best”? There are several parts to this answer.

First, asking which framework is “best” is always a loaded question. Does “best” mean quality? Performance? Extensibility? It’s an entirely subjective analysis, and ultimately “best” is only true in given situations. From our perspective, Ext JS offers an extensible framework in which all of the features are fully integrated. We guarantee you’ll be able to easily modify and extend every class in our framework if the built-in features don’t meet a specific need; moreover, you’ll be able to do this using a consistent code style. Micro-frameworks typically don’t guarantee that because they’re specialized, so in cases where a library doesn’t perfectly fit your needs you are often stuck hacking away at code not intended for customization or extensibility.

Second, you need to consider that micro-frameworks are not used in a vacuum. A specialized charting library needs to be wired into the rest of your application stack — work that can be very tedious as none of the moving parts are fully integrated.

And finally, it’s important to find the right tool for the right job. Ext JS is ideal for building feature-rich and complex line-of-business applications — and while our framework delivers the overwhelming majority of features an enterprise application needs, there may indeed be cases where you want to pull in a third-party library to do something Ext JS doesn’t specialize in (e.g. cryptographic algorithms). Ext JS can play nicely with other libraries — the webinar just warned against complicated dependency chains as they cause problems for long-term maintenance.

Performance

What gains are you seeing in HTML5 performance for Sencha apps as it relates to overtaking native apps and becoming the standard for mobile app development?

Sencha engineer Ross Gerbasi recently wrote an article discussing how HTML5 performance on iOS 8 has gained a lot of speed — but that there are also some bugs that still need to be addressed.

Sencha has strategically focused on HTML5 because we feel incredibly confident in the direction HTML5 is heading. JavaScript performance continues to improve both in mobile browsers as well as in the WebView.

During the webinar, we briefly talked about different approaches to building applications. It is hard to beat the performance of native apps with HTML5 simply because native apps are built with technology one step closer to the physical OS, but HTML5 applications can still achieve fantastic speed. Sencha proved this two years ago with our Fastbook demo, and since then others have also built impressive HTML5 apps with performance so good that users can’t tell whether-or-not they’re native.

Our take is that HTML5 already offers great performance for mobile apps, and it will continue to improve to the point where “performance” is good enough that we stop asking this question.

Security

How do you secure your framework? Basically, how would a customer have assurances that it’s secure enough?

Security is definitely a big issue for enterprise applications, but application security also comes in many flavors. Browser applications are inherently insecure as the runtime is open for anyone to debug, so let’s examine how Sencha tackles security.

In the Ext JS framework, many of our classes can be configured to help mitigate common security threats. For example, Ext.ElementLoader automatically prevents remote scripts from being loaded unless configured otherwise. Classes that enable user input (e.g. Ext.form.field.Text) can easily be configured to prevent the direct input of certain characters or expressions, and can also be configured to validate their input on submission. Ext JS also ships with a number of utilities (e.g. Ext.util.Format.stripScripts and stripTags) that enable the developer to implement security as needed.

But as I already mentioned, the browser is inherently insecure. Even if the client application prevented direct user input, savvy developers can easily open their debugging tools to manipulate script logic, DOM interactions or access localStorage. At the end of the day, a client application running in the browser must rely on server-side and network security.

For mobile applications built with HTML5, having your web application wrapped with tools like Cordova might make this more difficult for a hacker — but unfortunately, Cordova applications are still not completely secure.

We created Sencha Space specifically to address the enterprise concerns around building secure mobile applications with HTML5. Our recent white paper goes deeper into the security details to discuss how Sencha Space can help to lower risk, strengthen security, and lower the total cost of ownership for application and data mobility.

Conclusion

Sencha understands the impact that HTML5 and JavaScript can have on the long-term economics for enterprise software development, and Ext JS has been strategically engineered to help the enterprise build applications more efficiently. Please feel free to ask us more questions about the presentation in the comments below!

We really hope you enjoyed last week’s webinar — please join us in November to hear about what is new in Sencha Space 1.2, and how Sencha Space makes it easier to develop and deploy secure cross-platform HTML5 applications!

analyzing-the-roi-of-javascript-in-enterprise-software-development-1.png 3 Comments   Read more

Sencha Space Smooths the Transition to iOS 8

Sencha Space Smooths the Transition to iOS 8Although technology enthusiasts generally greet new Apple releases with a jubilant fanfare, new device and iOS releases regularly impose significant costs for application developers. As we covered in our blog post, Apple Shows Love for HTML5 with iOS 8, there are many great new features for web developers in Apple’s latest release. However, there are also a number of important unresolved bugs which directly impact hybrid applications.

Major version upgrades are always tedious; hybrid applications faced similar problems when iOS7 was first released. The reality is that many developers face the burden of working around these bugs and updating their applications to fix backward incompatibilities between versions, to update graphics to account for the new screen sizes of the iPhone 6 devices, and to test all of this hard work against an ever-increasing number of variables.

Fortunately, Sencha Space insulated its subscribers and end users from these interruptions. HTML5 and JavaScript application developers who use Sencha Space to manage the deployment of their apps did not have to make any code changes, test against new devices, or submit new binaries to the App Store. By targeting the consistent runtime environment that Sencha Space provides, developers shielded their apps and end users from the disruption of the iOS 8 upgrade.

What about Cordova?

PhoneGap and Cordova applications were not spared from this complex upgrade process. To take full advantage of the new larger iPhone devices, developers at a minimum had to test and re-submit their applications to the App Store. The Cordova project did release an updated version that resolved a number of API and plugin bugs — but developers were still required to first upgrade Cordova, then re-test and re-submit each application individually.

Conversely, because Sencha Space was ready for iOS 8 on day one, end users who upgraded to iOS 8 were able to simply upgrade their Space client application and all the apps deployed to them through Space continued to work as intended.

A Better Way to Deploy Applications

The benefit to developers in Sencha Space is simple, but profound. Over the lifetime of their applications, developers no longer have to worry about incurring an expensive maintenance cycle on their apps every time an OS vendor releases a new version. Imagine how disruptive that could be for development teams who support two, three, or four different target operating systems for their apps — a cost that is multiplied across every application maintained by an organization.

Because Sencha Space preserves API compatibility across different OS versions, developers can continue to drive new innovations for their apps instead of diverting resources just to keep their apps working and accessible in various application stores across device platforms. This helps to reduce the cost of developing cross-platform, multi-device apps and makes it easier to do more with the same amount of resources.

To learn more about Sencha Space, visit www.sencha.com/space.

1 Comment   Read more

Using GapDebug to Test Hybrid Web Apps Built with Sencha Frameworks

Introduction

Using GapDebug to Test Hybrid Web Apps Built with Sencha FrameworksDevelopers have been using PhoneGap (and subsequently Cordova) to deploy hybrid mobile applications since 2009, when it was first created. By allowing web applications to run on native devices, the HTML5 community fully embraced PhoneGap and thousands of apps have since been released on iOS, Android and a wide variety of other platforms. But while the wrapper itself is great, unfortunately the debugging tools have lagged far behind their browser counterparts — and debugging across multiple platforms has often been painful.

In this post, we’ll introduce you to the new Genuitec GapDebug tool and explain how it makes debugging hybrid applications deployed with PhoneGap far easier than ever before. We will also compare GapDebug to the popular Weinre debugger and highlight the key differences between them.

GapDebug LogoGapDebug

GapDebug is a free cross-platform mobile app debugger developed by Genuitec for use with Android and iOS PhoneGap (or Cordova) applications. It runs on both Windows and Mac OSX and is packed full of killer features for exploring every aspect of a hybrid app’s state and execution.

GapDebug is a free cross-platform mobile app debugger developed by Genuitec for use with Android and iOS PhoneGap (or Cordova) applications.

Many Sencha developers use Cordova or PhoneGap every day to deploy their hybrid applications — but debugging an HTML5 app directly from the device can be a very frustrating experience. GapDebug makes this process much easier, using a single interface for all apps and devices, and without requiring the developer to add special code.

How GapDebug Works – Plug and Debug

Before you can begin debugging, your iOS or Android devices require a simple 1-time configuration as outlined here. With your device configured, simply plug and debug by connecting your device to the GapDebug host computer using a USB cable. The device may prompt you to approve the connection. Once the connection is completed, the device info will appear on the left of the GapDebug user interface in the Device Panel.

On the mobile device, launch the app that you wish to debug. If the app is not already present or up to date on the device, use the app installation button GapDebug Download Image found next to the device info to select and install a new version of the app. Alternatively, you can drag and drop a binary app executable file on the device to install it. When the app is launched, the app’s ID and icon will appear just under the device in the GapDebug Device Panel.

Selecting the app in the Device Panel will start a debug Inspector in a new tab pane on the right side of GapDebug user interface. Two versions of the inspector are provided: for iOS apps a custom version of Apple’s Safari Webkit Inspector is presented, while Android apps get a custom version of the Chrome Developer Tools.

GapDebug (Windows version)
GapDebug (Windows version)

Before we dig in and start debugging, let’s first examine how GapDebug is different than the popular debugging tool Weinre.

GapDebug vs Weinre

Until GapDebug, Weinre was the go-to cross platform debugger for PhoneGap apps. Weinre was developed in early 2011 by Patrick Meuller as an open source solution for remote debugging of iOS and Android PhoneGap applications. It consists of a JavaScript library that is dynamically loaded by the app at startup, a debugger user interface that runs in your browser, and a server that handles communications between the application and the user interface.

Weinre is implemented in JavaScript and requires Node.js to install and execute locally, although you can avoid setting up a local installation by using one of several freely available online Weinre servers.

Weinre debugger user interface
Weinre debugger user interface

While Weinre remains an innovative tool, it is beginning to show its age. Let’s look at some of the pros and cons of using Weinre:

Pros

  • The debugger provides tools for DOM and CSS inspection, resource browsing and analysis, and a JavaScript console
  • Developers can simultaneously debug multiple apps across multiple devices
  • Mobile devices only require a network connection, no USB tether required
  • No special device configuration required
  • Weinre debugging works for a wider range of iOS and Android OS versions than GapDebug. (GapDebug supports Android v4.4 and above and iOS v5 and above)
  • Open source under Apache license

Cons

  • The Weinre user interface is a dated version of the WebKit Inspector
  • No JavaScript debugging and profiling
  • Not easy to reload the app for testing events such as deviceready
  • Requires modification of application code to include a special instrumentation script
  • Device must be online with a network connection, can’t debug offline scenarios
  • Requires processing time for communication with remote Weinre server
  • Server connection frequently times out, terminating your debug session unexpectedly

Using GapDebug to observe frequent Weinre network XHR activity in an application
Using GapDebug to observe frequent Weinre network XHR activity in an application

By contrast, GapDebug first debuted in June 2014 and is being rapidly enhanced with monthly updates by a small team at Genuitec.

Pros

  • Provides the most powerful hybrid app debugging features available through the use of special versions of Safari WebKit Inspector and Chrome Developer Tools
  • Professional Windows and Mac OSX installers, with automatic updates
  • Free for all users including commercial use
  • Simultaneously debug multiple apps across multiple devices
  • No requirement to modify application code with special instrumentation library
  • Device does not require a network connection, can debug offline apps
  • Easy app reloading to test events such as deviceready
  • Windows users can remotely debug iOS apps
  • Remotely view, control and debug Android apps over the internet

Cons

  • USB tethering may be considered a negative by some users
  • At this time, no common inspector UI (for cross-platform debugging, you must learn both the Safari WebKit Inspector tool and the Chrome Developer Tools — Genuitec is working towards a common UI in future release)
  • Currently only supports Android v4.4 and above and iOS 5 and above

Using GapDebug with Sencha

Because Sencha Cmd already has tight integration with Cordova and PhoneGap, Ext JS and Sencha Touch developers can immediately benefit from the superior tooling of GapDebug.

Using GapDebug, you can simultaneously debug multiple apps running on iOS and Android, and you can even debug iOS apps from Windows. Considering all of the HTML and CSS inspection, JavaScript debugging, and resource profiling capabilities, using GapDebug is a great choice when it comes to wrapping Sencha applications with PhoneGap or Cordova.

Summary

In most areas, GapDebug exceeds the capabilities of Weinre. While both GapDebug and Weinre applications require instrumenting to support debugging, GapDebug is not invasive and does not modify your application code. The GapDebug inspector tools are state of the art and function even when the device is offline. Lastly, GapDebug continues to be rapidly improved by the Genuitec team.

Download GapDebug for free and start debugging your Ext JS and Sencha Touch applications today.

analyzing-the-roi-of-javascript-in-enterprise-software-development-1.png No Comments   Read more

Apple Shows Love for HTML5 with iOS 8

Optimizing The Development Process With Sencha Cmd 5We 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.

New iOS8 Features Will Further HTML5 Development
Source: caniuse.com

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.

IndexedDB

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

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.

We can see that iOS 8 wins out in pretty much every test except CodeLoad.
Source: http://octane-benchmark.googlecode.com/svn/tags/v1/index.html

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.
Source: http://dromaeo.com/?dom

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.
Source: http://dromaeo.com/?cssquery

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.

We can see there’s a  bit of a performance dip when working with Base64 strings and code evaluation via new Function and eval.
Source: http://dromaeo.com/?dromaeo

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.
Source: http://ie.microsoft.com/testdrive/performance/fishietank/

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.

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.
Soutce: http://dromaeo.com/?cssquery

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.
Source: https://www.webkit.org/perf/sunspider/sunspider.html

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.

Source: http://html5test.com/

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

3 major bugs that are going to potentially affect HTML5 developers and therefore, Sencha customers.

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 “http://www.google.com” will work just fine.

Radar Bug Report: http://www.openradar.me/radar?id=5839348817723392

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: http://www.openradar.me/radar?id=5834555097350144

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: http://www.openradar.me/radar?id=5895945212395520

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.
Source: caniuse.com

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.

Conclusion

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.

ios8-teaser.png 16 Comments   Read more

Sencha Hosts Web Application Development Seminar in Seoul, Korea

Sencha is hosting a seminar in Seoul, Korea on May 16, 2014 &#8211 Sencha Web Application Development for the Enterprise with Mirae Labs.

The conference will focus on HTML5 and the Enterprise. With the proliferation of smartphones and tablets and the emergence of BYOD, organizations need to have a strategy for deploying applications for the web and multiple devices. This conference will help organizations by describing how HTML5 and Sencha solutions, which include frameworks, tools and application delivery platforms, can address these issues.

Presentations:

We will have two presenters at the event:

  • Stefan Stölzle, Sr. Solutions Engineer at Sencha, will talk about Ext JS in the enterprise
  • Jeff Pope, Managing Director at Sencha, will talk about Sencha Space and the issues of BYOD

Event Details:

  • Venue: Ferrum Hall, Ferrum Tower
  • Date: 16 May, 2014
  • Time: 13:30 – 17:40
  • Address: 3rd floor, Ferrum tower, 66 Suha-dong, Jung-gu, Seoul
  • Telephone: 82-2-6353-8989
  • Directions: Exit number 2 of Euljiro 1-ga station, Line 2
  • Registration: http://onoffmix.com/event/26741

If you’ll be in Seoul on May 16, sign up for the event. We look forward to seeing you there.

seminar-in-seoul.jpg 1 Comment   Read more

The Downside of Native Packaging

The 2007 introduction of the iPhone ushered in a new era of mobility. We now expect our applications and data to be accessible on the most convenient network-connected device. Our appetite for mobile technology has resulted in a massive influx of mobile devices supporting a myriad of different mobile operating systems.

Many application developers soon realized the inefficiency of developing native applications in this multi-device, multi-platform world. They chose instead to embrace web technology and the emerging open standards around HTML5. The shift, now called hybrid app development, created the need for a tool to package these HTML5-based applications, run them on the device, and provide access to common device hardware features like the camera, GPS, and accelerometer.

Starting in 2009, native packaging solutions were created to address this need. Developers have lauded native packagers for allowing HTML5-based apps to fit into the still-dominant public app store distribution model. More importantly native packagers meet a number of important needs for consumer applications and have enabled many HTML5 developers to access app store distribution who otherwise would not have had such an opportunity. Yet in subsequent years, the many deficiencies of native packagers have become painfully obvious to many application developers in the enterprise.

These deficiencies include:

  • Security – Sensitive data is stored unencrypted in the packagers’ caches and data stores
  • Complex app lifecycle – You have to build for multiple platforms and manage the deployment and maintenance of those binaries over the life of the application
  • Subject to frequent mobile OS changes – Any changes or backward-incompatibility from a mobile device vendor can break your packaged app
  • App Store Distribution – Distributing enterprise applications through consumer app stores is highly inefficient.

It’s now 2014; organizations have been dealing with this pain for long enough. They want a long-term solution for application and data mobility. The answer is to deploy HTML5 apps directly into a secure, managed runtime environment. This type of solution has many benefits:

  • End-users get a superior application user experience, relief from app fatigue, and protection for personal privacy. Their applications are always up to date.
  • Developers reap the benefits of both the web and today’s mobile devices. They no longer have to package the app for multiple platforms. They can also eliminate the hassle of dealing with consumer app stores to distribute their apps.
  • Organizations can instantly secure and manage the lifecycle of their apps, data, and users, fighting app sprawl in the process. Administrators can grant and revoke user access to apps and data as business needs dictate, wiping business data from users’ devices without touching personal data. Furthermore, their data is encrypted on the device, protecting them from data breach.

Native packagers have served you well at a time when you really needed it. But if these points concern your organization at all, there is a better way to solve these problems now. If you’re making apps for the enterprise, it’s time to let native packagers go.

Click here to learn more about how Sencha can ease your transition to a post-native packager world.

20140414-mind-the-phone-gap-teaser-v1.jpg 3 Comments   Read more

Announcing Public Beta of Ext JS 5

We are extremely excited to announce that the beta version of Sencha Ext JS 5 is available for public access and evaluation. This beta release enables you, our Sencha community, to test and evaluate our Ext JS 5 work in progress. For all the Ext JS developers out there, this a great opportunity to help make this the best Ext JS release ever.

And since this is a beta, we advise against putting it into production just yet.

Goals for Ext JS 5

We’re proud that Ext JS has become the industry standard for data-driven single-page applications. Engineered to grow with teams and projects, Ext JS powers applications that have successfully scaled to hundreds of screens and hundreds of thousands of lines of code. For intelligible, maintainable web applications, with clear separation of structure, behavior and visuals, we believe that the architected, component-centric approach of Ext JS is simply unbeatable.

When we sat down to design Ext JS 5, we wanted to take everything that made Ext JS great and make it even better. We had three themes for our development process. Our first theme was to Make Multi-Device Development Real. Ext JS 5 is our first release that allows the same code to power both desktop and touch device experiences, with a gesture system inspired by Sencha Touch. There are two fresh multi-device themes, so our rich set of UI components look and feel at home on both touch and desktop screens.

Our second theme was Evolution not Revolution. Perhaps the most important thing that hasn’t changed in Ext JS 5 is that we continue to make Internet Explorer 8 a first-class browser. We made this decision because a solid majority of you told us that IE8 support will continue to be a requirement for your applications through 2015 and beyond. We’ve also made smooth upgrades from Ext JS 4 a priority. As we’ve added and upgraded functionality, we’ve minimized breaking changes in our public APIs.

Our third and final theme was Developer Productivity. As we designed the new two-way data binding architecture, our goal was to vastly reduce the amount of code developers had to write to implement common UIs. In many cases, tasks that used to require several listeners can now be reduced to a few binding directives — which can be seen in some of our Kitchen Sink examples. Through the use of declarative listeners, views can now often be completely code-free, allowing developers to not only cut code size but maintain better separation of concerns at the same time.

As you can tell, we’re proud to release this beta to the community and hope that when compatibility, productivity and user experience matter most, Ext JS will continue to be your proven way to deliver the best engineered applications to your end users, customers and clients.

Announcing Public Beta of Ext JS 5

Now, on to the new features! Ext JS 5 has a myriad of new features and improvements. Here are some of the best:

  • Two-way data binding is a new mechanism that allows changes made in the view to be automatically written back to the model (and vice versa) without the need for custom event handlers.
  • Grid gadgets are new lightweight components useful for embedding within grid cells. Widgets and buffered updates make Ext JS grids even better, enabling richer data visualization and real-time data updates.
  • Touch-optimized charts is a new charting package that comes with features like 3D charts, financial charts, and multi-axis. It also has faster performance, cleaner code and a great experience on touch-screen devices. (The existing chart package is available as a separate package, so you can still use it.)
  • Routing allows application deep linking by translating your application’s URL into controller actions and methods.

There are numerous other enhancements and improvements related to MVC and performance in general. Read What’s New in Ext JS 5 for an exhaustive view of every new feature.

Another goal of Ext JS 5 is to converge much of the framework core between Ext JS and Sencha Touch. In Ext JS 5, we methodically converged code for the class system, data package, and feature/environment detection into a common core, so it can be shared across Ext JS and Sencha Touch. These shared components enable the creation of applications that share resources regardless of the framework.

Ext JS 5 supports IE8+ and the latest tablet platforms such as iOS6/7, Chrome on Android 4.1+, and Win 8 touch-screen devices (such as Surface and touch-screen laptops) running IE10+.

Beta Availability

Ext JS 5 beta is available for download immediately along with a beta version 5 of Sencha Cmd which is available for Windows, Mac OS X, Linux/64, and Linux/32. Check out our examples on a tablet.

We’re working hard to release Ext JS 5 in finished form as soon as possible, and we need your help and feedback to make that happen. Try out our new kitchen sink examples, migrate one of your smaller apps and report bugs, issues, or errors on the Ext JS 5 Public Beta forum. We look forward to your feedback.

20140401-ext-js-5-teaser.jpg 117 Comments   Read more

iOS 7.1: The Bug Fix Release Arrives

Last October we reviewed the web implementation in iOS7.0. We were disappointed in the release, and said that "the sheer number of bugs and broken features, clearly mark this release as a beta". Now that iOS 7.1 has just shipped, we decided to revisit our assessment and see how much progress Apple has made polishing the product.

TL;DR The good news is that the majority of bugs, broken features and performance regressions have been cleaned up. For example, we’re back to 60 fps performance for SVG animation, and Home Screen Apps seem to be working just fine again.

Home Screen Apps Back Again

The biggest news for web developers with iOS 7.1 is that Home Screen App functionality seems to have been fixed. This is good news, because Home Screen Apps were horribly broken in iOS7, with disabled alerts, hard crashing bugs and other wacky behavior. Apple now also provides a new meta tag to trigger (almost) full-screen on page load. The new meta tag is called "minimal-ui" and it loads a page with the toolbar hidden and the top URL bar minimized to the domain name. Unfortunately, minimal-ui breaks Sencha Touch 2.3 viewport position on iOS 7.1 when rotating from portrait to landscape. So thanks to Steffen Hiller for finding the bug and also for creating a workaround for minimal-ui breaking landscape.

Bug Fixes In Content Handling

iOS7.1 fixes almost every bug we found in iOS7.0 content rendering and animation:

  • Interactive elements that are near page borders now get focus properly when swiping left or right (instead of triggering the page back/forward action in the browser).
  • requestAnimationFrame animations now properly suspend when in a non-active tab
  • Web workers now properly suspend when in a non-active tab
  • Implicit z-indexes are now properly calculated before CSS animations fire
  • On iPad, changing orientation while an input has focus now seems to work just fine and the bug related to document height 100% seems to also have been fixed.

We do note that window.resize still doesn’t seem to fire when the URL bar and toolbar are minimized, although if you’re using the minimal-ui meta tag because you have bottom positioned content (for example) you shouldn’t run into this.

Performance

In our original iOS7.0 scorecard, we noted a number of performance gains and regressions vs. iOS6. On the positive side, JavaScript peformance (Sunspider and Octane) improved a lot and SVG long path drawing got an enormous boost (200x). On the downside, JavaScript animation of SVG was crippled.

The good news with iOS7.1 is that JavaScript animation of SVG is now high performance. The 500 bouncing SVG balls test that was crawling along at less than a frame per second, is now at 60 fps on iOS7.1. SVG Animators rejoice! There do not seem to be any other significant performance changes. Canvas is still super fast, and DOM Query is still half the speed of iOS6.

Great Quality Improvements, But No New Features

iOS 7.1 is a bug fix release that fixes almost all the issues we found in the rushed-to-market iOS7. While there are no new HTML5 features that we (or HTML5Test) could see, web developers can once again rely on Apple’s best in class browser for building HTML5 applications. We continue to expect Apple to introduce WebGL, Web audio, and more HTML5 features in a future release to be on par with the HTML5 features being introduced by Google, Microsoft, and Blackberry to their mobile platforms.

20140312-ios-bug-fix-teaser.jpg 9 Comments   Read more

Addressing Mobile Data Security (Part 2)

In Part 1 of this series, we explored how the increasing cost of data breaches coupled with the risk of increased mobility poses formidable challenges for IT-based organizations. The post discussed how MDM/MAM solutions can help to provide a basic level of protection, but fall short in certain key areas. In particular, MDM and MAM solutions do a poor job of providing application-level security unless organizations choose to rebuild or recode their applications. Organizations should complement their MDM/MAM deployments with solutions that use strong encryption and digital signatures to protect their sensitive data.

Using strong encryption and digital signatures can add another layer of protection if a mobile device containing sensitive data is lost or stolen. MDM/MAM solutions typically provide remote wipe of the device in the event of loss or theft. However, because this feature works at the device level, it erases all data on the device, including the end user’s personal data. This lack of granularity in MDM solutions is often cited as a barrier to end user adoption of corporate BYOD programs.

An ideal solution instead would be to manage cryptographic data security, maintain separation between personal and professional data, and constrain the scope of the remote wipe capability to the organization’s proprietary data, leaving the end user’s personal data untouched.”

An ideal solution instead would be to manage cryptographic data security, maintain separation between personal and professional data, and constrain the scope of the remote wipe capability to the organization’s proprietary data, leaving the end user’s personal data untouched. In addition, this approach would potentially address the privacy concerns many users have about turning their personal devices over to the control of their employer’s IT department.

Another growing threat to mobile data security is the explosion in mobile malware and network-borne threats. These are additional threats, under which MDM solutions fall short. Because an MDM solution works at the device level, if mobile malware manages to get on the device, it can access and exfiltrate proprietary data on the device. If the device is connected via a device-wide IPSec VPN to data center assets, the malware could potentially spread or gain access to data center resources as well. If the data were secured using fine-grained encryption (i.e. each data chunk encrypted with its own unique, long encryption key) then a malware data thief would have a very difficult time recovering anything useful in a timely manner.

Similarly, if a user connects to the internet via an insecure WiFi hotspot, all proprietary data should be encrypted on the wire or face the risk of a man-in-the-middle attacker gaining unauthorized access to sensitive data. An application level VPN can help to protect data-in-motion from this sort of threat. Unlike the device-wide VPN policy, an MDM solution can manage the application-level VPN and prevent other applications on the device from accessing intranet resources.

Managing devices can provide a minimum baseline for security compliance. However, organizations should focus instead on deep security of their applications and data itself, regardless of whether it resides on IT-issued or user-owned devices. This data-centric approach is especially important in scenarios where non-employee collaborators such as partners, contractors, and consultants require access to sensitive data.

In these scenarios, MDM/MAM solutions are particularly ineffective because IT cannot realistically mandate these external entities to subscribe to their particular MDM/MAM policies and applications. By combining encrypted storage with encrypted transmission at the application layer, an organization can help to ensure that their data is managed and as safe as possible from potential security threats. The solution should provide these benefits even when authorized business collaborators, such as partners and contractors, who are not subject to corporate IT policies access the data.

To learn more about how Sencha solutions can help to address mobile data security challenges, please click here.

20140227-space-security.jpg 2 Comments   Read more

The HTML5 Scorecard: The Good, The Bad and the Ugly in iOS 7

We’ve been testing the final release of iOS 7 over the last few days against our usual battery of HTML5 tests. Normally we’re effusive about new releases of iOS to the point of fanboy-dom, but this time, and for the first time ever, we’re disappointed in the execution of iOS software. Although there are some impressive performance gains in SVG and JavaScript, the sheer number of bugs and broken features, clearly mark this release as a beta. While nowhere as bad as the Android 3 browser — our all time champ of broken web releases — we recommend that organizations standardized on HTML5 development hold off upgrading until an iOS update fixes these issues.

Update for iOS7.1 Mar 12, 2014: the iOS7.1 release happily fixes almost all of the web problems in iOS7.0 that we describe in this blog. Read our recent blog entry describing the HTML5 improvements in iOS7.1.

iOS 7 Bugs & Features

Max Firtman has already done an excellent first pass about the new features, bugs and quirks in iOS 7’s web runtime. If you haven’t read his post, you should read it now. We will not repeat all the findings here; but to review, there are two very big bugs in iOS 7. First, WebSQL permissions to increase the default 5MB of space for an app to the previously permitted 50MB limit no longer work correctly, and require a workaround. Second, “Save to Home Screen” apps are basically broken. Once more than four apps are saved to home screen, the save slots are recycled and sometimes duplicated, and the phone has to be rebooted in order to clear itself. Further, any external URI no longer opens correctly and all JavaScript modal dialogs (alert, prompt etc.) are disabled. Finally, If your app uses AppCache and you are managing state via hash or other mechanisms, the history object will never update, disabling history.back.

We recommend that organizations standardized on HTML5 development, hold off on upgrading to iOS 7 until an update fixes these issues.”

Beyond these major bugs, there are also some very troublesome design decisions in iOS 7. First, there is no way to hide the URL bar using JavaScript (and the user no longer has a “full screen” button in mobile Safari). This will throw a wrench into layouts if your app relies on absolute positioning. One workaround, suggested by Andrea Giammarchi, is to ask the user to take an action (such as swiping up) in order to reset into full-screen. But there is no programmatic way to do this (as of yet). And once you are in full-screen, tapping anywhere in the bottom region first summons the browser chrome and there is no way to cancel this. This makes for poor UX for bottom-positioned toolbars: the first user tap summons the browser chrome, which boosts the tool-bar up the page, and then requires the user to tap again to take an action. There are related problems with the status bar which can be worked around.

In addition to these decisions, right and left swipe gestures within about 10 percent of display edge are always grabbed by iOS and treated as a forward/back request, and not passed to the browser. Furthermore, if you’ve built back/forward behavior into your app using history push-state, then accidental swipes will load the previous state as if it was a prior web-site. This will probably be unexpected behavior. Chrome for Android was the first browser to introduce this behavior, but has now removed it based on feedback from web developers. We hope Apple follows suit quickly.

In our own testing, we discovered a number of additional bugs in the iOS 7 runtime.

  • On iPad, an orientation change when an input is focused shifts content unpredictably, and causes screen rendering artifacts.
  • Launching and quitting the same home screen app several times can hard lock the device requiring a hardware reboot.
  • requestAnimationFrame animations do not appear to background correctly, and cause performance degradation in RAF animations on the active page. This defeats one of the major purposes of using RAF animations.
  • On iPad, if the document body is set to 100 percent height, content is shifted upwards by 20px in landscape mode. This can be worked around by calling window.scrollTo(0, 0) on the orientationchange event.
  • In certain cases, resizing a composited layer (an element with 3D transform) does not repaint it correctly. Instead, the cached bitmap is stretched.
  • CSS Animations will sometimes fire before implicit z-indexes have been calculated, resulting in incorrect z layering during an animation.
  • Scripts running within Web Workers are not suspended unless either the originating page is explicitly killed, or the Safari process is explicitly terminated. Neither switching to another tab, nor minimizing Safari, nor turning off the screen seem to stop Worker execution. This is a serious issue that allows any web page to drain the battery of an iOS 7 device and slow down performance of the whole system without a user alert.

Performance Characteristics

In addition to feature/bug testing, we also put iOS 7 through a battery of our standard performance tests on an iPhone 5 running iOS 6.1 vs. iOS 7. There are some remarkable increases in benchmark performance as well as some very notable misses. First up, we want to note that something odd has happened to the JavaScript timer on iOS 7. In previous versions, iOS had an exceptionally well implemented timer: 4ms with extremely good consistency (see below). But using John Resig’s standard timer test resulted in this odd profile: a timer that jumps between 4ms and 12ms with clockwork regularity and much more noise than iOS 6.

iOS7 timer

Figure 1A: JavaScript timer resolution: iPhone 5/iOS 7

iOS6 timer

Figure1B: JavaScript timer resolution: iPhone 5/iOS 6

Perhaps this is a limitation of the test in some way, but it’s certainly nothing we’ve ever seen before, and one more reason to make sure that you use requestAnimationFrame for JavaScript animation.

In good news, raw JavaScript performance has increased substantially. SunSpider 1.0 is about 15% faster on iOS 7 vs iOS 6.1, and iOS 7’s Octane score is 70% better vs. iOS 6. Some Octane tests showed dramatic speed-ups: Navier-Stokes performance increased by almost 4x. By comparison, Safari on my 2 year old MacBook clocks in at 5,600 — so iOS 7 is now 50% as fast as desktop Safari on Octane! This is either some serious JIT hacking, or we also speculate that there may be some GPU offloading of general computation in iOS 7?

iOS7

Figure 2: Octane Benchmark – iPhone 5 iOS 6 vs. iOS 7 (higher is better)

But it’s not all good news on the performance front. During the iOS 7 beta, we were concerned at the very slow DOM interaction benchmarks that we were seeing from Dromaeo on iOS 7, and expected that Apple would get performance back to snuff before final release. For DOM traversal, attributes and modification, performance is now back at iOS 6 levels, which is good. However DOM Query is still 50% of iOS 6 speed. This is a major concern for the many HTML5 apps that perform high numbers of DOM queries, and this needs to be on Apple’s fix-list for its next update.

iOS7

Figure 3: Dromaeo benchmark – iOS 6 vs iOS 7 (iOS 6 = 1.00 – higher is better)

Graphics Performance

Test of Canvas performance show a minor improvement in iOS 7 — about 10% in the Fishtank test and on Mindcat microbenchmarks. But SVG is the real revelation. Thanks to a switch to a new drawing algorithm, SVG Path drawing speed has improved 200x. Yes that’s literally 200 times faster. In iOS 6, a 10,000 segment SVG path took about 11 seconds to draw. In iOS 7 that’s now 53 milliseconds. iOS is now 6x faster than the Surface RT — the previous champ at SVG drawing performance.

iOS7

Figure 4: SVG Path Drawing Benchmark (lower is better)

Other SVG capabilities experience similar speed-ups. Some SVG Filter operations now appear to be GPU accelerated — which means that meaningful filter animations are now possible on iOS. But performance is dependent on specific filters. Color transformations (Color Matrix & Color Curves) and displacementMaps are fast. Complex compositing and lighting effects are still slow.

And now the real killer. In the rush to get iOS 7 out the door, making sure SVG animation via JavaScript was fast seems to have been dropped on the floor. Animating SVG with JavaScript is now a hit or miss proposition. Animating 500 SVG circles used to be 50 fps on iOS 6. On iOS 7, the animation simply freezes after a few frames. We tried other apps that have interactive UI elements built with SVG, and we saw a similar severe performance degradation.

iOS 7: A Beta Release of Web

Given all these bugs and issues, combined with some genuine major advances, it’s hard not to interpret this as a beta release that was rushed into production for the release of the iPhone 5S. In a way, it reminds us of the Android 3 release — which was rushed into production for the Motorola Xoom tablet — with severe bugs and performance deficiencies. We’re eagerly awaiting the release of the first update for iOS 7 when we hope Apple delivers on its usual commitment to quality.

But beyond bugs, the design decisions in iOS 7 clearly privilege consumer content over business applications. We remain convinced that Enterprises that want to deploy HTML5 applications to mobile devices can’t rely on consumer browsers and need a secure and predictable mobile environment designed for business applications. iOS 7 has convinced us that more than ever that the future of HTML5 app deployment for business is Sencha Space.

20130924-iOS7.png 9 Comments   Read more