Advanced Settings

Troubleshooting

Interaction

Navigation

Memory & Privacy

Remote Management Server

Temporary / Beta

Deprecated Features

Removed Features


Log App Events

This setting is for generating logs if you are experiencing an issue with Kiosk Pro. These logs are helpful to Kiosk Pro’s support team when helping you troubleshoot the issue.

Default: Off

When this setting is enabled, you will need to run the kiosk and replicate the problem.

These log files will be stored locally in the Kiosk Pro documents folder and must be manually retrieved at this point. They'll also continue to log over time if the feature is not turned off (which could theoretically result in a very large text file) so you will only want to use this feature for short-term troubleshooting (and not as a continuously running feature).

More information about transferring files from your iPad can be found here.


Log WebKit Requests

This setting allows you to generate a text log of all requests being made through the underlying WebKit browser. These http://  requests and responses can allow for troubleshooting of more advanced content (including AJAX and caching requests).

Default: Off

This type of logging is fairly intensive and can affect the behavior of the kiosk in certain instances.  Logging will continue over time if the feature is not turned off (which could result in a very large text file that could max out your internal storage) so you will only want to use this feature for session troubleshooting and not as a continuously running feature.

These log files will be stored locally in the Kiosk Pro Documents folder inside a folder called ‘___com.kioskgroup.application.logs___’ and must be manually retrieved at this point. More information about transferring files from your iPad can be found here.


Log Remote Management Server Events & Communications

Important: Do not enable these settings unless instructed by Kiosk Pro’s support team.

Default: Off

Troubleshooting Assistant

This setting allows you to create a bundle of information from your iPad to help us to troubleshoot problems with Kiosk Pro. The bundle can be emailed directly to us or, if you are using a paid version of the app that supports local file storage, can be stored locally and transferred via iTunes. You can also delete all current logs from this setting's navigation bar.

The following information will be sent to us:

  • iPad model
  • iOS version
  • Kiosk Pro version
  • a summary of your Kiosk Pro settings
  • any client.log files saved while ‘Log App Events’ is enabled in the Kiosk Pro ‘Advanced Settings’ menu

To store the troubleshooting bundle locally, tap 'Save Info'. To email it, tap 'Send Info'. Please note that in order to send the troubleshooting bundle, you will need to have a Mail account set up on the iPad.

Steps for setting up a Mail account:

  1. Open the iPad’s General Settings (silver gear icon).
  2. Choose ‘Mail, Contacts, Calendars’ from the sidebar and choose ‘Add Account’.
  3. Choose an email provider from the list and enter your login information for your email account.
  4. Make sure that the toggle for ‘Mail’ is On.
  5. Choose ‘Save’ and you’re ready to go.

Once you have a Mail account set up, you will be able to choose ‘Send Info’ from the navigation, which will bring up an email layout inside Kiosk Pro. If you have not already contacted our support team regarding the issue, please include a clear description of the issue you are experiencing in the body of the email including the steps required to replicate the problem.

If you think a screenshot will be helpful to us (if, for example, you are experiencing a problem with page layout or rendering), you can take one by pressing the Home button and Power button at the same time. The screen will briefly flash white to indicate that a screenshot has been taken and the screenshot will be saved automatically in the Photos app. You can include photos by holding your finger down in the email body for a second, then lifting up and choosing ‘Insert Photo or Video’.


Disable Tel: Links

Removed in version 8.4 due to change in Apple guidelines. Functionality now included as part of Disable Touch Callouts.

This setting tells the app to filter and disable tel: links within your content.

Default: On

Tel: links use a specific link scheme to provide a callout menu with additional options when linking to a phone number on a mobile devices. We've added this filtering as iOS does not provide any way to disable this phone callout functionality through native frameworks.

The callout menu shown includes options to call the number (on iPhone only), send a message, or add to contacts and can thus allow visitors access to phone and messaging apps or the contacts stored on the device, effectively exiting the kiosk app. If the device is being used in Guided Access mode, the pop-up will still be shown, but the options are disabled and do not respond to touch.

