Best Practices for Packaging macOS Apps for Intune Deployment

Introduction

Deploying macOS applications via Microsoft Intune (Endpoint Manager) requires preparing those apps in a format Intune can distribute. In the past, admins had to wrap apps into Intune's proprietary .intunemac format, but this is no longer necessary. As of August 2022, Intune supports uploading standard .pkg installer files directly, deprecating the old Intune App Wrapping Tool. This means you can package a Mac app as a .pkg (Apple's native installer format) and deploy it through Intune without additional wrapping steps. In this post, we'll cover the step-by-step process to create and package macOS apps for Intune, highlight best practices to ensure smooth installation, share real-world examples and configurations, and provide detailed guidance on tools, troubleshooting, and common issues. Whether you're deploying third-party software or an in-house app, these tips will help IT administrators manage macOS app deployments via Intune effectively.

Prerequisites and Requirements for Intune Mac App Packages

Before diving into packaging, let's review the key requirements and prerequisites for macOS line-of-business (LOB) apps in Intune:

• Use .pkg Installers: Intune now only accepts .pkg files for custom Mac app uploads. The legacy .intunemac format is no longer supported. If your app comes as a .dmg or .app, you'll need to convert it to a .pkg (we'll cover how). (Intune also introduced direct support for .dmg in certain cases – more on that later.)

• Package Size Limit: Ensure the package is not excessively large. Intune supports Mac app packages up to 8 GB in size, which is usually plenty for most applications.

• Developer ID Signature: Code-sign your .pkg with an Apple Developer ID Installer certificate. Intune requires the .pkg to be signed by a "Developer ID Installer" certificate (from an Apple Developer account). Unsigned packages or those signed with other certificates may be rejected or fail to install. Obtaining this certificate requires an Apple Developer subscription, so plan accordingly.

• Correct Package Format (no nested apps): The installer must be a valid macOS package – either a component package or a distribution package (which can contain multiple components). Do not simply zip up an app or include a .app bundle or .dmg inside the .pkg; Intune will not deploy such packages. Instead, the .pkg's payload should contain the files to be installed (e.g. the app bundle's files in the correct directories).

• Include a Payload: The .pkg must actually install something (have a payload). Packages with no payload will continually reattempt installation since Intune can't detect a successful install.

• Install Location – /Applications: Plan for the app to be installed in /Applications (the standard Mac applications folder). Intune's macOS app deployment currently supports apps that install to /Applications (or a subfolder thereof). If your package tries to install an app elsewhere, Intune may not consider the deployment successful. In practice, most app packages target /Applications by default, but if you create your own, you should specify the install location accordingly (we'll show how to do this with packaging tools).

• App Metadata (Bundle ID & Version): Ensure the application's bundle identifier and version information are present and correct in the app's Info.plist and in the package metadata. Intune relies on these to track installation. If the package's internal info is missing a version or bundle ID, Intune might fail to install it silently. We'll cover how to verify and set these values.

• Intune Management Enrollment: Naturally, devices must be enrolled in Intune (Microsoft Endpoint Manager) for deployment to work. For .pkg-based deployments, Intune uses the macOS MDM framework to push the installer. No additional agent is required for .pkg installs, but if you plan to deploy via the newer .dmg method, the Intune Management Agent for macOS is required on the client (more on this in the DMG section).

• Company Portal Icon: Intune requires a logo/icon for macOS LOB apps. If you don't upload an icon when adding the app, it won't appear in the Company Portal for users. Prepare a PNG or JPEG icon file to represent your app for a better user experience.

With these prerequisites in mind, we can proceed to actually packaging the application.

Step-by-Step: Packaging a macOS App for Intune Deployment

In this section, we'll walk through creating a signed .pkg installer from your macOS app. Follow these steps:

1. Obtain the Mac Application: Start with the app you want to deploy. This could be:

   • A downloadable app that comes in a .dmg or .zip. Mount the DMG or unzip the archive and copy the .app to your /Applications folder on a Mac. Placing it in /Applications ensures the app is in the expected location when we package it.
   • An existing .pkg installer from the software vendor. If the vendor already provides a signed .pkg (e.g., Chrome, Zoom, etc.), you can usually use it directly – skip to the Intune upload section. (For instance, Google provides a Chrome Enterprise installer pkg which can be used as-is.)
   • An in-house or custom-built app (as an .app bundle). Ensure it's a properly built macOS app bundle and located in /Applications for packaging.

