Mac software arrives in two shapes: an installer package (.pkg) that runs a scripted install, and a disk image (.dmg) that holds an application bundle the user is meant to drag into Applications. Intune has an app type for each, and they are not interchangeable: what you can do with the app in Intune depends on which file the vendor gave you.
The two app types
| macOS app (PKG) | macOS app (DMG) | |
|---|---|---|
| What Intune does | Runs the installer package on the Mac through the Intune agent. | Mounts the image and copies the app bundle(s) at its top level into /Applications. |
| Install location | Wherever the package puts things: /Applications, /Library, launch agents, drivers. | /Applications only. |
| Pre- and post-install scripts | Yes, both, run as root. | No. |
| Detection | Included apps: bundle identifier and version, read from the package on upload. | Included apps: bundle identifier and version, read from the image on upload. |
| Uninstall | By bundle identifier of the included apps (files the package put elsewhere stay). | Removes the app bundle(s) from /Applications. |
| Signing | Vendor packages are signed; your own packages should be signed with a Developer ID Installer certificate to avoid Gatekeeper trouble. | No signing requirement for the image; the app inside should be notarised by the vendor. |
| Typical source | Vendors with installers (Zoom, Microsoft, Adobe, Google Chrome's enterprise pkg). | Drag-to-install apps (most of what Homebrew casks ship). |
Two shapes Intune does not take: a DMG that contains a .pkg rather than an app (upload the pkg itself instead), and a DMG whose app sits in a subfolder (Intune only copies bundles at the top level of the image).
Choosing when the vendor offers both
- Need a launch agent, a kernel or system extension, a licence file dropped into /Library, or anything outside /Applications? PKG, and probably a post-install script.
- A plain application the user would otherwise drag to Applications? DMG is simpler and has no scripts to maintain.
- Want to run something before or after the install (remove the old version, write a preference, disable the vendor's own updater)? PKG; DMG cannot.
Detection: bundle identifier and version
Both types detect through the included apps: for each app bundle, the CFBundleIdentifier and CFBundleShortVersionString from its Info.plist. Intune reads them when you upload the file and you can edit them. The install is considered successful when an app with that identifier and that version is present.
- The version Intune compares is the short version string, not
CFBundleVersion(the build number). A package whose marketed version is 6.5.3 but whose short version string reads 6.5.3.12345 will be detected as something else; use the string from the bundle, whatever it says. - Self-updating apps (browsers, Zoom, Slack) move past the version Intune expects within days. Intune then sees "wrong version" and reinstalls the old one, which the app updates again. The Ignore app version setting detects by identifier only and is the right choice for any app that updates itself.
- Universal versus architecture-specific builds. Intune has no architecture requirement rule for macOS. Deploy the universal build where the vendor offers one; otherwise two apps (Intel and Apple silicon) filtered by device attribute.
Updating a Mac app
Unlike Win32, a new version is not a new app object: you upload the new PKG or DMG to the same Intune app and adjust the included apps' version. Devices that report the old version get the new file at their next check-in. There is no supersedence relationship and no built-in staged rollout; rings are something you build with groups and timing.