Fleet-maintained apps: Remove equivalent VPP app by default

[noahtalerman]

• @noahtalerman: numa wants to migrate from App Store (VPP) apps to Fleet-maintained apps. If possible, I think it makes sense to update the default behavior for FMA installs to first check if the VPP app is installed and if yes, uninstall the VPP app before installing the FMA.
  • This way the migration is "built-in" to VPP apps.

[noahtalerman]

@allenhouchins what do you think?

FYI @marko-lisica

[allenhouchins]

This will be fraught with issues and challenges. Why this would be challenging:

• We don't have an effective way of knowing which of our 960 macOS apps (and growing) have App Store equivalents and we would need to create an entire new ingester process to validate App Store apps for current and future FMAs. I did a rough pass and its around 10% of FMAs have an App Store equivalent half, of which have a completely different bundle ID than their FMA counterpart.
• We don't know what the App Store version of the apps' bundle identifiers are because some App Store apps have different bundle IDs than pkg/dmg deployments (ex: Slack). There's also no metadata source like homebrew or winget for App Store apps so it would be manually installing and validating to collect this info.
• We don't know all the directories and processes that need to be quit and uninstalled for an effective cleanup. This is metadata pulled from homebrew for FMAs. App Store versions would be different paths.
  • It's also not an uninstall they would be after but a migration of the user's settings and saved data which is in a different location and sandbox than the FMA. Otherwise they could just unscope the VPP app and have a label automatically install the FMA (or create a script-only package that closes this loop in one go).
• We tried automating this internally with Slack using custom scripts when we transitioned from VPP to FMA and it had a less than 10% success rate often leading to the app persistently crashing after install due to the migration of preferences and caches from one app domain to another. That was before good AI scripting though!
• We also don't reclaim licenses on uninstall for VPP apps yet (or have we implemented that?) so doing this at scale would get messy and clean up in Apple Business Manager would require further custom API work.
• Additional complexity I am overlooking that would need to be addressed in order to support international VPP stores.

No other MDM or app management solutions does this that I'm aware of.

I think it makes sense to update the default behavior for FMA installs to first check if the VPP app is installed and if yes, uninstall the VPP app before installing the FMA.

I think the key is the customer is likely not asking for an uninstall but rather a migration. Otherwise they could just stop scoping the VPP app and only offer the FMA installer. Naturally over time the VPP version would disappear from their environment short of them doing custom scripts to remove them more quickly. They could also only offer and run the FMA installer on top of their VPP apps to convert them to the FMA version but that means the preferences and saved data won't transfer in some cases which is why I believe they are asking for an uninstall + migration, not just an uninstall.

Do we have any sense of the scale of VPP apps this customer is using and which have FMA equivalents? This feels more like a CSA engagement than rewriting how FMAs work. This customer is currently using 32 FMAs of which only about 9 have App Store equivalents at a quick glance.