Web page is loading slower in Kiosk Pro than in mobile Safari?

Since it's introduction in 2010, Kiosk Pro has been based on Apple's UIWebView browser, which up until the introduction of iOS 8, was the browser that all third party apps accessing web content were required by Apple to use. UIWebView uses a separate (and slower) rendering JavaScript engine than the native mobile Safari browser, resulting in slower loading of your content. With that said, we do have a few suggestions for optimizing your content within Kiosk Pro:

Use the WKWebView Browser Engine

In iOS 8, Apple introduced a new browser shell, WKWebView, that is now available to third-party apps and uses the same Nitro engine as mobile Safari. 

In our 8.1 update, we added the ability to use WKWebView as the underlying browser. WKWebView doesn't support every app feature, so we'd recommend thoroughly testing your project before you make it available for the public. A list of non-supported features and known issues can be found here.

Optimize Kiosk Pro Settings

Many of the things that Kiosk Pro does (like hiding the copy/paste menus, for example) are done by manipulating a page at runtime, which extends loading times - while we attempt to optimize these transformations whenever possible, these also contribute to slower performance.

You can minimize the amount of processing Kiosk Pro is doing by using the following settings:

  • Access JavaScript API > Never (recommended only if you aren't using our JavaScript API)
  • Cache source > Native UIWebView Cache (exit and relaunch the app to apply)

In Advanced Settings:

  • Any setting you do not specifically need > Off.

With the settings above, you should see faster performance (although there are the tradeoffs of not being able to use these settings, which you'll have to weigh in the context of your own project).

Increase Touch Sensitivity

The UIWebView and WKWebView browser components interpret and pass touch events to the app. As a result, there's no way for us to increase the sensitivity or speed of a touch event.

UIWebView adds a 300ms delay after you touch anything to determine whether the user is single or double clicking. This delay is one of the most prominent reasons that HTML-based web apps are considered "sluggish" by many users.

In WKWebView, testing has shown that the 300ms delay is only added after a fast tap (<~125 ms), which the iOS interprets as more likely to be part of a double-click 'tap-to-zoom' gesture, and not after a slow tap (>~125 ms).  More detail on this  here

We've had several users see improvements with "sluggish" content by implementing FastClick or another library that eliminates this delay.

Still stuck? How can we help? How can we help?