Applications on some iOS Devices do not Update
Regular App Store applications on some iOS devices do not update after the associated App Catalog Rule is updated with a newer version of an application. This is especially true for devices that do not check-in within 24 hours of the update of the App Catalog Rule.
- SOTI MobiControl v14.0.1 and older
- SOTI MobiControl older than 220.127.116.1167
When an App Catalog Rule is updated with a new version of an application, a command is generated for all devices targeted by that application. However, in the aforementioned versions of SOTI MobiControl, it purges all pending commands for an iOS device every 24 hours. So, devices that do not check-in within 24 hours of the update of the App Catalog Rule, will never receive the command to update the application.
Furthermore, since the process to update iOS applications depends on a change in the version of an application in an App Catalog Rule, without some help from Technical Support staff to simulate an application version change, the administrator would not be able to request MobiControl to update an application on that iOS device again until a new version of the application would be published in the App Store.
To address these concerns, the process to push a regular or VPP App Store application update to iOS devices has been revamped in later versions of MobiControl. Therefore, the customer is encouraged to upgrade to either:
- SOTI MobiControl 14.0.2 or greater
- SOTI MobiControl 18.104.22.16867 or greater
The process to push a regular or VPP App Store application update to iOS devices now requires an administrator to use the button named “Push App Update” in the Advanced settings of an application in the App Catalog Rule.
Upon confirming this action, MobiControl generates persistent commands for all iOS devices targeted by the App Catalog Rule. Since all device commands issued in this process are persistent, this new process does not require a device to check in within 24 hours of this administrative action. More importantly, in the case that the application update is not successfully installed on a device, because the user of a device rejects the update for instance, the administrator can request MobiControl to push application updates to iOS devices again without having to wait for a new version of the application to be published in the App Store.
Please note that repeated invocation of the "Push App Update" is highly discouraged because each invocation requests all devices to update their applications even if their application is up-to-date and therefore doing so can result in very high data usage rates for your iOS devices. To provide some protection against accidental repeated invocations, MobiControl will not request a device to update its application if the device command to do so is already queued for that device.
Finally, new device logs have been implemented to provide greater visibility and feedback into the various steps of this new process as shown below:
- After the "Push App Update" action is invoked by the administrator, the following log is displayed for the App Catalog Rule from where it was invoked:
"Update of application 'X' requested for 'Y' of 'Z' Apple devices targeted by App Catalog rule 'A'."
- For a device that was targeted by that App Catalog Rule and whose application was installed by MobiControl (ie. the application status is Managed), the following device logs indicate a successful request to update the application:
"Update of application 'X' requested."
"Successfully requested to install application 'X'."
- For a device that was targeted by that App Catalog Rule and whose application was installed by MobiControl (ie. the application status is Managed) and deployed using a device-based VPP license, but whose iOS version is less than 10.3, the following device log is generated:
"Update of application 'X' will not be requested because the device OS version is less than 10.3."
- For a device that was targeted by that App Catalog Rule and whose application was installed by MobiControl (ie. the application status is Managed), but for whom a device command to update the application is already queued, the following device log is generated:
"Update of application 'X' will not be requested because it has already been requested. It will be installed the next time the device checks in."