> For the complete documentation index, see [llms.txt](https://docs.easy2patch.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.easy2patch.com/managing-easy2patch/easy2patch-4.0/macos-apps/application-and-update-modes.md).

# Application and Update Modes

A macOS product can be sent to Intune in two modes: as an **Application** or as an **Update**. On Windows these two modes differ in several places — different scripts, different rules, a different application category. On macOS they differ in exactly one field.

### The one difference

| Mode            | `ignoreVersionDetection` | What Intune looks for on the device                                                                                               |
| --------------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
| **Application** | Yes                      | The **bundle ID** only. If the application is not installed, install it. If it is installed, leave it alone whatever its version. |
| **Update**      | No                       | The **bundle ID and the bundle version**. If the installed version differs from the one in the package, install the package.      |

That is the whole of it. Both modes upload the same package, build the same application type, carry the same bundle identifiers, the same minimum operating system and the same icon.

{% hint style="info" %}
This is Microsoft's own definition of the setting, not an Easy2Patch convention. **Yes** is intended for applications that update themselves and would otherwise fight with Intune over the version number; **No** is intended for applications whose version you want Intune to enforce.
{% endhint %}

### Choosing a mode

**Send as Application** when you want the product present on the device and you do not care which version is there — typically an application with its own updater, or a first-time rollout where the fleet is mixed.

**Send as Update** when the version matters — when the point of the deployment is to move devices from an old build to a new one.

### Naming

The mode is part of the name the application carries in Intune, so both can exist side by side in the same tenant and neither is mistaken for the other in a list. The suffix also marks which applications were created by Easy2Patch; applications you created by hand in the Intune portal are not touched by Easy2Patch maintenance operations.

### This is not the same as Auto Update

Two settings sound similar and are unrelated. They do not constrain each other, and every combination of the two is valid.

| Setting                                                  | Where it takes effect                    | What it does                                                                         |
| -------------------------------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------------ |
| **Auto Update** (Off / Evergreen / Versioned)            | In the Easy2Patch catalog, on the server | Fetches the new version from the vendor and refreshes the Easy2Patch product record. |
| **Ignore version detection** (Application / Update mode) | On the endpoint, inside Intune           | Decides whether Intune enforces the version on the device.                           |

A product can be set to **Versioned** auto update and still be sent as an **Application** with `ignoreVersionDetection = Yes`. That combination is legitimate and common: Easy2Patch keeps the catalog record current, while Intune leaves the self-updating client alone on the device.

### Related pages

* [Deployment Models](/managing-easy2patch/easy2patch-4.0/macos-apps/deployment-models.md)
* [Publish Options and Retire](/managing-easy2patch/easy2patch-4.0/macos-apps/publish-options-and-retire.md)