Understanding App Detection Rules for macOS in Intune

Introduction

Managing Mac applications with Microsoft Intune requires careful configuration of app detection rules. These rules tell Intune how to check if an app is already installed on a macOS device and whether the correct version is present. By understanding and configuring detection rules properly, you ensure Intune only installs apps when needed and accurately reports installation status. In this guide, we'll explore what app detection rules are, how Intune detects macOS apps by default, ways to customize these rules for different app types, command-line methods to find the info you need, troubleshooting tips, and best practices for reliable Intune macOS app deployments.

What Are App Detection Rules (and Why They Matter)?

In Intune, app detection rules are the criteria Intune uses to determine if an application is installed on a managed device. For macOS line-of-business (LOB) apps, this typically means checking for a specific app bundle identifier (a unique ID for the app) and often a version number. Intune uses the app's CFBundleIdentifier (the unique bundle ID defined in the app's Info.plist) to identify applications uniquely on macOS. These rules matter because they prevent Intune from repeatedly installing an app that's already present and ensure Intune can verify that the deployed app is the correct version.

Without proper detection rules, Intune might falsely assume an app isn't installed (triggering re-installation) or think an installation succeeded when it actually failed. In other words, detection rules are crucial for Intune to accurately track app deployment compliance and to decide whether an app needs installation or upgrade. A correctly set rule saves bandwidth and avoids unnecessary reinstall attempts, while an incorrect rule can lead to Intune installing the app over and over or not installing it when it should.

How Intune Detects Installed macOS Applications

Microsoft Intune uses a client agent on macOS (the Intune management agent) to detect installed applications. This agent checks the system for the presence of the app using the criteria you define in the detection rules. On macOS, detection is usually centered on the application bundle in the /Applications directory (or another install path). Intune doesn't just look for an app name; it checks the app's internal bundle ID and version information to confirm the app's identity.

When you add a macOS app (whether a .pkg installer or a .dmg containing an app) to Intune, you provide or confirm its bundle identifier (e.g. com.company.appname) and typically the version. Intune uses these values to query the device. If an application with that bundle ID (and meeting the version criteria) is found on the Mac, Intune considers the app installed. If not, or if the version is lower than expected, Intune will attempt to install or update the app.

For example, if you deploy an app with bundle ID com.example.MyApp and version 1.0.0 as a required install, the Intune agent will check the Mac for any app whose CFBundleIdentifier is com.example.MyApp. If it finds one, and you've required version 1.0.0, it will also compare the app's version. This detection mechanism relies on the unique bundle ID (which Intune uses as a unique key) and the app's version property to decide the next action. This approach is much more reliable than looking for a file name, since the bundle ID is embedded in the app itself and remains constant regardless of where the app is installed or if it's been renamed.

Default Detection Methods: Bundle ID and Version

