Managed app

How it works

Management is an attribute of the install, not of the app itself. On iOS and iPadOS, an app pushed by the MDM is flagged as managed; Apple introduced the concept with iOS 5 and later added the ability to take over an existing unmanaged copy with the user's consent, so nobody has to delete and reinstall. On Android, any app installed in the work profile or on a fully managed device is managed by definition.

Being managed unlocks three things. Settings can be pushed through managed app configuration. Data boundaries apply, so a managed app can be blocked from sharing documents with unmanaged ones. And removal is clean: when the device is unenrolled or the work space is wiped, the app and its data disappear.

The same binary can exist twice on a BYOD phone. A personal copy of a mail client with private accounts, and a managed copy holding the corporate mailbox. They don't share storage.

Why it matters for a fleet

This is what makes offboarding survivable. An employee leaves on a Friday, you wipe the work space, and the corporate data is gone by Monday without an argument about their photos.

It matters for compliance too. An auditor asking where company data sits on mobile wants a clear answer: these apps, managed, with these restrictions, removable remotely. A pile of user-installed apps gives you nothing to show.

Watch one detail. If a user installed an app personally before enrollment, it stays unmanaged until you convert it. Teams discover this months later, when a wipe leaves corporate documents sitting in an unmanaged copy.

How Appaloosa handles it

Apps deployed from Appaloosa are managed from the start, whether they come from Managed Google Play, Apple VPP or your own internal APK and IPA builds. The console applies managed app configuration, keeps version history, and removes apps and their data remotely when a device leaves the fleet. See the Mobile Application Management page.