2. Verify App Metadata: It's good practice to check that the app's Info.plist contains a CFBundleIdentifier (a unique identifier, typically in reverse-domain format) and a CFBundleShortVersionString/CFBundleVersion (version numbers). Intune will use these for detection. You can open the app's Contents/Info.plist or use Terminal commands:

   defaults read /Applications/YourApp.app/Contents/Info CFBundleIdentifier
   defaults read /Applications/YourApp.app/Contents/Info CFBundleShortVersionString

   Ensure these return valid values. If not, you may need to add them. (For custom apps with missing fields, you can use defaults write ... to insert a bundle ID or version before packaging.)

3. Prepare Any Install Scripts (Optional): If your deployment needs to do extra setup (copying files, running scripts, setting permissions, etc.), you can include pre-install or post-install shell scripts in your package. For example, you might want a post-install script to clean up old versions or adjust ownership/permissions. Prepare these scripts now if needed. Commonly, you'll create a Scripts directory with preinstall and/or postinstall scripts. Ensure they are executable (chmod +x) and have no file extension.

4. Use a Packaging Tool to Create the .pkg: Now create the installer package. You have a few options:

   • Apple's pkgbuild (CLI): This is a command-line tool provided by Apple for creating packages. It's ideal for simple packaging tasks. For a basic app bundle installation to /Applications, one straightforward command is:

     sudo pkgbuild --install-location /Applications \
                  --component "/Applications/YourApp.app" \
                  --scripts /path/to/Scripts \
                  "YourApp.pkg"

     This tells pkgbuild to take the app bundle and package it to install into /Applications (including any scripts from the Scripts folder). If you don't need scripts, you can omit the --scripts flag. Also include --identifier and --version flags if you want to set a specific package identifier and version (otherwise it uses the app's Info.plist values).

     Once run, this will output a YourApp.pkg file. Make sure to review the Terminal output for any warnings.

   • Third-Party Packaging Tools (GUI): If you prefer a graphical interface or need more complex packaging (multiple components, pre/post scripts without manual CLI), consider using a tool like Packages by WhiteBox. Packages is a free GUI that can build installation packages and is widely used by Mac admins. It allows you to add files, set installation locations, and include scripts (called "post-install actions") easily. You would create a new project, add the app bundle under /Applications in the payload, attach any scripts, and build the package. Ensure you mark the project as "Distribution" or component package as needed and provide version and identifier information in the project settings.

   • Jamf Composer or Others: Admins in Mac environments might also use Jamf Composer, Munki's pkgbuild, or other packaging utilities. The goal in all cases is the same: produce a signed, flat .pkg installer that puts the app in /Applications.

5. (If needed) Create a Distribution Package: If your app package is simple, the single .pkg from pkgbuild is often sufficient. In some cases, you might wrap that component package into a distribution (.pkg) especially if you need to bundle multiple packages. For example, using Apple's productbuild to create a distribution can let you set a product version and requirements. This is more advanced and typically not required unless you have multiple components. Most single-app deployments don't need this step, but be aware that Intune supports either a component package or a package with multiple components. The key is that the final result is a .pkg that meets the requirements.

6. Sign the Package: Code-sign the .pkg with your Developer ID Installer certificate. This step is critical. If you used pkgbuild with the --sign "Developer ID Installer: <Your Name>" option (or configured signing in your packaging tool), your package may already be signed. If not, you can sign it after the fact with Terminal:

   productsign --sign "Developer ID Installer: Your Company Name (TeamID)" \
               "YourApp.pkg" "YourApp-signed.pkg"

   Replace the certificate name with the exact name of your Developer ID Installer certificate. The result will be YourApp-signed.pkg. This is the file you will upload to Intune. Signing ensures macOS will trust the installer on the end-user devices and is mandated by Intune.