We generally recommend leaving this setting disabled, however there are some use cases where you may want to enable these links. Disabling tel:links will occasionally affect links using the pound sign (#). For example, if you have a link that brings the visitor to a specific part of a page using anchor tags, this could potentially be disabled.

If you do need to disable this setting, we highly recommend either removing any existing tel: links from your content as these may allow visitors to exit the app or access the Contacts stored on the device, or running the app in Guided Access mode.


Disable Touch Callouts

This setting allows you to control the use of touch callouts.

Default: On

Touch callouts are most frequently used to allow visitors to select elements on a page by holding their finger down until a pop-up appears with a list of options. While these generally will not allow visitors to leave Kiosk Pro, they can still be confusing to visitors and may allow access to and editing of information stored elsewhere on the device (such as Contacts).

Certain websites use touch callouts to approximate a ‘hover’ state on a touch device. If you are seeing a problem with a link, modal window, or lightbox plugin not opening as expected, you may want to try testing with ‘Disable Touch Callouts’ turned off.


Prevent iOS Drag & Drop

Added in version 8.5

This setting allows you to control the drag and drop functionality introduced in iOS 11.

Default: Off

The drag and drop functionality allows users to move data between apps. Since most use cases require the iPad to be locked down to Kiosk Pro, we've disabled this functionality by default as it could be confusing to users.


Preload Homepage Behind Screensaver

This setting gives additional control over how the homepage is loaded when the Screensaver is in use.

Default: Off

If enabled, this setting tells Kiosk Pro to load the homepage while the screensaver is running. This loads the homepage in a separate layer, allowing the app to transition immediately from the Screensaver to the homepage when the visitor touches the screen.

Loading the homepage in a separate layer can cause problems with certain types of content. iOS can only play a single video at a time, so this setting should be disabled if your homepage uses a video that is set to autoplay.


Show Keyboard Automatically on Focus Event

This setting determines whether to allow JavaScript .focus() events called on a page to automatically trigger the on-screen keyboard.

Default: Off

The on-screen keyboard takes up a large amount of screen real estate and it can be disorienting or frustrating for a visitor if the keyboard pops up automatically (as opposed to allowing them to trigger the keyboard manually by touching inside an input field).

There are applications where this type of automatic focus can streamline data entry, which is what this setting is for.


Screen Asynchronous Requests with Allowed & Restricted Domains

Added in version 8.4

This setting provides the ability to screen asynchronous requests to determine if a site is allowed.

Default: On

This screening happens post factum meaning that the page will load before it is blocked. When Kiosk Pro sees that the page is not allowed, it will display an error alert and immediately navigate to the previous page.


Clear Cache on Relaunch

This setting allows you to clear the app’s cache when the app is opened/relaunched.

Default: On

In most cases, keeping this on is recommended to help keep visitor information secure. In some use cases, you may need to turn this off to allow your content to remain cached.


Cache Source

Kiosk Pro uses web caching to temporarily store certain files and pages to increase the speed of page loading and to reduce bandwidth usage. To apply any changes to this setting, you must exit the app to the device's Home screen and relaunch it.  

This setting is only applied in Plus and Enterprise when the app's  Browser Engine setting is set to UIWebView.

Options:

  • Native UIWebView Cache (default)
  • Kiosk Pro Cache
  • Never Cache (may result in slower performance)

Due to the inability to completely clear the native browser cache in iOS 7 and 8, we implemented a custom caching system for Kiosk Pro, which requires that we load requests through a custom HTTP protocol. This means that Kiosk Pro Cache is incompatible with certain sites. If you are using Kiosk Pro Cache and experience problems, we recommend switching to the native caching. 

In iOS 9, the problem clearing the cache appears to be fixed and we have returned the default for this setting to native caching.  

Never Cache allows you to avoid caching altogether. As this option loads every asset directly from its source every time it is used, it may result in extended page loading times and other performance delays.


Only Notify Browser of Server Redirection Events

When using Kiosk Pro with the cache mode ‘Kiosk Pro Cache’, the app is designed to notify the underlying UI WebView browser about all redirections (even if the server has not returned a redirection response).

Default: Off

This is necessary because a page may use redirection history in a number of ways - for example, to standardize the format of a request for cache management (e.g., changing a request for 'http://www.apple.com' to the standardized, or canonical, version: 'http://www.apple.com/').

However, certain sites that use AJAX for browser requests rely on the browser only reporting redirections when they are requested specifically by the server.

For these sites, we’ve implemented a new advanced setting allowing you to toggle this behavior. If ‘Only Notify Browser of Server Redirection Events’ is enabled, the app is designed to notify the underlying UI WebView browser about a redirection if (and only if) the server has returned a redirection response.

This reduces the chance of the browser timing out with a ‘Too many HTTP requests’ error when looping through a series of intentional redirects and can prevent other unintentional side effects that appear when using the default behavior.


Analytics > Track Asynchronous Requests When Possible

The Page Usage Statistics in the Remote Management Server tracks visitor sessions by listing the pages that a visitor navigated and the time spent on each page.

Default: On

When enabled, this setting instructs the app to track asynchronous changes to the current URL that occur without an explicit page load event and report them to the remote management server as separate navigation steps whenever possible.

This setting is only supported when using the WKWebView Browser Engine


Server Version

The current version of the Server software can be determined by signing into the web interface and checking the top left corner for 'Console Version: X.Y.Z', which must then be entered in the format XXYYZZ.

Default: 040701

For example, 'Console Version: 4.7.1' would be entered as '040701'.


Request Timeout Interval

This setting allows you to configure how long Kiosk Pro should attempt a communication request with the Remote Management Server before timing out.

Default: 300

This type of timeout prevents Kiosk Pro from endlessly waiting for a response from the server that may be taking too long to respond. If a request times out, Kiosk Pro will attempt the request again the next time the communication timer is triggered.

A request can timeout for a number of reasons:

  • Problems with the server - for example, the server is offline, is experiencing heavy traffic, or experiences an error when trying to access the data necessary to fulfill the request and fails to send a response.
  • Problems with the device - for example, the device is attempting to contact the wrong address for the server or isn't connected to the internet.
  • Problems with the network - for example, the WiFi router is overtaxed with requests from other computers and devices or there is a firewall in place blocking access to the server.

A longer timeout period will increase the length of time Kiosk Pro will wait for a response and can increase the success rate of downloads in certain circumstances.

Transform Links for Guided Access

This setting addresses a bug introduced in iOS 8 for Apple’s UIWebView browser (which Kiosk Pro is based on).

Default: On

When a link is touched while Guided Access is enabled, the message ‘Guided Access is enabled’ appears at the top of the screen. When this setting is turned on, it will transform certain links in your content so that this message does not appear. See our  Known Issue for more details about which links can be transformed.

Disabling this setting is only recommended if you’re using Apple Configurator to lock down your app or if you aren’t using Guided Access.


Trigger Change Event After Autofill

Added in version 7.0

This setting triggers an "onChange event" when using the Autofill feature to help with form submission.

Default: Off

Some fields in a form will look for a change before the form can be submitted. When a field is Autofilled by Kiosk Pro, the field doesn't notice a change, so an "onChange event" will need to be triggered.

Allowed Link Path Depth from Homepage

This setting allows you to define how far your visitors can navigate from the homepage by setting a number of links allowed.

The default setting is empty, which means that this setting is disabled. Once a number is defined, Kiosk Pro will only allow that 'depth' of links to be followed before showing the off-domain alert (if enabled). For example, if this is set at '2', you should be able to navigate to any link on your homepage and any link on the page you navigated to before being blocked. It can be used in conjunction with allowed and restricted domains settings; if used at the same time, each link will be checked against these lists before being loaded and added to the 'depth' history.

The UI WebView browser that Kiosk Pro uses does not provide us direct access to the history of webpages loaded so the app attempts to construct its own history to access. Requests that are registered by the UI WebView as 'main' views are tracked, requests that are registered as 'frame views' (where part of a browser pane is loaded from another url, frequently used in page advertisements) or 'hidden' are ignored. As we must rely on UI WebView to categorize these requests, this functionality may perform differently depending on the content being shown and how it is categorized by UI WebView. We recommend testing with your content prior to implementation to determine the correct level of links required.

In addition, Kiosk Pro does not map all the links on the page so it is possible that your visitors will be blocked from following a link that would otherwise be allowed if they were higher in the navigation path. For example, let's say you set 'http://www.kioskproapp.com' as your homepage and an 'Allowed Link Depth' of '2'. If you follow the 'Tour' link at the top of the page, that sets you at a link depth of one, allowing you to navigate one page further. You touch 'Pricing' and you are now at a link depth of two (despite the fact that you could theoretically navigate to that page at a link depth of one). At this point, you are allowed to navigate back to the main homepage (which resets your link depth at zero) or to 'Tour' (which resets it to one), but you cannot navigate to 'Demos' (as that would put you at a link depth of three).


Allowed Links to External Apps

Removed in version 8.4 due to change in Apple guidelines

We initially provided this setting for users who wanted to be able to use Kiosk Pro in conjunction with their own app (which could then be programmed to call Kiosk Pro back when appropriate) or in a supervised situation where a user could manually relaunch Kiosk Pro when needed. 

Since Guided Access and Configurator's Single App mode both block calls to other apps, neither can be used in combination with this feature.  Due to changes in iOS 8 & 9, visitors can now exit an app if the Notification Center is available - the only way to block the Notification Center is by using Guided Access or Single App mode, which means essentially that this feature is only a workable solution for devices used with staff supervision.  

WARNING: This setting should only be used if you have a way to return your visitors to Kiosk Pro! Kiosk Pro is not able to run other iOS apps. While we can enable the custom URL handlers to allow you to call and open another app, there is no way for us to return control of the device to Kiosk Pro.

This functionality relies on custom URL handlers (also known as custom URI schemes), which are a way of linking between iOS apps through a specific string defined in the app's bundle files. Apps are not required by Apple to define a URL handler, so not every app has these implemented.

To find out if the app you'd like to run in combination with Kiosk Pro has implemented URL handlers, you may need to contact the developer of the app or check an archive of known URL handlers. For more information on implementing URL handlers in your own app, see Apple's documentation on 'Communicating with Other Apps' in the iOS App Programming Guide.

Calling an external app from Kiosk Pro

In order to call an external app, you will need to do two things:

  1. Enter the custom url handler's scheme name into the 'Allowed External App URL Handlers' input in Kiosk Pro settings.
  2. Use the custom url handler in the link on your .html page.

In Kiosk Pro settings, custom URL handlers should be entered as only names of schemes without ':' and '://'. Multiple handlers should be separated by a semicolon. For example, fileupload2;kindle

To call the app handler, you can use either the Address Bar to manually link or provide a link within your .html page. When calling another app handler, you should use the full address as described in the documentation for the app. For example, fileupload2:// or kindle:/home. If you are unsure about the URL handler being correct, you can test it by entering the entire URL handler into the address bar in mobile Safari. This should then open the app you are trying to call.

Example using the Youtube app with a URL handler 'youtube://'

In Kiosk Pro settings:

  • Allowed External App URL Handlers = youtube

In the .html page linking to the external app:

  • <a href="youtube://">Open Youtube App</a>
Calling Kiosk Pro from an external app

To return your users to Kiosk Pro, you can ask your app to navigate to the following URL handlers:

  • Lite* - kioskprolite://
  • Basic* - kioskpro:// (6.6 release or earlier) or kioskprobasic:// (6.7 release and later)
  • Plus - kioskproplus://
  • Enterprise through iTunes- kioskproenterpriseapp://
  • Enterprise through B2B - kioskproenterprise://

* Please note that while our Lite and Basic versions can be launched using these URL schemes, the 'Allowed Links to External Apps' setting is not included in either version and other apps cannot be launched from these apps, making this essentially a one-way launch. 

This will launch the app normally, showing the app's splash screen and then either the Homepage set in Kiosk Pro settings or the settings menu (if set to show 'On App Launch').


Enable Camera Rotation Fix

Removed in version 8.1 as underlying bug resolved in iOS

This setting compensates for a bug where iOS 8 orients the camera incorrectly.

Default: On

We have submitted a bug report to Apple regarding this issue. If the bug is addressed in a future version of iOS, turning this setting off should restore the previous camera behavior.

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