Skip to main content

Apple Tracking Policy (App Blocking Tracking)

Updated today

The Appe Tracking Policy in Swif.ai can be used together with the Apple Application Block Policy to give you visibility into when users try to open blocked applications on macOS devices, and to surface those events in Swif’s reports.

This builds on the existing Apple Tracking Policy described here:
Apple Tracking Policy | Help Center | Swif.ai

Note: This article focuses specifically on app‑blocking–related tracking on macOS. For USB, lock/unlock, wipe, and location tracking, refer to the Apple Tracking Policy article above.


What This Policy Does for App Blocking

When used together with an Apple Application Block Policy, the Apple Tracking Policy allows Swif.ai to collect additional data related to blocked apps:

1. Blocked app open attempts (real‑time blocking callback)

When a user attempts to launch an application that has been blocked via an Apple Application Block Policy, the Swif's agent will:

  • Detect that the application is blocked by policy.

  • Prevent the application from running (Swif denies execution).

  • Send a callback event from Swif's sync server into Swif’s backend indicating:

“You blocked this app, but a user still tried to open it.”

This gives Security and IT teams visibility into attempted policy violations and user behavior on macOS devices.

These callback events are processed through the same tracking/event pipeline used by other tracking fields and are visible in Swif.ai’s Event Logs and related reports.


How App Blocking Works on macOS with Tracking

On macOS, Swif’s app blocking and tracking pipeline operates as follows:

  1. User launches an app on macOS.

  2. Swif evaluates the app against your block rules (managed via Swif policies).

  3. If the app matches a rule in an Apple Application Block Policy:

    • Swif blocks the execution of the app.

    • Swif sends a block event to the sync server.

  4. Swif’s backend receives this callback and records a tracking event tied to:

    • Device

    • Blocked application identifier (e.g., path, hash, or name as available)

    • Time of the attempted launch

  5. The event is surfaced in Swif.ai:

    • Under Reports → Event Logs → Device Events and other relevant views.

Result: You get both enforcement (app is blocked at execution time) and observability (you can see every attempt to run a blocked app), without needing to manually collect logs from endpoints.

Important: This feature applies to macOS devices managed by Swif.ai where both Apple Application Block Policy and Apple Tracking Policy are configured.


Requirements

  • OS: macOS

  • Policies required:

    • An Apple Tracking Policy with app‑blocking tracking enabled (field described below).

    • A Apple Application Block Policy defining which apps or binaries to block (for example, by path, team ID, hash, or other supported match criteria).

  • Device management: Device enrolled and managed via Swif.ai MDM.

  • Agent: Swif macOS agent installed and up-to-date.

For the base Apple Tracking Policy documentation (USB, lock, wipe, location), see:
Apple Tracking Policy | Help Center | Swif.ai


Policy Settings (App‑Blocking–Related)

In addition to the existing Apple Tracking Policy fields (USB Tracking, Device Lock Tracking, Device Wipe Tracking, Location Tracking), the Apple Tracking Policy includes an app‑blocking tracking setting:

Field Name

Description

Value Options

Events Report Location

Minimum Requirement

Application Block Tracking

Controls whether Swif logs tracking events related to blocked applications on macOS devices. This includes when a user attempts to open a blocked app and Swif denies execution, and that event is sent to Swif via the sync server callback.

True – Enables tracking of blocked app open attempts. A tracking event is created whenever Swif blocks an application that matches your Apple Application Block Policy. False – Disables app‑blocking tracking events (apps may still be blocked, but attempts are not logged as tracking events).

View reports at Device Management → Event Logs and relevant security/endpoint reports.

macOS

Behavior when enabled (true)

  • Real‑time event on block:

    • When the user runs an app that is blocked by policy:

      • Swif blocks the execution.

      • Swif sends a callback to the sync server.

      • Swif records a “Blocked application opened (macOS)”–type tracking event.

  • Events include key context such as:

    • Device identifier

    • Timestamp

    • Blocked application identifier details (for example, executable, bundle, or hash, depending on the implementation)

Behavior when disabled (false)

  • The Apple Application Block Policy can still prevent the app from running.

  • However:

    • No special tracking events are generated when blocked apps are attempted.

    • You will not see app‑blocking attempts in Event Logs tied to this tracking field.


Where to View App‑Blocking Tracking Events

Once both the Apple Tracking Policy and Apple Application Block Policy are applied, and Application Block Tracking is enabled:

Go to:

  • Device Management → Event Logs → Device Events