By default, Intune's detection rules for macOS LOB apps use the app's bundle ID and version (from the app's Info.plist). When you upload a Mac app to Intune, the system often tries to automatically read these values:

• App bundle ID – This is the CFBundleIdentifier of the app. It's a unique string (usually in reverse domain format, like com.company.app) that identifies the app. Intune populates or uses this to know exactly which app to look for.
• App version – This corresponds to the app's version number. Intune uses the CFBundleShortVersionString (sometimes called the build or version string) from the app's Info.plist as the version in detection rules. For example, an app might have a version "1.2.3" as its CFBundleShortVersionString.

Intune's default behavior is to consider the app installed only if both the bundle ID matches and the version matches what you specified. However, you have control over this via the "Ignore app version" setting:

• Ignore app version: No – If you set this to No, Intune will check both the app's bundle ID and its version number on the Mac. The Intune agent looks for the exact bundle ID and also compares the installed app's version to the one you deployed. If either the ID isn't found or the version doesn't match what Intune expects, Intune will treat the app as not installed (or not the right version) and will attempt to install or reinstall the application. This is useful when you want to enforce a specific version of an app. For instance, if you deployed version 1.0.0 and the user somehow has 1.0.1, Intune will try to reinstall 1.0.0 (or mark it as needing remediation).
• Ignore app version: Yes – If you set this to Yes, Intune will ignore the version difference and only check for the presence of the bundle ID on the device. As long as an app with that bundle identifier exists, Intune considers the app installed (regardless of its version). This is typically used for apps that auto-update themselves. A great example is Google Chrome, which regularly updates on its own; with Ignore app version = Yes, Intune will install Chrome if it's missing, but once Chrome is there, Intune won't reinstall it just because the version changed due to an auto-update. This prevents Intune from fighting with the app's own update mechanism.

When you add a macOS app in Intune, you'll also encounter the Included apps section. Intune may list one or more detected apps in the installer under Included apps. These are the bundle IDs (and versions) Intune found in the package you uploaded, which it will use to detect installation status. In most cases for a single-app installer, there will be just one entry here – the main application. Intune requires that all apps listed in Included apps are installed on the device for it to mark the deployment as successful. If even one of the listed bundle IDs is not found after installation, Intune will not consider the app installation complete (the status will remain as not installed or failed). The first app in the Included apps list is treated as the primary app for reporting purposes.

How Intune obtains these values by default: For a .pkg (PKG) installer, Intune will automatically scan the package file for any application bundles inside it. It looks for any .app bundles and reads their CFBundleIdentifier and CFBundleShortVersionString during the upload process. If the PKG contains exactly one app, Intune will show that one in the detection rules. If the PKG contains multiple apps (for example, an app and a helper tool, each as a separate .app bundle), Intune will list all those bundle IDs and versions. For a .dmg (DMG), if you upload it as a macOS app (DMG type) in Intune, Intune will inspect the DMG for applications. Typically, DMGs contain a single .app file; Intune will identify that app and may pre-fill the bundle ID and version in the detection rules form (or you will enter them manually based on the app's Info). The important thing is that whether it's auto-populated or entered by you, the detection logic defaults to using the bundle ID and version.

Customizing Detection Rules for Different Types of macOS Apps

Different types of app installers may require slight adjustments to detection rules to ensure Intune can properly detect the app. The two common LOB app formats for macOS in Intune are PKG installers and DMG (drag-and-drop) installers, and each can be handled a bit differently. Additionally, you might have cases with multiple app bundles or non-standard install locations that need special consideration.

1. PKG-based apps: When deploying a .pkg file through Intune, Intune will often auto-detect the apps inside as mentioned. If your PKG installer contains multiple .app bundles, you should customize the Included apps list in Intune to ensure it only includes the relevant apps. Intune allows you to remove entries from the included apps list (via a trash can icon in the UI). As a best practice, remove any bundle IDs that are not actual user-facing applications or that aren't installed in the /Applications directory. For example, some PKG installers might install a main app in /Applications and also install a helper tool or plugin elsewhere. Intune might list both the main app's bundle ID and the helper's bundle ID. You would want to remove the helper's bundle ID from the detection list if that helper isn't something in /Applications, because Intune only verifies apps in the Applications folder by default. If you leave an entry for a component that doesn't get placed in /Applications, Intune will never find it and thus never mark the install as complete. By cleaning up the included apps list to only the main app, you make detection more reliable.

Also, if your PKG installer has multiple apps but they are truly part of one product (for instance, a suite with two .app bundles that are both required), you can include both in the detection list. Intune will then check that both apps are installed. Keep in mind that Intune can only report on one app in the portal (the first in the list is the one shown in reports), but it will still require the others to be present to consider the install successful. If possible, it's often easier to repackage such software so that there's just one main app bundle to detect, simplifying the rule.

2. DMG-based apps: A DMG is essentially a disk image that usually contains a single .app to be dragged into Applications. Intune's macOS (DMG) app deployment expects the DMG to have one (or multiple dependent) app bundles. When you add a DMG in Intune, you'll need to provide the App bundle ID and App version manually (Intune might read them automatically in some cases, but you should verify them). To get these, you might mount the DMG on a Mac and inspect the app's Info.plist. Often, the simplest method is using the Terminal defaults read command (discussed in the next section) to read the CFBundleIdentifier and CFBundleShortVersionString from the app on the DMG. Alternatively, you can open the Info.plist file in a text editor or use a tool like Pacifist (which allows exploring package contents) to find those values. After uploading the DMG, Intune will list the app under included apps (just like PKG). Ensure that the DMG contains only the apps you intend to deploy. It's recommended to avoid bundling multiple independent apps in one DMG; Microsoft's guidance is that a single DMG should contain a single application (or multiple apps that are part of one solution). If you were to have two unrelated .app files in one DMG and deploy them together, one failing could cause Intune to continually retry or mark the whole deployment as failed.

3. Custom install locations or non-app components: Intune's macOS detection logic is primarily designed around finding application bundles in the standard install location. If your app installs to a non-standard path (for example, a CLI tool into /usr/local/bin with no .app bundle), Intune's default detection might struggle because there's no bundle ID in /Applications to check. In such cases, consider repackaging the software to include a dummy .app bundle for detection, or use a PKG receipt as a marker. (Intune doesn't natively let you specify a custom file path or script for detection on macOS like it does for Win32 apps on Windows, so you have to work within the bundle ID paradigm.) One approach is to create a small dummy app bundle with a unique identifier and have your PKG drop that dummy app (or simply a stub .app) in /Applications solely for detection purposes – but this is an advanced workaround. Ideally, any app you deploy via Intune should either be a standard macOS application bundle or come with a package receipt that includes a bundle ID Intune can use.

In summary, tailor the detection rules based on how the app is packaged:

• For PKG installers: review the detected bundle IDs, remove any that don't apply, and make sure the remaining one(s) correspond to actual apps installed in /Applications. Intune will use those for detection.
• For DMG installers: provide the correct bundle ID and version from the app inside the DMG. Only include multiple apps if they're meant to be installed together. Otherwise, use separate Intune app entries for each to keep things simple.
• If an app auto-updates or you don't care about minor version differences, consider setting Ignore app version = Yes to avoid constant reinstallation attempts, as long as you're okay not enforcing the exact version.
• If you need to deploy something that isn't a typical .app, ensure there's some identifiable bundle or receipt. You might need to get creative, since Intune's UI for macOS doesn't have a direct custom script option for detection.

Using Terminal Commands to Find Detection Info

When configuring detection rules, you'll often need to retrieve the CFBundleIdentifier (bundle ID) and CFBundleShortVersionString (app version) from the application you want to deploy. Here are some handy command-line methods to get this information on a Mac:

• Using defaults read on an installed app: If you have the app already installed on a Mac (or after you install it on a test machine), you can use the defaults command to read the app's Info.plist. For example, if you have Google Chrome installed in the Applications folder, you could run:

  defaults read "/Applications/Google Chrome.app/Contents/Info" CFBundleIdentifier
  defaults read "/Applications/Google Chrome.app/Contents/Info" CFBundleShortVersionString

  The first command would output Chrome's bundle ID (e.g., com.google.Chrome), and the second outputs the version (e.g., 100.0.4896.75). You should run these for whatever app you are deploying (replace the path with your app's path). If the app name has spaces, remember to either escape them with a backslash (\ ) or put the path in quotes as shown above.

