The Apple Tracking Policy controls which supported device events and security information Swif tracks on managed Macs. Administrators can enable USB, device lock, device wipe, location, application block, XProtect log, and audit log tracking independently.

Use this policy to collect evidence for investigations, review device activity, and monitor security configuration. Tracking does not itself block USB devices or applications, lock or erase a Mac, start an XProtect scan, or repair audit-log permissions.

Learn more at Tracking Device and Browser Events with Swif.

Despite the name, this policy is for Macs. It does not provide iPhone or iPad tracking.

Use macOS 12.0 or later as the deployment baseline for the complete policy. Individual lock and wipe field descriptions list an earlier minimum, but the policy's overall supported minimum is macOS 12.0.

Choose lock and wipe tracking values explicitly when creating the policy. Do not assume an unspecified value means enabled or disabled on every device.

The policy does not expose a collection-interval or data-retention setting.

Enables tracking of supported USB device activity, such as connections involving external drives or peripherals.

This can help investigate when removable hardware was connected. A connection event does not prove that files were copied, identify every transferred file, or establish that data left the organization.

Use the separate Apple USB Policy when you need USB restrictions. Enabling tracking alone does not deny access to a connected device.

Combine this policy with the Apple USB Policy for a complete endpoint tracking and control strategy.

Enables reporting of device lock events. These records can help administrators review lock activity alongside other device evidence.

This setting does not set an inactivity timeout, require a password, or send a lock command. Configure the applicable lock-screen or screen-saver controls separately.

Do not treat lock records alone as a measure of employee attendance or productivity. The absence of an event can also reflect collection or connectivity gaps.

Enables reporting of supported device wipe events, including managed wipe activity described in Swif's tracking documentation.

Enabling this option does not erase the Mac. A wipe must be initiated separately through an authorized management action.

For offboarding and disposal, review the wipe event together with the command status and your device-handling records. An event indicating a wipe request or action is not, by itself, independent proof that every storage location was erased. A wiped or disconnected device may no longer be able to report.

Requests location information during periodic compliance checks throughout the day.

This is periodic location reporting, not a promise of continuous, real-time tracking. The policy does not let administrators specify a polling interval or guarantee location accuracy.

On macOS, access to location is controlled through Location Services. On recent macOS releases, review System Settings > Privacy & Security > Location Services. Older releases use System Preferences > Security & Privacy > Privacy. Check the requesting Swif application's permission where it appears. Assigning a tracking policy should not be treated as proof that macOS has granted permission. See Apple: Control access to the location of your Mac.

Enable location tracking only for the devices and purposes covered by your organization's tracking practices. Consider BYOD separately because location may reveal personal activity away from work.

Reports application-blocking events when a corresponding Apple Application Block Policy is assigned and blocking occurs. Learn more →

For example, an attempt to open an application prohibited by the blocking policy can generate an event for review.

Both components serve a distinct purpose:

This setting does not create an application blocklist or record all application usage. Test it with a harmless application selected for a pilot restriction.

Combine with Apple Application Block Policy, which blocks apps to track blocking events.

Periodically reads XProtect Remediator scan results from the macOS unified log and reports the information available in those records:

This is monitoring only. The policy does not configure XProtect, trigger scans, change its schedule, or initiate remediation.

Apple provides XProtect as part of macOS malware protection. Swif's setting adds visibility into available results. See Apple: Protecting against malware in macOS.

Interpret the reported verdict before taking action. A plugin name identifies the scanner involved; it does not by itself mean malware was found. Likewise, no reported result does not establish that the Mac is malware-free.

Reports the audit-log configuration associated with Swif's ALC-1 control, including:

Mode describes file-system permission bits. Ownership and ACL information helps administrators assess who can access or modify audit records.

This option monitors configuration. It does not change permissions or ownership, enable auditing, or repair a failed check. It also should not be described as forwarding the complete contents of the Mac's audit logs.

If a reported value differs from your requirements, use a separately approved remediation process and verify the next report.

For a company-owned Mac pilot, start with the categories needed for your security operations:

These are suggested deployment choices, not product defaults. For BYOD, scope each category to the agreed management purpose and explain the data collected to affected users.

Swif's Apple Tracking Policy documentation directs administrators to Device Management > Event Logs for device events and Device Management > Device Detail > Tracking for location information. Use the corresponding security or compliance report for XProtect results and ALC-1 configuration evidence available in your dashboard.

Always check the device, event time, and latest check-in before interpreting a record.

Successful policy installation confirms delivery, not that a relevant event has already occurred. Some categories require a later event or periodic collection before information appears.

Tracking records can contain device activity, physical location, and file paths. XProtect paths may include usernames or project names. Audit-log configuration can expose local account and permission details.

Explain the selected categories to users, restrict access to reports, and apply your organization's retention process. This policy has no retention field, so disabling a category should not be treated as a request to delete previously reported data.

For more information, see the Swif Privacy Policy.

Confirm that the relevant switch is enabled, the Mac meets the policy requirements, and the Swif reporting components are operational. Check the last check-in, report filters, and whether a relevant event occurred after configuration.

If the Mac was offline, reconnect it and review subsequent reporting. Do not assume every event from an offline period will necessarily be recovered.

Check Location Services and the requesting application's permission. Confirm that the Mac can communicate with Swif, then allow another periodic compliance check. A previously reported location should be read with its timestamp, not treated as the device's current position.

Confirm that Application Block Tracking is enabled and that the restriction came from the assigned Apple Application Block Policy. Check the application match, policy status, check-in time, and event filters. A block imposed by another security product may not generate a Swif application-block event.

USB tracking should not be interpreted as a complete file-transfer audit. Review the event's actual fields. Use an appropriate data-protection control if your requirement is to detect or prevent specific transfers.

Confirm that XProtect Log Tracking is enabled and review collection errors. Available results depend on XProtect activity and readable unified-log records. Enabling tracking does not immediately start a scan or guarantee that older records remain available.

This is expected. Audit Log Tracking reports ALC-1 configuration without changing it. Apply the approved corrective configuration separately and verify the next report.

Review the management command's status and the device's last communication. Do not use the existence of a tracking record as the only evidence of successful erasure. Follow your organization's disposal-verification process.

To change collection, edit the relevant switches, save the policy, allow the Mac to check in, and verify subsequent reporting.

To stop managing this configuration, remove the assignment and verify the resulting state. If you need a specific category disabled, explicitly deploy that value and confirm it before relying on policy removal. The supplied policy definition does not specify cleanup behavior on removal.

Disabling tracking does not itself disable XProtect, remove application restrictions, change audit-log permissions, or delete previously collected records.