You will see entries such as:

  • Blocked application opened (macOS)
    Indicates that:

    • The app is blocked by your policy.

    • A user attempted to run it.

    • Swif and the sync server reported the block, and Swif recorded it as a tracking event.

These events can typically be filtered by:

  • Device

  • Application name / identifier (depending on what is stored)

  • Event type (e.g., blocked application)

  • Time range

This gives Security and IT teams a consolidated view of attempted policy violations on macOS, similar in spirit to Linux app‑blocking tracking described here:
Linux Tracking Policy (App Blocking Tracking) | Help Center | Swif.ai


Example Use Cases

  • Enforce high‑risk software bans on macOS

    • Block remote‑control tools, high‑risk browsers, or unsanctioned collaboration apps.

    • Track every attempt to run them, even if users rename app bundles or try different paths (subject to your policy rule design).

  • Investigate suspicious behavior

    • Correlate “blocked application opened (macOS)” events with:

      • USB Tracking events

      • Lock/unlock patterns

      • Other device activity

    • Build a clearer picture of users repeatedly trying to bypass security controls.

  • Compliance & audit evidence

    • Show that restricted apps on macOS are:

      • Explicitly blocked by technical control.

      • Actively monitored via tracking events.

    • Support requirements for SOC 2, ISO 27001, HIPAA, or internal security policies.


How to Configure App‑Blocking Tracking on macOS

1. Create or update your Apple Tracking Policy

  1. In the Swif Admin Console, go to Policies.

  2. Choose Apple Tracking Policy (or create a new one), as described here:
    Apple Tracking Policy | Help Center | Swif.ai

  3. Enable Application Block Tracking for macOS.

  4. (Optionally) also configure:

    • USB Tracking

    • Device Lock Tracking

    • Device Wipe Tracking

    • Location Tracking
      according to your organization’s needs.

  5. Assign this tracking policy to the target macOS devices or device groups.

2. Configure your Apple Application Block Policy

  1. In the Swif Admin Console, go to Policies → macOS → Application Block Policy (or equivalent macOS software/app blocking policy).

  2. Define the applications you want to block, for example:

    • Specific app bundle identifiers or paths.

    • Developer/team IDs or signing identifiers supported by Swif.

    • Hashes or other rule types as per your allowed/blocked ruleset.

  3. Assign this policy to the same device groups that have the Apple Tracking Policy with Application Block Tracking enabled.

3. Verify on a test macOS device

  1. Make sure:

    • The device is enrolled in Swif.ai MDM.

    • The Swif macOS agent is installed and running.

    • Both the Apple Application Block Policy and Tracking Policy are applied.

  2. On the test device:

    • Attempt to open an application that is blocked by your policy.

  3. In Swif:

    • Confirm that the application is prevented from running (on the device).

    • Check Reports → Event Logs → Device Events for a new “blocked application opened (macOS)” event associated with that device and app.


Verification & Troubleshooting

If you do not see app‑blocking tracking events for macOS:

  1. Confirm policies are assigned

  2. Check the Swif macOS agent

    • Confirm the Swif agent is installed and running.

    • If needed, restart the device or agent and allow time for policy sync.

  3. Check Event Logs filters

    • In Reports → Event Logs → Device Events:

      • Clear or widen filters (time range, event type, device).

      • Verify that you are looking at the correct organization environment and device.

  4. Confirm the app matches your block rules

    • Double‑check the identifiers you used in the Apple Application Block Policy (e.g., path, identifier, hash).

    • Ensure they match the actual app being launched on the endpoint.


Best Practices

  • Always pair policies

    • Use Apple Tracking Policy + Apple Application Block Policy together:

      • Application Block Policy → enforcement.

      • Tracking Policy → visibility into blocked app attempts.

  • Start with a pilot group

    • Roll out app‑blocking and tracking to a small set of macOS devices first.

    • Validate that critical apps are not unintentionally blocked and that events appear as expected.

  • Monitor trends

    • Use Event Logs to review:

      • Which blocked apps are most frequently attempted.

      • Which devices or users are repeatedly trying to run blocked software.

    • Use this data to refine your block rules or user training.

  • Automate alerts and workflows

    • Integrate block‑attempt events with:

      • Notification systems (email, chat).

      • Ticketing or SOAR tools.

    • For example, automatically open a ticket when a high‑risk blocked app is attempted multiple times.

  • Review regularly

    • Periodically review:

      • Your list of blocked macOS applications.

      • The event data for blocked app attempts.

    • Align your control set with current risk, approved software catalogs, and business requirements.


Did this answer your question?