• Using defaults read on a mounted DMG: If you haven't installed the app yet but have the installer DMG, you can mount the DMG and read the Info.plist directly from the app on the DMG. Suppose the DMG mounts to /Volumes/ExampleApp and contains ExampleApp.app – you could run:

  defaults read "/Volumes/ExampleApp/ExampleApp.app/Contents/Info" CFBundleIdentifier
  defaults read "/Volumes/ExampleApp/ExampleApp.app/Contents/Info" CFBundleShortVersionString

  This gives you the bundle ID and version without needing to fully install the app. This method was demonstrated with Chrome's DMG as well (reading com.google.Chrome and the version from the mounted image).

• Opening the Info.plist file: If you prefer, you can open the app's Contents/Info.plist file in a text editor or use Xcode's Property List editor. Look for keys named CFBundleIdentifier and CFBundleShortVersionString (and/or CFBundleVersion). Intune primarily uses the bundle ID and short version string for detection. Ensure you copy the values exactly, as they are case-sensitive. (com.MyCompany.App is different from com.mycompany.app due to case, for example.)

• Using pkgutil for PKG receipts: If your app was installed via a PKG, macOS will have a package receipt. Sometimes you might know the package identifier (which often looks similar to a bundle ID). You can list all installed package IDs with pkgutil --pkgs. For instance:

  pkgutil --pkgs | grep -i citrix

  This might show something like com.citrix.receiver.pkg. You can then get details including version with:

  pkgutil --pkg-info com.citrix.receiver.pkg

  This will output info about the installed package, including a version. However, note that Intune on macOS doesn't use the package receipt alone for detection; it still relies on the app bundle info. The pkgutil approach is more useful for troubleshooting (e.g., to see if a previous install exists on the system).

