[11.4] Mac Application Deployment: PKG, DMG, and the App Store

This entry is part 6 of 9 in the series Phase 11 - macOS

macOS application deployment through Intune works differently from Windows in ways that matter for packaging, detection, and ongoing lifecycle management. The concepts from Phase 7 apply – detection logic needs to be accurate, assignment intent needs to be deliberate, and packaging needs to be reliable – but the mechanisms are different.

There are three primary deployment paths for macOS applications in Intune: PKG packages, the Mac App Store through Volume Purchase Program licensing, and shell scripts for applications that need a wrapper around a DMG installer or a custom installation process.


PKG is the cleanest and most reliable macOS deployment model. A PKG file is a native macOS installer package – it installs through the macOS installer subsystem, supports pre and post-install scripts, and produces predictable installation outcomes. Intune supports PKG deployment natively – you upload the PKG, configure detection rules, set assignment intent, and Intune delivers and installs it. Detection for PKG apps typically uses file existence or version checks on the installed application bundle, or application bundle version queries. PKG is the right format for most enterprise macOS applications that ship a PKG installer.

The Mac App Store through VPP – Volume Purchase Program – is the right model for applications available in the App Store that you want to deploy at scale. VPP requires Apple Business Manager and a VPP token connected to your Intune tenant. ABM purchases or claims the app licenses, the VPP token syncs those licenses to Intune, and Intune assigns them to devices or users. Installation happens through the App Store infrastructure rather than Intune delivering a package directly – which means updates are handled by the App Store and you don’t manage the installation package yourself. For well-maintained App Store applications, this is the lowest operational overhead deployment model available.

VPP through ABM is the cleanest deployment model for App Store apps – no package management, no detection logic, updates handled by Apple. The prerequisite is ABM setup, which is worth doing regardless for the enrollment benefits alone.

DMG files – disk images – are supported as a native deployment type in Intune through the macOS DMG app type. You upload the DMG directly, Intune instructs the management agent on the device to mount it and copy the application bundle to the Applications folder. The macOS DMG deployment requires the Intune management agent to be installed on the device and treats the installed application as unmanaged – meaning Intune cannot automatically remove it if the device is unenrolled. For most applications distributed as DMG, this is the cleanest deployment path. The older approach of converting DMGs to PKG using pkgbuild or shell script wrappers is no longer necessary for most scenarios.

PKG deployment has two variants worth understanding. The Line-of-business app type handles signed PKGs – the PKG must be signed with an Apple Developer ID Installer certificate, must install to the /Applications directory, and must not contain nested bundles or disk images. LOB PKGs can be marked “Install as managed,” which enables Intune to uninstall them through an Uninstall assignment. The macOS app (PKG) type handles complex or unsigned PKGs – those with custom install locations, multiple components, pre and post-install scripts, or that don’t meet the signing requirements of the LOB path. Complex PKGs installed through the macOS app (PKG) type are also treated as unmanaged and cannot be automatically removed by Intune.

Shell scripts in Intune for macOS run as the management agent with elevated privileges, or optionally as the logged-in user. They support pre and post-install logic, can be used for application installation, configuration, and remediation, and run once or on a recurring schedule. The intune-my-macs repository uses shell scripts extensively – Company Portal installation, Dock customization, and Escrow Buddy are all deployed as scripts rather than as packaged applications.

Detection logic for macOS applications follows the same principles as Windows – check for something that uniquely and reliably indicates the application is installed. For application bundles, checking the CFBundleShortVersionString in the Info.plist at the expected installation path is the most reliable approach. It gives you both existence and version confirmation in a single check. Applications that install to unexpected locations or that update their bundle path between versions need detection logic that accounts for that variability.

Microsoft applications – Office 365, Teams, Edge, Defender, Company Portal – should all be deployed through Intune rather than left for users to install manually. The intune-my-macs repository handles most of these, but verify the versions being deployed are current and that update mechanisms are configured – Microsoft AutoUpdate (MAU) keeps Microsoft applications current on macOS and should be deployed and configured alongside the applications themselves.

Phase 11 - macOS

[11.3] Mac Compliance [11.5] Mac Baselines: Configuration Profiles vs Settings Catalog

Intune Deployment Guide · Phase 11: Mac Management
‹ Previous: [11.3] Mac Compliance
Next: [11.5] Mac Baselines: Configuration Profiles vs Settings Catalog