Skip to main content

Automatic updating of iOS/iPadOS Kiosk

What

FileWave Kiosk on iOS and iPadOS is the self-service application that lets users open Kiosk, view Kiosk-associated content, install available items, and trigger actions such as Verify.

Starting with FileWave 16.3.0, the current delivery method for iOS/iPadOS Kiosk is the Apple App Store version of the app, deployed as a VPP / Apps and Books app. As long as FileWave is correctly syncing with Apple School Manager (ASM) or Apple Business Manager (ABM) and the required FileWave Kiosk licenses have already been acquired there, the FileWave server will push the App Store Kiosk to managed devices and replace the older Kiosk.

App Store listing:

When/Why

This is the current and recommended behavior for FileWave 16.3.0 and later. The move to the App Store / VPP model aligns Kiosk deployment with Apple's current best practices and with the way other MDM and UEM platforms typically deliver managed iOS and iPadOS applications.

The most important operational change is that administrators should not treat the Kiosk upgrade as fully self-contained anymore. Before upgrading to FileWave 16.3.0 or later, make sure FileWave is connected to ASM/ABM for app-license sync and that enough free FileWave Kiosk licenses have already been obtained. If those preconditions are in place, the transition is straightforward. If they are not, Kiosk deployment can be delayed or fail to appear when expected.

The section below focuses on the current 16.3.0+ behavior first. A short reference section for 15.3.0 through 16.2.x is included afterward for customers who have not upgraded yet or who need historical context.

How

Current behavior in FileWave 16.3.0 and later

Before upgrading to FileWave 16.3.0 or later:

  • make sure FileWave is syncing Apps and Books / VPP licenses from ASM or ABM
  • acquire free licenses for FileWave Kiosk in ASM/ABM before the upgrade
  • obtain licenses for more devices than are currently managed so normal growth does not create an avoidable shortage

A practical example is to acquire about 1500 licenses if you currently manage 1000 devices.

If the licenses are already present before the upgrade, devices remove the older enterprise Kiosk and install the new App Store Kiosk shortly afterward, typically within a few minutes.

If the licenses are only acquired after the upgrade, the change is less immediate. In that case, purchase the licenses, run a Model Update, and then Verify the affected devices. If some other model change is made and pushed, that should also trigger verification. Without that follow-up activity, devices may not receive the new Kiosk until their next normal verify cycle, which can be up to 24 hours later.

There is currently no in-product warning that tells administrators they upgraded without the needed Kiosk licenses. If VPP is configured but the app has not been acquired in ASM/ABM, one useful clue is in filewave_django.log, which can show:

  • No VPP organizations have the App Store Kiosk purchased.

Permissions and profile updates

Because the App Store Kiosk is a new app, iOS/iPadOS treats it as a different application even though it serves the same purpose. Administrators should expect permission prompts such as notifications or location services to appear again after the transition.

The new iOS/iPadOS Kiosk app uses this bundle identifier:

  • com.filewave.ios.app.kiosk3

If you deploy a configuration profile that forces notifications or uses any other app-specific payload for Kiosk, review and update that profile for the new bundle identifier before or during the FileWave 16.3.0 transition.

Reference: behavior in FileWave 15.3.0 through 16.2.x

From FileWave 15.3.0 through 16.2.x, FileWave automatically deployed the newer iOS/iPadOS Kiosk through the older built-in workflow rather than the App Store / VPP model used in 16.3.0 and later.

In that earlier behavior:

  • FileWave automatically installed the new Kiosk on managed iOS/iPadOS devices
  • the older App Portal web clip was removed from devices
  • filesets of the previous native App Portal were not automatically removed, so administrators could remove those associations if they wanted only the newer Kiosk present
  • newer Kiosk releases continued to be deployed automatically through that same pre-16.3.0 workflow