• Extracting a PKG or using Pacifist: If you want to inspect a PKG file without installing it, you can use the pkgutil --expand command to extract its contents to a folder, or use a third-party tool like Pacifist to look inside the PKG. Inside, if there are .app files, you can find their Info.plist and get the CFBundleIdentifier and CFBundleShortVersionString. This is the same info Intune will need for detection. Microsoft's documentation even suggests extracting the PKG and checking the Info.plist if you run into detection issues.

• Verifying data in Intune: Once you add the app in Intune, you can double-check what you entered (or what Intune auto-filled) for the bundle ID and version. If you realize you made a typo, you can edit the detection rules in the Intune app properties. There is also an option in Intune admin center to view the app's detected bundle ID after creation, but it's safer to verify beforehand via the above methods.

Using these command-line methods ensures you have the exact identifiers. Always copy-paste or carefully type these values into Intune. A common mistake is a subtle typo in the bundle ID or version that causes Intune's detection to fail. For example, missing a digit in the version or mis-capitalizing a letter in the bundle ID will result in Intune not finding the app. By retrieving the info directly from the app or installer, you eliminate guesswork.

Troubleshooting Common Detection Issues

Even with the correct process, you might encounter issues where Intune doesn't detect the app as expected. Here are some common detection problems and how to resolve them:

1. Intune reports the app as "Not Detected" even though it's installed: This usually means the detection rule didn't find a match on the device. The most likely cause is an incorrect bundle ID or version in the rule. Double-check that the CFBundleIdentifier in Intune matches the app exactly (including capitalization) and that the App version in Intune matches the app's CFBundleShortVersionString. A case sensitivity mismatch or an extra space can throw off detection. If you discover a mistake, update the detection rule in Intune to the correct value and sync the device again. Also, ensure the app is actually installed in the expected location (generally /Applications). Intune by default looks in the standard locations for apps. If a user accidentally moved the app or installed it in a user-specific folder, Intune might not find it.

2. Intune keeps trying to reinstall an app (or reports install pending repeatedly): This can happen if Ignore app version is set to No and the version on the device doesn't exactly match what Intune expects. For example, suppose you deployed version 5.0 of an app with ignore version = No. If the end-user updated the app to 5.1 on their own, Intune will see the bundle ID but a different version, so it will attempt to reinstall 5.0 thinking the app is outdated or not the intended version. It might even succeed in reinstalling, but then the app (or user) updates again, causing a loop. The solution is to either disable strict version checking (set ignore version = Yes) for apps that auto-update, or keep your Intune deployment updated to the latest version so Intune isn't detecting a mismatch. On the other hand, if Intune is reinstalling even though nothing changed, check if maybe the version format in Intune is slightly off (e.g., missing a minor version that the app reports). Adjusting the detection rule to match the app's actual version format can fix this. Remember that with ignore version = No, Intune expects an exact match; any difference triggers a reinstall attempt.

