[iOS vs Android] OS and Application Updates

I frequently get this question from customers and partners: “How can I control Application and OS Updates in iOS and Android“. So I’ll drop a note here.

Update management includes:

  • Configuring the behaviour of OS upgrades (major), patches, public apps (via App/Play Store, VPP) and private apps (via App/Play Store or directly via EMM)
  • Scheduling updates to happen (or NOT happen) at specific times For example, do not update between 8AM and 6PM, when the user is working.
  • Manually pushing or rolling back an update to a single device or group of devices (troubleshooting, 0day immediate security patch etc)
  • Controlling the visibility of update to the user, or blocking an update to specific devices altogether (known compatibility issue with business/mission-critical apps)
  • Version control: i.e. upgrade to version X, not just to the latest version available. A very common case with public app stores.
  • Pre-release support: alpha/beta users, multiple adoption rings.
  • Controlling the updates delivery to that they only happen on Wi-Fi, or on Cellular.
  • Granular control of all of the above per device group/type, per user group/name/type, per app etc.
  • Controlling user ability to influence any of the above (allow costly cellular updates, defer/deny critical updates, update manually to an unsupported OS version etc)

Suddenly, things are not that simple, are they? Long story short, the winner is BY FAR the …Windows 10! 🙂 Watch the video on managing Win10 Updates with UEM here (tech and WorkspaceONE implementation and design/philosophy – much recommended). Now, let’s go back to iOS and Android an see what have we got there.

NB: This info may become out of date when new OS capabilities are released. If you notice anything outdated – leave a commend and I’ll update the post.

Controlling OS Updates

Honestly, both iOS and Android don’t give you much. Both Apple and Google really want the users to be safe and sound, and thus are very strict at pushing patches timely. The best you can expect is delaying the OS update up to 30 (Android) or 90 (iOS) days. In both cases, this only affects the Work-Managed/Supervised devices. Also, in both cases, if the user sees the “Update” button – they can manually initiate the update, and there’s no doing anything abou-a-wow-t it.

Configuring OS Update policy in Android (Android Enterprise 6.0+, Work-Managed)

Configuring OS Update policy in iOS (11.3+, Supervised)

Android also allows you to set the maintenance window, while iOS allows checking for update availability in console and force-pushing update to one or more devices. Forcing an Android OS update basically requires pushing the System Updates profile with “Install Updates Automatically” setting, and then reverting it to the default. (Something that can be automated with WS1 Intelligence)

Both OSes are very strict on downgrading, especially downgrading to previous major versions, which is often time-limited or plain impossible.

Android can differentiate between major OSes and security updates, but only for the purposes of display. So, for scheduling purposes both OSes cannot be set up with a policy like “Install patches, but not the major upgrades”

Android patch level in Device Details pane

All this puts extra strain on enterprises having their own internal apps. The possible solutions here are the ones that put OS Update management under full MDM control like Samsung E-FOTA or just going to rugged devices, where over the air updates do not exist (updates are pushed as special packages via MDM). In both cases there is difference between security patches and major updates (Zebra, for instance, usually patches N-1 or N-2 previous major versions under their LifeGuard program). But in this case you are limited to Android only.

End result (OS Updates).

Manual push +/-++
Control user+/-++
Control visibility+/-++/-
Control delivery+

Stock Android options are less than iOS, but some vendors took care of it, allowing for precise update management. However, honestly, they both have ways to go. For comparison, a click for a screenshot of update management options in Windows 10 (then click again to zoom in) 🙂

Application Updates

Now, let’s take a look at app updates. This will be easy. If you want full control – publish your apps as Internal/Private. This way you control who, when, how will get what. However, even there some differences exist. Read here how to manage Private apps for Android Enterprise, and
(coming soon) for Private app management for iOS. Both OSes have pros and cons when it comes to private app management, but since the subject of this post is update management, we will omit them.

