Deploy a .pkg App to Macs with Intune

Distributing a line-of-business app across a Mac fleet by hand doesn't scale: every manually installed machine is a source of errors, omissions and divergent versions. Intune lets you deploy a signed .pkg package centrally, with automatic install detection and group-based assignment. Done well, this deployment guarantees each Mac gets the right application, in the right version, with no user intervention. Here are the key steps and the pitfalls to avoid to get it right the first time.

Prepare and sign the package

Intune accepts macOS apps in .pkg format. The preparation phase decides success: a malformed or unsigned package fails silently, with no clear message, making diagnosis frustrating.

The right format and signature

The package must be a genuine .pkg installer, signed with a valid Developer ID Installer certificate. Files in .dmg format or .app bundles must first be converted to .pkg. Without a valid signature, installation is blocked by macOS security mechanisms.

• Use a .pkg file (.dmg or .app must be converted beforehand).
• Sign the package with a Developer ID Installer certificate.
• Ensure a fully silent install, with no clicks or windows required.
• Note the app's exact bundleId for the detection rule.

Identify the bundleId and version

The bundleId (for example com.vendor.myapp) is the app's unique identifier. Combined with the version number, it lets Intune know whether the app is already present and up to date. Take the time to record it exactly: a single typo throws off the entire detection.

Configure detection and assignment

When adding the app in Intune, you set the detection rules and then choose whom to push the app to. Intune uses this information to install, update or skip the package on each Mac.

1. 1Add the app in Intune as a macOS app (PKG).
2. 2Upload the signed .pkg package and fill in the metadata.
3. 3Enter the bundleId (e.g. com.vendor.myapp) as the detection rule.
4. 4Specify the expected version to detect required updates.
5. 5Assign to a device or user group in required mode.

Monitor and troubleshoot

After assignment, watch the installation report in Intune: it shows, machine by machine, the succeeded, pending or failed statuses. Always test on a pilot machine before a broad rollout, to isolate issues before they hit the whole fleet.

The most common failure causes

Most failures boil down to a few recurring causes, easy to fix once identified.

• Package unsigned or signed with an expired certificate.
• Wrong bundleId, preventing Intune from detecting a successful install.
• Missing dependency the app expects at startup.
• Installer that requires user interaction instead of being silent.
• Version entered in Intune different from the one actually installed.

Repackaging a .app or .dmg into a signed .pkg

Most line-of-business macOS apps ship as a .dmg or as a bare .app bundle, two formats Intune cannot install directly for a supervised deployment. Repackaging into a signed .pkg is not an optional formality: it is the brick that makes the deployment reliable and detectable. Concretely, the macOS pkgbuild tool builds an installation component from the application, productbuild assembles it into a distributable installer, and productsign applies the essential Developer ID Installer signature. Once you have run this chain once, it scripts cleanly and replays in seconds for every new version.

1. 1Extract the .app application from the downloaded .dmg and place it in the expected Applications folder.
2. 2Build a component with pkgbuild, pointing at the app and its install location.
3. 3Assemble the final installer with productbuild to obtain a distributable .pkg.
4. 4Sign the package with productsign and a valid Developer ID Installer certificate.
5. 5Verify the signature with pkgutil before uploading the package to Intune.

This repackaging has an often underestimated benefit: it makes you independent of vendors' packaging quirks. Whether the supplier ships a .dmg this time and a .zip the next, your internal process always produces a consistent signed .pkg, with the same detection bundleId and the same test procedure. That regularity is what turns app deployment into a predictable routine rather than an investigation with every new release.

Deployment best practices

Document each application's bundleId, version and target group in a shared reference. Deploy first to a small pilot ring, then widen in waves. Keep the previous version until correct operation is confirmed, and schedule major updates outside peak hours to limit user impact.

An exact bundleId and a signed package prevent 90% of macOS deployment failures.

A concrete example

An IT team needs to deploy a line-of-business VPN client to fifty Macs. The first attempt fails: the Intune report shows installations stuck in a loop. On investigation, two classic causes emerge. First, the package supplied by the vendor was actually a .dmg containing an .app, never repackaged into a signed .pkg installer. Second, the bundleId entered had a typo (com.vendor.vpnclient instead of com.vendor.vpn.client), preventing any detection. Once the package is correctly signed and the bundleId is fixed, deployment reaches 100% success on the pilot ring, then rolls out fleet-wide without incident.

This example shows that most troubleshooting happens upstream, in preparation. A pilot of a few machines reveals these flaws immediately, whereas a direct rollout to the whole fleet would have turned them into fifty simultaneous tickets. Spending ten minutes verifying the format, signature and bundleId saves hours of correction later. It is the single highest-return habit in macOS app deployment.

Managing the application lifecycle

A successful deployment is only the beginning: an app lives, receives security updates and sometimes ends up being retired. Think about the full lifecycle from the start to avoid a fragmented fleet a few months later. Intune helps you track installed versions and push new ones, but it is your organization that must frame the pace and the deployment waves.

• Track the installed version on each Mac via the Intune report.
• Publish updates in waves, starting with the pilot ring.
• Keep a rollback procedure in case of regression.
• Plan the clean removal of obsolete applications.
• Document bundleId and target version in a shared reference.

This lifecycle discipline turns a one-off deployment into a controlled process, the condition for a Mac fleet that stays genuinely consistent and compliant over time rather than drifting version by version.

How AuPoint helps

AuPoint streamlines macOS app deployment by guiding you step by step, with no PowerShell or obscure configuration. You assign your apps in a few clicks, with an impact preview before deployment, clear install tracking and reversible policies if something goes wrong. The result: a well-managed, consistent and compliant Mac fleet, with no scripting skills required.

Frequently asked questions

Can you deploy a .dmg directly?

The .pkg format is the one expected for reliable deployment with detection. Content shipped as .dmg or .app must be repackaged into a signed .pkg installer before being added to Intune.

How do you force an app update?

Simply upload the new package and enter the higher version number. Intune compares the version detected on the Mac and triggers installation when it is older than the expected version.

What happens if the bundleId is wrong?

Intune cannot confirm the installation and may retry it in a loop or mark it as failed. Correcting the bundleId in the detection rule usually resolves the problem immediately.

Do you need Apple Business Manager to deploy a .pkg?

No. A line-of-business .pkg package deploys directly through Intune without Apple Business Manager. The latter becomes useful for distributing App Store apps through volume licensing (VPP) or for automated device enrollment, but it is not required for your internal packages.

Ready to deploy your macOS applications without jargon or command lines? With AuPoint, push your .pkg packages to the right group in a few clicks and keep a consistent, compliant Mac fleet.