3. Installation succeeded but Intune still shows the app as not installed: You might observe the app is on the device and working, yet Intune marks the deployment as failed or not installed. In such cases, the installation likely happened, but the detection rule did not validate it. This can occur if the Included apps list wasn't configured correctly. For instance, maybe the PKG installer actually installed the app, but Intune was also looking for a secondary bundle ID that never got installed. As mentioned earlier, if all listed bundle IDs are not found, Intune will not report success. The fix is to adjust the included apps list: remove any bundle IDs that aren't applicable, and then redeploy or sync. Another scenario is if the app installed to a different path (not /Applications) – Intune may not detect it there. Ensure the app is in the expected folder. If not, you might need to modify the installer or instruct users to move it. (Note: Intune's macOS agent typically installs DMG apps into /Applications automatically when using Required assignment, so this is more of an issue if an installer had unusual behavior.)

4. Detection rule configured correctly, but Intune still errors out: If you're confident the bundle ID and version are right and the app is in place, it's time to dig into logs. On the Mac, check the Intune logs – particularly the IntuneMDMDaemon logs – for clues. The IntuneMDMDaemon.log on the client can show if there were errors evaluating the detection rule or if the app's Info was read. Microsoft support forums often suggest checking these logs when detection doesn't work as expected. Look for entries related to app detection or your app's name/bundle ID in those logs. You might find an error message indicating a value mismatch or a missing component. If you see something like "app not detected" with specifics, it can guide you to the root cause (for example, a different version string than you thought, or an unexpected bundle ID).

5. Previous installation interfering with detection: If you had the app installed on the device before enrolling in Intune or before deploying via Intune, it might cause confusion. Intune will still detect it if the bundle ID matches, which is fine – it will mark it as installed (unless version checking is on and it's different). However, if you at some point installed and removed the app, a leftover package receipt could exist. For PKG-based deployments, a residual receipt could make Intune think the app is installed (or cause the macOS installer to behave differently). One user scenario: you tested the PKG manually on a machine, uninstalled the app, and then let Intune deploy it. The old receipt might still be present, causing Intune to think the app is there when it's not fully. To fix weird cases like this, you can remove the package receipt using Terminal:

   sudo pkgutil --forget <package-id>

   (Replace <package-id> with the identifier of the app's PKG, which you can find with pkgutil --pkgs.) Forgetting the package registration removes the record of that install. Then Intune will treat the app as not present and attempt installation fresh. Generally, you won't hit this in normal operations, but it can happen during testing or if an app was installed by other means earlier.

6. Multiple apps in one DMG/PKG causing confusion: As noted, if you bundled multiple apps in one installer, troubleshooting can get tricky. If one of the apps fails to install (or is removed by the user), Intune may continually show the deployment as incomplete and try again. The Intune logs or macOS console might show which exact bundle ID wasn't detected. The remedy is to deploy such apps separately or ensure all pieces are always installed together. If Intune is, say, deploying App A and App B from one package and App B is manually removed by a user later, Intune might attempt a reinstall of the whole package to get App B back. Be aware of this in scenarios where you see repeated reinstalls – it could be one component missing.

7. General installation failures vs detection failures: Sometimes an app might fail to install at all (due to a bad installer, certificate issues, etc.), and that's not directly a detection rule problem. To distinguish this, check if the app ever appeared in the Applications folder. If the Intune deployment error says something like "install failed" and the app isn't on disk, troubleshoot the installer (maybe the PKG is not signed or not compatible). If the app is on disk but Intune says "not detected" or keeps retrying, then it's a detection issue. For installation issues, ensure the PKG is properly signed and the Mac has the Intune management agent installed (Intune takes care of that automatically for Required deployments). Always test the installer locally: does the PKG install manually without Intune? Does the app run? This can help isolate whether it's the package or Intune's detection causing the problem.

In any case of detection trouble, the key steps are: verify the rules (bundle ID & version), use Terminal or logs to see what's on the device, and adjust the detection logic accordingly. The Intune admin center might show an error code for detection issues (for example, error 0x87D1041C often indicates a detection failure in Intune for Win32 apps; macOS might show a generic message). Pair that with the client-side logs for a full picture.

Best Practices for Setting Up Reliable Detection Rules

To avoid the above issues and ensure smooth app deployments on macOS, consider these best practices when configuring Intune detection rules:

• Always get the exact bundle ID and version from the source: Do not guess or rely on internet info for an app's identifier. Use a Mac to extract the CFBundleIdentifier and CFBundleShortVersionString via Terminal or by inspecting the app's Info.plist. This guarantees you enter the correct values in Intune. Remember, these values are case-sensitive and space-sensitive.

• Use Ignore Version judiciously: Decide upfront if you want Intune to enforce a specific version or not. For apps that auto-update (have their own update mechanism) or when you don't mind if users run a higher version, set Ignore app version = Yes to have Intune just ensure the app is present. This prevents Intune from downgrading or reinstalling due to minor version changes. For apps where you need control of the version (security tools, certain enterprise apps), keep Ignore app version = No so Intune will attempt to update/reinstall if the installed version isn't what you deployed. Just remember to update the Intune app package when a new version is approved for use.

• One app per package (when possible): Try to package and deploy each application separately. Avoid combining multiple independent apps into one Intune LOB app entry. If you have a suite of apps, deploy them as separate apps in Intune unless they truly must be installed together. This isolation makes detection straightforward and ensures one app's failure doesn't impact others. Intune's design assumes a 1:1 relationship between a LOB app entry and the software it installs.

• Clean up the detection list: After uploading a PKG or DMG, review the Included apps Intune detected. Remove any entries that are not actual applications or that you don't need to track. Often, you'll only keep the main app's bundle ID. This reduces the chance of false negatives in detection (e.g., Intune looking for an auxiliary component that isn't critical).

• Ensure standard install locations: Configure your app packages to install applications in the /Applications folder. Intune expects apps there by default. Apps installed in unusual locations (~/Applications, /Applications/Utilities, etc.) might still be detected if the bundle ID is registered, but to be safe, /Applications at the root is recommended. Additionally, for Required installs, Intune's agent will put DMG-based apps into /Applications automatically.

• Test the installer and detection on a pilot device: Before wide deployment, use a test macOS device. Install the app using Intune (or manually if needed) and see if Intune reports it correctly. This pilot run can catch issues with signing, installation, or detection in a low-stakes environment. During testing, keep an eye on the Intune device install status and check the Intune logs on the Mac if something doesn't line up.

• Leverage Intune's "managed" app capability when applicable: If your PKG installer contains a single app and you meet the requirements (app in /Applications and macOS 11+), consider marking Install as managed in Intune (there's a checkbox when adding the app). When an app is installed as managed, Intune can potentially uninstall it later if you issue an uninstall assignment. This doesn't directly affect detection, but it's a good practice for lifecycle management. Just note that to use this, you must only have one bundle ID in the detection list (hence one app) and it should be in /Applications.

• Document your detection rules: For each app you integrate into Intune, document the bundle ID and version used, and whether you set ignore version to yes/no. This helps if another admin needs to update the app or troubleshoot. It also helps you remember to update the version in Intune when the app is updated. Keeping a simple spreadsheet or documentation of "App name – bundle ID – version – ignore version setting" can be invaluable for tracking your macOS app deployments.

• Monitor and adjust: After deployment, regularly check Intune's app install status reports. If you see a high failure rate or devices where installation is stuck, investigate those. It could be a detection issue you need to adjust (for example, maybe a new version came out and many devices auto-updated, causing your detection to fail). Intune allows editing the detection rules of an existing app, so you can correct them and have devices retry the detection (devices will typically re-evaluate app installs on the next check-in or when you re-push the assignment). Proactively monitoring ensures you catch any pattern (like "App X not detected on macOS 12 devices" or similar) early.

Following these best practices will make your Intune macOS app management much more predictable. The goal is to configure the detection in a way that Intune reliably knows the app's presence and status on the Mac. A little extra time spent verifying bundle IDs, cleaning up detection lists, and deciding on version rules will save a lot of headache later.

Conclusion
App detection rules are the backbone of successful macOS app deployment in Intune. They ensure that the Intune agent can confidently say an app is installed (or not) and take action accordingly. By understanding how Intune uses bundle IDs and versions to identify apps, you can configure detection rules that align perfectly with each Mac app you deploy. Always gather the necessary app identification details beforehand (using tools like Terminal's defaults read for CFBundleIdentifier and version) and use the appropriate settings (version checking on or off) based on the app's nature. With careful setup and the best practices outlined above, you'll minimize false detection issues and enjoy more streamlined app installations and updates. Ultimately, well-defined detection rules mean less manual intervention, fewer reinstall loops, and a better experience for both admins and end-users in your macOS Intune environment.