7. Verify the Package: It's a good idea to test the package locally before uploading:

   • Run sudo installer -pkg YourApp-signed.pkg -target / on a Mac to simulate the installation. Check that it installs the app to /Applications and that the app launches correctly.
   • You can also inspect the package metadata by extracting it (xar -xf YourApp-signed.pkg) to ensure the PackageInfo or distribution contains the expected Bundle ID, versions, and install-location (look for /Applications in the pkg metadata).
   • If anything is amiss (for example, the install-location is wrong or version missing), go back and fix the package (e.g., use pkgbuild's flags to set version/identifier or adjust your project in Packages).

Once you have a signed .pkg file that installs your app correctly to the Applications folder, you're ready to deploy it via Intune.

Uploading and Deploying the macOS App in Intune

With the .pkg prepared, the next part is adding it to Intune and deploying to your target Macs. Intune's admin center provides a straightforward wizard for this:

1. Add a new macOS LOB app: In the Intune (Microsoft Endpoint Manager) admin center, navigate to Apps > macOS (or Apps > All apps and click Add). Select "Line-of-business app" as the app type for macOS. (This is the option for custom macOS apps via .pkg.)

2. Upload the .pkg file: When prompted to select an app package file, browse and upload your signed .pkg file. Intune will parse the package. If the pkg is properly structured, the portal should display the app name, bundle identifier, version, and size after upload.

3. App Information: Enter the application details:

   • Name – The app name as you want it to appear in the Company Portal.
   • Description – Details or purpose of the app (optional but useful for users).
   • Publisher – Software vendor or your company (for in-house apps).
   • Minimum Operating System – The lowest macOS version on which this app should install. (Intune will prevent installation on older OS versions than specified). Note that Intune requires at least macOS 10.14 for .pkg LOB apps.
   • Ignore app version – Decide whether Intune should consider the app version when deploying. If set to Yes, Intune will install the app only if it's not already present on the device (it will ignore version differences). If set to No, Intune will install the app if it's not present or if the version on the device is different from the one you're deploying. For self-updating apps like Chrome or Zoom, Ignore version = Yes is often recommended so Intune doesn't reinstall updates that the app auto-installs. For apps you want to strictly manage versions for, use No.
   • Install as managed – Choose Yes to install the app as a managed app (requires macOS 11+). Managed apps can be removed by Intune (using an uninstall assignment) and will be removed if the device is unenrolled. To qualify, the package must contain a single app that installs to /Applications and no nested installers. If your package meets the criteria, setting this to Yes allows Intune to later uninstall the app if needed. (If set to No, Intune cannot automate the app's removal.)
   • Logo – Upload the app's icon image (PNG/JPG). Remember, without a logo the app will not show up in Company Portal for users, so this is required for visibility.

4. Included Apps (Detection Rules): Intune will list the "Included apps" it detected in the package (usually just the main .app). This includes the app's Bundle ID and version that Intune will use to detect installation status. Verify that this list makes sense (e.g., it should list the app you intended to install). If your package installs multiple apps or components, ensure they are all listed. Important: The included apps list should only contain actual apps that the package installs in /Applications. If it lists something incorrect (or if the app isn't actually installed), Intune might never mark the install as success. You can remove any extraneous entries here. The first app in the list is treated as the primary app for reporting.

5. Assignments: Choose how to deploy the app:

   • Required – to push the app to devices/users (selected groups will get it installed automatically).
   • Available for enrollment – to make the app available in Company Portal for users to install on demand.
   • Uninstall – (if managed install) to remove the app from devices in selected groups.

   Add the Azure AD groups (of users or devices) under the appropriate assignment category. For example, to force-install on all company Macs, you might assign to an "All Mac Devices" group as Required.

6. Review and Create: Review your settings and finish the wizard to create the app entry in Intune.

Once created, Intune will begin deploying the app to targeted Macs at the next device check-in. You can monitor deployment status in Intune:

• Monitoring Deployment: Go to the app's Overview in Intune Apps, and check Device install status and User install status for progress or errors. It may show statuses like Waiting for install, Installed, Failed, etc., per device.

• End User Experience: If the app was assigned as Required, it will silently install in the background on the device (no user interaction). If it was made Available, users can open the Company Portal, find the app (with the icon and description you provided), and click Install to trigger deployment.

• Uninstall (if applicable): If you ever need to remove a managed app, you can assign it to an Uninstall group. Intune will then issue an uninstall command to those devices and remove the app (for macOS 11+ with managed apps).

Next, we'll discuss some best practices and examples to ensure this deployment process goes smoothly.

Best Practices for Smooth macOS App Deployment via Intune

Packaging and deploying Mac apps in an enterprise environment can have pitfalls. Follow these best practices to minimize issues:

• Use Vendor-Provided PKGs When Available: If a software vendor offers a macOS PKG installer (especially an "enterprise" version), use it. These are often already signed and configured properly for mass deployment. Example: Google Chrome provides a PKG installer for Mac, which meets Intune's requirements out-of-the-box. Using these saves you time and ensures compatibility.

• Ensure Proper Signing: Always sign your custom packages with a Developer ID Installer certificate. Untrusted or unsigned packages might fail to install on Macs due to Gatekeeper, and Intune will not accept an unsigned package. If your organization doesn't have an Apple Developer ID, acquire one and distribute the certificate to whoever packages apps.

• Include Accurate App Metadata: The package's internal metadata should include the app's bundle identifier and version. If you build the package with tools like pkgbuild, provide the --identifier and --version flags (matching the app's version) to embed this info. Missing version info can lead to Intune not recognizing the installation. It's also wise to keep the package version aligned with the app version for clarity.

• Target /Applications Directory: Configure your package to install the app in /Applications. Intune currently expects Mac apps to reside in the Applications folder, and will only successfully track deployments for apps installed there. Installing to non-standard locations (e.g., ~/Applications or /Library for apps) can cause Intune to report the app as not installed. The install-location can be set in your packaging tool (for pkgbuild, we used --install-location /Applications).

• Do Not Nest Apps or DMGs in the Package: Your .pkg should directly install the app's files, not just drop an .app or .dmg onto the system. For instance, do not create a pkg that simply copies a .app file into /Applications – it should install it (expanding it as files). Similarly, don't include disk images inside the package. Intune will ignore packages that contain another container.

• Test Installation Manually: Before deploying via Intune, test the installer on a macOS test machine. This will catch issues like missing dependencies, incorrect file paths, or permission problems. Make sure the app launches fine after installation.

• Use Post-Install Scripts for Extras: If your deployment needs to configure settings (like license files, configuration plists, or running activation scripts), package those steps into a post-install script within the .pkg. This way, everything is done in one installation transaction. For example, you might include a script to copy config files into /Library/Application Support or to set ownership of the app files for the logged-in user. Ensure any scripts exit with code 0 on success and are tested.

• Leverage "Install as Managed" when possible: If you meet the criteria (single app, no nested packages, installing to /Applications), consider marking the app as managed in Intune. This will allow you to uninstall or auto-remove the app if a device is unenrolled, giving you more control.

• Provide a Company Portal Icon: Always upload an app icon in Intune. This not only makes the portal look professional, but as noted, Intune requires it for the app to be listed for end-users.

• Plan Version Updates: For apps that update frequently, decide on a strategy:

  • If the app auto-updates (e.g., Chrome, web browsers, some VPN clients), you might set Ignore app version = Yes so Intune doesn't attempt to reinstall an update that the app already applied. You would then only push a new Intune package when a major update is needed or to install on fresh devices.
  • If you want Intune to manage updates, leave Ignore version = No, and periodically update the Intune app package to the latest version. Intune will then try to upgrade devices that have an older version.

• Use Device (or User) Groups Wisely: If you assign apps to devices, the install will occur in the system context (which is typical for required installs). User assignments will trigger when that user is logged in on a Mac. For most LOB apps on macOS, device-based required assignments are common. Make sure your Azure AD groups are set up so you don't accidentally push to unintended machines.

• Stagger Deployments for Testing: Consider deploying to a test group or a pilot batch of Macs first. Monitor the results, then roll out to all users. This can catch any unexpected issues without impacting everyone at once.

Real-World Examples and Scenarios

To illustrate these principles, here are a few real-world scenarios:

• Deploying Google Chrome (Vendor PKG): Google provides a Chrome enterprise installer (.pkg) for Mac. In this case, packaging is straightforward – download the PKG from Google (which is already signed and properly configured), upload it to Intune, configure the app info, and assign it. Many IT admins have successfully deployed Chrome via Intune using this method. Best practice is to set Ignore app version to Yes, since Chrome auto-updates. The Intune deployment simply ensures Chrome is present; Chrome's own update mechanism handles keeping it up to date.

• Deploying an In-House App (Custom Packaging): Imagine your company developed a macOS app internally, and you have the .app bundle. You would follow the packaging steps: place it in /Applications on a Mac, use pkgbuild (or a tool like Packages) to create a .pkg installer that puts the app into /Applications, include any config files it needs, and sign the package with your Developer ID. Upload this to Intune as a LOB app. Because this is an in-house app, you'll be responsible for incrementing the version and re-uploading new .pkg versions to Intune when you release updates. Always test on a Mac (or a few) directly before Intune deployment to verify installation behavior.

• Packaging an App with Additional Scripts: Suppose you need to deploy an app that also requires a license file to be placed in /Library/Application Support and a post-install script to set permissions for that file. You can achieve this by creating a package that includes both the app (to /Applications) and the license file (to the appropriate path), along with a post-install script. For example, you might have a Content folder for pkgbuild that contains:

  • Applications/YourApp.app (the app bundle)
  • Library/Application Support/YourApp/license.dat (the license file) And a Scripts folder with a postinstall that does something like chown root:admin /Library/Application\ Support/YourApp/license.dat if needed. Using the --root Content --scripts Scripts options in pkgbuild would then create a single package containing both. This one package can be deployed via Intune, ensuring the app and its necessary files are delivered together.

• Handling DMG-Based Apps via Intune Management Agent: Some software vendors only distribute macOS apps in a .dmg (disk image) where the user would traditionally drag-and-drop the .app to Applications. If you prefer not to repackage these into .pkg yourself, Intune now offers a solution: macOS app (DMG) deployment. When adding an app in Intune, you can choose "macOS app (DMG)" instead of LOB, and upload a DMG that contains an .app. Intune leverages the Intune Management Agent on the Mac to mount the DMG and copy the app to /Applications. For example, if deploying Slack (which might come as a DMG with Slack.app inside), you could use this method. Keep in mind:

  • The DMG must contain one or more .app files at the root (no pkg or other installers inside).
  • The device must have the Intune management agent installed (you can deploy this from Intune; it's mainly used for scripts and now DMG apps).
  • On macOS 13+, Intune will auto-request Full Disk Access for the agent to move the app; on older versions you might need to instruct users or deploy a privacy preferences profile.
  • Intune will detect the app similar to .pkg (you'll see included app bundle IDs for detection).

  While the DMG deployment method saves repackaging effort, note that Microsoft's documentation still recommends .pkg for most scenarios, and not all apps may be supported. Also, the DMG method is relatively new, so ensure thorough testing if you use it. If you're comfortable repackaging, you might still choose to create a pkg for consistency.

• Office 365 and Microsoft Apps: It's worth mentioning that for Microsoft 365 Apps (Office suite), Intune provides a dedicated deployment workflow (you don't manually package those). Similarly, apps like Microsoft Edge or Defender have their own integration in Intune. Use those when applicable instead of packaging them yourself.

Each scenario might have slight nuances, but the foundational practices remain: get a good .pkg, sign it, and make sure Intune's requirements are met.

Common Issues and Troubleshooting Tips

Even with careful planning, you might encounter issues. Here are some common problems and how to troubleshoot them:

• App never installs (no error in Intune): If you assign a required app and it doesn't install, and Intune shows no error (or just "Waiting" status), check the package's integrity:

  • Missing metadata? A known issue is if the .pkg's internal info is incomplete – for example, no CFBundleVersion or an incorrect install path. Intune silently ignores such a package. Use the xar command (as shown earlier) to inspect PackageInfo. Ensure it has a <pkg-info> entry with a version and an install-location="/Applications" (or a distribution with a <choice> specifying /Applications). If not, rebuild your package with the correct parameters.
  • Not signed or wrong certificate: Intune might allow an upload of an unsigned pkg, but the Mac will refuse to install it. Always confirm the package is signed with Developer ID. You can run pkgutil --check-signature YourApp.pkg on a Mac to verify the signature.
  • Intune Management Profile issues: On the Mac, ensure the Intune MDM profile is present and active (System Settings > Profiles). If the MDM profile was removed or corrupted, app installs will fail. You might need to re-enroll the device.

• Installation failed with an error code: If Intune shows a specific error (e.g., Installation failed with an error message or code), you'll need to dig into logs:

  • On the Mac, check Intune logs at /Library/Logs/Microsoft/Intune/. The files IntuneMDMDaemon.log and IntuneMDMAgent.log can provide insight. Look for entries around the time of the install attempt. These logs might show, for example, a Gatekeeper error (signature issue) or a failure to mount a DMG, etc.
  • The macOS system installer log (in Console app or /var/log/install.log) might also show why a pkg failed (e.g., script error, missing requirement).
  • Common errors include certificate trust issues (if not signed properly) or path not found (if the pkg tries to put files in a directory that doesn't exist or isn't allowed).

• App installs but Intune reports "Not Installed": You see the app on the device, but Intune doesn't acknowledge it:

  • This often relates to detection. Check the Included apps in Intune for that app entry. Does it list the correct bundle ID and version of the app that got installed? If the app that installed has a different version (maybe it auto-updated immediately or you packaged the wrong version metadata), Intune's expected version might not match what's actually there, leading it to think install didn't happen. Updating the app or the detection info (by re-uploading a corrected package) can fix this.
  • If your package installed multiple apps and one is missing, Intune might mark overall install as failed. For example, if you packaged two apps together and one didn't install correctly, Intune may report failure for both. The solution is to ensure all included components install or split the packages.
  • Also verify that the app is in /Applications and not in a subfolder or user directory that Intune isn't monitoring. Intune expects it in the standard location.

• App appears in Company Portal but won't download/install for user: This could be due to missing icon (which can prevent listing – but if it appears, icon is there). More likely it could be a network or service issue. Have the user try clicking "Retry" or ensure the device is online and checking in. You can also try a manual sync: on the Mac, open Company Portal > Settings > Sync, or in Intune portal use the "Sync" device action.

• Devices not checking in or receiving apps: Sometimes the issue isn't the app or package at all, but Intune communication. If a device is offline or has an MDM connectivity issue, it won't get the app until those are resolved. In Intune portal, check if the device's last check-in time is recent. You can instruct the user to force an MDM sync (in Company Portal) or even use Terminal with sudo profiles -e -F to trigger an immediate MDM check-in. If many devices are affected, verify if Apple Push Notification service and Intune are functioning normally.

• Troubleshooting with Logs and Diagnostic Reports: For deeper debugging, you can collect the Intune diagnostic logs from the Mac. Microsoft's Company Portal app has an option to gather logs. Additionally, the troubleshooting blade in Intune might show per-device errors. If needed, enable higher log levels for Intune components or consult Microsoft support with logs for unresolved issues.

• Package deploys but app is unusable: If the app installs but doesn't run on the end-user device (e.g., crashes or asks for permissions):

  • This might not be Intune's fault but consider if the app needs additional configuration. For instance, some apps require Rosetta 2 on Apple Silicon Macs. If deploying to M1/M2 Macs, ensure Rosetta is installed (you could push a script via Intune to install Rosetta beforehand if needed).
  • If the app needs a config profile (for example, a kernel extension approval or a Privacy/TCC permission), you might have to deploy an Intune configuration profile alongside the app.
  • Test with a local manual install vs. Intune install to see if the behavior differs. If they behave the same, the issue lies with the app itself or missing configurations (not the packaging or Intune).

In summary, when issues arise, double-check the packaging (signing, format, metadata) and use logging on the Mac to diagnose. Most problems boil down to package format errors (which are solved by following the best practices above) or environmental issues (device not ready, etc.).

Conclusion

Packaging macOS apps for Intune deployment may initially seem daunting, but with the right approach it becomes a repeatable process. By using Apple's packaging tools or third-party solutions to create a proper .pkg installer (and avoiding the now-obsolete wrapping tool), you ensure your Mac applications are in a format Intune can deploy reliably. Always remember to sign your packages and adhere to Intune's requirements – especially installing to /Applications and including correct version info – for the smoothest results.

Through the step-by-step guide above, we covered how to package an app (with an example command using pkgbuild), how to upload and configure it in Intune, and what settings can optimize deployment. We also discussed real-world examples like deploying Chrome (leveraging vendor PKGs) and handling custom apps, as well as Intune's newer capabilities like DMG deployment for those cases where repackaging isn't feasible.

By following these best practices – testing your packages, using proper signing, and monitoring deployments – you'll significantly reduce installation issues. In case problems do occur, use the troubleshooting tips and logs to pinpoint the cause, whether it's a packaging oversight or an Intune communication hiccup. Over time, you'll build a library of Intune-ready macOS app packages, making future deployments as simple as a few clicks to assign apps to new devices.

Managing Mac apps at scale is becoming easier with tools like Intune evolving rapidly. Staying up-to-date with Intune's latest features (for example, improvements to macOS app management) will further streamline your workflows. With the knowledge from this guide, IT administrators can confidently deliver macOS applications to their users via Intune, providing a seamless and secure app experience in the modern workplace.

References:

1. Microsoft Docs – Add macOS line-of-business apps to Microsoft Intune
2. Microsoft Docs – Troubleshoot macOS LOB apps not deploying
3. HowToManageDevices Blog – Deploy macOS LOB Apps using Intune
4. Reddit (r/Intune) – Discussion on Intune macOS .pkg deployment (post-App Wrapping Tool)
5. CloudInfra Blog – Deploy PKG Apps on macOS using Intune (Intune settings and logs)
6. The Ether Blog – Packaging a macOS Application for Intune MDM (advanced pkgbuild example)
7. Microsoft Docs – Add a macOS DMG app to Intune (DMG deployment details)