In addition, Android allows for more custom options that enable complex update provisioning (mostly for Work-Managed devices)

Advanced device Provisioning actions for Android with WorkspaceONE UEM 1811

With public apps (coming from the App/Play Store), things are a lot simpler. Because there is a lot less that you can do!

Targeting a specific version: impossible. In both Android and iOS there is only one version for upgrades: the latest. This is causing royal pain for some large enterprise customers, due to the next point

Scheduling/blocking, controlling delivery (i.e Wi-Fi only)

  • iOS – Impossible (unless you are using the firewall methods and block App Store completely). Similarly, there is no way to prevent iOS from updating the apps over the ($$) cellular connection. According to this page, iOS has a hardcoded 150MB limit – larger apps only update over Wi-Fi (i.e. good luck force-pushing an update).
  • Android – since recently Google had made some changes to Play APIs and we now have some degree of control, including blocking updates whatsoever, allowing them on wi-fi only or setting the update window (so that the apps only update after hours, for examples) . However, this works for ALL apps. Controlling this for individual apps is (currently) impossible. Not enough, but better than nothing.

Actually, Play Store offers APIs that could technically enable manual per-app update, and thus (in combination with “never auto-update”) the scheduled per-app version control. 

Auto Update profile for Android (WorkspaceONE UEM 1811)

Preventing user from manually updating the app. This may be useful when a known compatibility issue exists. On iOS this is impossible. On Android – also impossible, unless you block ALL updates and lock down the user from seeing the Play Store app. Basically, impossible.

Rollback. Another impossible feature, since the public app stores only offer the latest version of the app.

Beta Versions. According to Apple’s App Store Guidelines, “Demos, betas, and trial versions of your app don’t belong on the App Store – use TestFlight instead “. But TestFlight it is not integrated with MDM. Your best bet is Private app distribution. With Android since recently, when assigning an app to specific smart groups, you may choose if you want alpha/beta or production version and integrate with the Google Play Developer accounts of your trusted developers (in-house or 3rd party).

Assigning alpha/beta version of an Android public app via WS1 UEM

VPP (Volume Purchase Program) – Apple strikes back!

OK, so for “fully” public apps, Apple has nothing. But there is also VPP, which is something in between the fully public and fully private apps. The apps come from public App Store, but they are Enterprise-managed. Many free apps can also be “purchased” via VPP. Why is this important? With properly configured VPP distribution, you get control over the app updates. Per App!

There is some work to be done, you still can only target the latest version and cannot update on wi-fi only, but this is better than nothing! (A recurring slogan by public apps management in both iOS and Android 🙂 )

Apple VPP enable useful per-app update management functions on iOS

For justice sake, Google also offers VPP but it is (at the time of writing this post) limited to US/Canada only and I don’t know anyone who’d seen it live.

End result (App Updates).

Version Control+++/-
Manual push+-/++
Control user++/-+
Control visibility+-/++
Controlling delivery ++
Advanced provisioning+

Basically, if you want control – use private apps or at least VPP. iOS without VPP is useless. Stock version of Android offers some features, but still not that far ahead. Google’s VPP effectively does not exist.

Grand summary

If you come from Desktop Management or legacy WinCE/Mobile operations world, Update management sucks by both iOS and Android. However, in most cases those advanced management features are simply not required (otherwise they would have definitely been implemented).

Those wanting full control over app versioning can leverage Private apps or at least VPP. Both Apple and Google are paying closer attention to the matter of updates than 2-3 years before, so we may expect improvements on that front.

What are your thought, have I missed anything?


3 thoughts on “[iOS vs Android] OS and Application Updates

Add yours

  1. Hi Arsen great article… for android enterprise is it not possible to implement version control of the app is uploaded to the App Store as a private app ?


    1. Sure. If the app is in the Managed Play Store – version control may be possible if you upload the APKs yourself, or if your developer (who publishes the app to your managed store) had created a version track for you. I have blogged on these topics last year.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: