Delaying app updates

By default, App Catalog updates applications as quickly as possible after the update is released. Organizations may want to delay updates for a group of apps of even all apps to minimize the risk of installing updates containing bugs and potentially impacting the organization's productivity.

App Catalog allows setting up delay rules to granularly define an update delay strategy fitting the needs of the organization.

The delay is based on a number of days after the version date of the app with a maximum of 90 days.

The version date of the app might not be the release date of the app. Technically, the version date is the date the app was compiled.

Delay rules only apply for app updates. New app installations will always install the latest available version.

Delay rules

Delay rules allow granular control over which updates are delayed and for how many days. These rules can be very simple or very complex, based on your needs. Rules are evaluated from top to bottom in the Configuration Profile. The first rule that matches an app's Bundle ID will be applied.

A delay rule has the following properties:

• Bundle ID: The Bundle Identifier of the app. This includes support for wildcards, for example com.microsoft.* to delay all Microsoft apps or * to set the same delay for all apps.

• Delay in days: How many days to delay the app updates with a maximum of 90 days.

Delay rules are configured with the DelayAppUpdates key

Key: DelayAppUpdates

Value type: Array of dictionaries

Dictionary value types:

• BundleID (required): String, a valid app Bundle Identifier (Get an app Bundle Identifier) or wildcard.

• Days (required): Integer, number of days to delay.

Default: -

Examples:

Delay all app updates for 3 days:

<key>DelayAppUpdates</key>
  <array>
    <dict>
      <key>BundleID</key>
      <string>*</string>
      <key>Days</key>
      <integer>3</integer>
    </dict>
  </array>

Delay all Microsoft apps for 7 days and all other apps for 3 days:

<key>DelayAppUpdates</key>
<array>
  <dict>
    <key>BundleID</key>
    <string>com.microsoft.*</string>
    <key>Days</key>
    <integer>7</integer>
  </dict>
  <dict>
    <key>BundleID</key>
    <string>*</string>
    <key>Days</key>
    <integer>3</integer>
  </dict>

Delay all Amazon apps for 7 days and all Google apps for 3 days. All other apps are not delayed.

<key>DelayAppUpdates</key>
<array>
  <dict>
    <key>BundleID</key>
    <string>com.amazon.*</string>
    <key>Days</key>
    <integer>7</integer>
  </dict>
  <dict>
    <key>BundleID</key>
    <string>com.google.*</string>
    <key>Days</key>
    <integer>3</integer>
  </dict>
</array>

Best practices

We recommend setting the number of days to just a couple of days as shown in the examples. We only recommend setting a delay to 90 days for specific apps and uses cases where it is absolutely critical to delay updates and take more time to test the next version.

Popular main stream apps are updated every couple of days. If the delay is bigger than the time between updates being released, this might result in updates never becoming available.

Deployment rings

Organizations may want to deploy different delay strategies for multiple device or user groups. This can be achieved by deploying profiles with the domain nl.root3.catalog with just the DelayAppUpdates key. For example the following structure:

• Global profile for all users: contains authorization and other keys applicable to all devices

• Profile for developers group: contains DelayAppUpdates with different delay for certain development tools.

• Profile for early adopters: contains DelayAppUpdates with a small delay for updates for all apps or delay at all.

• Profile for all other users: contains DelayAppUpdates with delay for all apps.

User experience

If the end-user Catalog Apps is enabled, App Catalog transparently shows which updates are delayed and when those will be made available. The use can click on Updates > Upcoming Updates:

The delay rules are also visible in the Catalog App settings > Delay Rules: