A digital publication from the J. Willard Marriott Library
Red Block U Logo

Uninstalling Adobe Acrobat DC on macOS: The Character-Building Exercise Gets Specific

10 Aug Uninstalling Adobe Acrobat DC on macOS: The Character-Building Exercise Gets Specific

Posted at 10:26h in Administration, Automation, Documentation, Enterprise, Higher Education, Information Technology by
1 Like

Adobe Acrobat DC has a reputation for being one of those apps that seems simple until you try to remove it at scale. On paper, the task looks straightforward: uninstall the app, verify it is gone, move on. In practice, Acrobat frequently behaves like a special case inside Adobe’s larger macOS ecosystem. It is not always handled the same way as the rest of the Creative Cloud family, and that makes a good uninstall workflow more important than a casual one-off removal.

That is why Acrobat DC deserves its own post. The broader Adobe uninstall story is already complicated. Acrobat adds a few extra wrinkles because it is both a current product and a long-lived endpoint in Adobe’s packaging history. It may have been installed from an Admin Console package, an older package workflow, a manual installer, Creative Cloud Desktop, or a local support scramble that made sense at the time. It may be Acrobat Pro, Acrobat Standard, Acrobat Reader, or a DC-era variant. It may arrive with helper tools, launch agents, preferences, licensing state, and shared Adobe components that are not always removed by the first method you try.

For MacAdmins, that is not an abstract problem. It becomes a practical one when a lab machine needs to be rebuilt, a device needs to be repurposed, or an old Acrobat deployment needs to be removed before a new install. In those moments, the right answer is usually not “run one command and hope.” The right answer is to treat Acrobat uninstall as a layered workflow with verification built in.

Acrobat DC removal is layered Start with Adobe's evidence, then move through app-specific and cleanup paths only as needed.

Key Topics

  • Why Acrobat DC is not handled like most Creative Cloud apps.
  • Why Adobe’s command-line uninstall tool is a good first step, and why --list is useful preflight evidence.
  • How Acrobat’s bundled remover fits into the process.
  • Why Acrobat Pro/Standard and Acrobat Reader should not be treated as the same target.
  • Why targeted cleanup still matters after the main uninstall methods fail.
  • Why a simple, logged workflow is more reliable than a heroic one-line cleanup.

Why Acrobat DC Is Different

The first thing to understand is that Acrobat DC does not always fit neatly into the same uninstall model as other Adobe applications. Adobe’s current enterprise guidance points admins toward the Adobe uninstall tool for many Creative Cloud products, and that is a sensible place to start. But Acrobat has long been treated as a slightly different animal in the Adobe ecosystem. It has its own app behavior, its own package history, and its own cleanup needs.

That matters because uninstall success is not only about the application bundle. It is also about the surrounding state that Adobe leaves behind. Acrobat can leave behind helper frameworks, support tools, launch services, preferences, and application support files. Some of those pieces are easy to miss if the workflow stops after the main app disappears.

This is one reason Acrobat removal is often less tidy than expected. A machine may appear to be “clean” after the app is deleted, only to show signs of old Acrobat state during a future reinstall, a support ticket, or a lab refresh. The result is an ecosystem that can still feel half-removed even when the visible application is gone.

AdobeUninstaller Is the Right First Step

For current enterprise workflows, AdobeUninstaller is the best place to start when the installed product is visible to Adobe’s command-line uninstall tool. Adobe documents the tool for Creative Cloud app removal, including --list, XML output, --products, and --uninstallConfigPath workflows. The important preflight habit is to list first, then uninstall from evidence:

sudo /tmp/adobe_uninstaller/AdobeUninstaller --list
sudo /tmp/adobe_uninstaller/AdobeUninstaller --list --format=XML

# Optional local Acrobat filter when APRO is the target
sudo /tmp/adobe_uninstaller/AdobeUninstaller --list --products=APRO

That first pass answers the question that matters most: what does Adobe’s own tool think is installed on this Mac? Once the installed Acrobat target is confirmed, an Acrobat uninstall can attempt the matching target. In the local script, that target is the Acrobat SAP code APRO:

sudo /tmp/adobe_uninstaller/AdobeUninstaller --products=APRO

In environments where AdobeUninstaller reports a base-version-specific Acrobat target, use the exact value from --list or the XML output rather than relying on memory. The broader Adobe uninstall documentation is clear that product-specific uninstall commands can use SAP codes with base versions, and mixed fleets are exactly where that detail becomes a quiet failure point.

Using AdobeUninstaller is the cleanest first pass when the tool recognizes the installed product. It is also the path that makes the most sense when the Mac still has a valid Adobe enterprise package story behind it. If the tool works, the workflow can stop there. If it does not, the next step is to treat the failure as information rather than as a reason to panic.

AdobeUninstaller is typically obtained from the Adobe Admin Console. In the Adobe Admin Console, admins can go to Packages > Tools to download the enterprise uninstall utility for the relevant Adobe product family. Adobe’s own documentation for enterprise uninstall workflows is the best place to review the supported usage patterns, including the command-line options for listing products, uninstalling specific products, and using the tool in mixed environments.

The documentation is especially useful when you need to understand the difference between an app-specific uninstall, a broader Adobe cleanup, and a version-targeted uninstall. In practice, the workflow usually looks like this:

  • Download AdobeUninstaller from Adobe Admin Console > Packages > Tools.
  • Copy it to a temporary location such as /tmp/adobe_uninstaller.
  • When validating a Mac or troubleshooting, run --list and keep the output with the uninstall log.
  • Run the tool with the relevant product target and inspect the exit status.
  • Treat a failure as a signal to move to the Acrobat-specific remover or the fallback cleanup path.

This is where Adobe’s documentation and reality begin to diverge a little. The uninstall tool may fail because the installed product differs from what the package history suggests, because the app was installed through a different packaging path, or because the installed state is older or more inconsistent than expected. In those cases, the tool is still useful, but it is not the end of the story.

The Acrobat Bundled Remover Matters

The next step in the workflow is Acrobat’s own bundled remover. This is one of the reasons Acrobat deserves a dedicated script. Adobe’s user-facing macOS instructions for Acrobat point people to the Acrobat Uninstaller inside the application folder. For fleet work, that same idea matters because the app bundle may contain a remover that is closer to Acrobat’s own expectations than a generic file cleanup.

In our workflow, that path looks for the Acrobat app in standard install locations and then checks for the bundled remover at a specific path such as:

/Applications/Adobe Acrobat DC/Adobe Acrobat.app/Contents/Helpers/Acrobat Uninstaller.app/Contents/Library/LaunchServices/com.adobe.Acrobat.RemoverTool

If that tool exists, the script can call it directly with the app path as an argument. That is a meaningful distinction. AdobeUninstaller is the enterprise-facing tool. Acrobat’s bundled remover is the application-specific recovery path. They are related, but they are not interchangeable.

That distinction matters because Acrobat is one of those titles that can be removed in a way that looks “mostly successful” while still leaving behind bits of state that cause later trouble. The bundled remover is a useful second pass because it is closer to the actual Acrobat app experience and often better aligned with what the app expects to remove.

Know which Acrobat you are removing.

Acrobat Reader Is a Different Boundary

This post is focused on Adobe Acrobat DC, especially Acrobat Pro/Standard-style deployments in managed environments. Acrobat Reader is related, and the current local script includes Reader paths because real-world Acrobat and Reader footprints can overlap. Still, Reader should not be treated as the same uninstall target without checking the installed app and Adobe’s current guidance.

Adobe’s public Reader uninstall instructions for macOS are simpler than the Acrobat instructions: quit Reader, remove the app from /Applications, and restart. That does not mean every managed Reader deployment is automatically clean after a trash removal, and it does not mean Reader leftovers never matter. It does mean a script should identify whether it is removing Acrobat or Reader before it starts deleting paths.

That boundary is useful operationally. If the Mac has /Applications/Adobe Acrobat/Adobe Acrobat.app, that is a different situation than /Applications/Adobe Acrobat Reader.app or an older /Applications/Adobe Acrobat DC folder. When the fallback path runs, the output should at least show which app path was found, which remover path was attempted, and which cleanup rules were applied.

The Cleanup Fallback Is Not Glamorous, But It Helps

If AdobeUninstaller and the bundled remover both fail, the workflow needs a fallback. That fallback is not glamorous, but it is practical. The goal is not to be clever. The goal is to remove the remaining evidence that makes Acrobat feel half-installed.

That is where the script moves into targeted cleanup. It can remove common Acrobat-related application folders, Adobe support directories, launch agents and launch daemons, preference files, temporary paths, and other leftovers that are often associated with the old installation. The approach is necessarily broad because Acrobat’s install footprint is broad. The script also tries to unload Adobe services before removing them, which is useful because some helper components will not delete cleanly while they are still running or loaded.

This stage is not a substitute for the vendor uninstall methods. It is a follow-up for the cases where the app is present but the AdobeUninstaller or bundled-remover path has not completed successfully. In other words, it is the cleanup layer, not the primary method. The important operational habit is simple: try Adobe’s uninstall tooling as the first step, but verify what actually happened on disk before declaring the Mac clean.

Why a Layered Workflow Is Better Than a Single Command

The real lesson from Acrobat DC uninstall work is that Adobe cleanup is rarely a single-step operation. A strong workflow looks more like this:

  1. Try Adobe’s uninstall tool first.
  2. Use Acrobat’s own bundled remover if the first path fails.
  3. Perform targeted cleanup for leftover files, services, and preferences.
  4. Verify that the main app paths are gone.
  5. Log what happened so the next admin can understand the result.

That sequence is boring, but boring is good in this context. Boring means predictable. Predictable means less chance of damaging the device or leaving behind an install footprint that causes trouble later.

It also means the workflow is easier to troubleshoot. If the first uninstall fails, the log shows whether the problem was the Adobe tool, the Acrobat-specific remover, the helper services, the app location, or the leftover filesystem state. That is much more useful than a final exit code with no context.

The log is part of the uninstall process

Why the Script Was Built This Way

The Marriott Library approach to Acrobat DC uninstall is intentionally practical. The script is designed to try the enterprise uninstall tool first, then the built-in Acrobat remover, and then a targeted cleanup path if needed. That structure reflects the reality of the field. Adobe’s tools improve over time, but they do not always cover every mixed-fleet or legacy install scenario cleanly.

The script is also careful about logging and scope. It records the commands, the exit codes, and the key stages of the removal process. That matters because Adobe uninstall work often becomes a support problem later if nobody remembers what happened during the cleanup. A script that logs clearly is easier to trust, easier to review, and easier to reuse in the future.

For teams managing shared labs, classroom devices, staff workstations, or refresh projects, that kind of transparency is valuable. It turns an uninstall from a one-off troubleshooting task into a documented operational workflow.

The Marriott Library Script

The Marriott Library workflow for Acrobat DC is being prepared as a companion to the broader Adobe CC uninstall work. The intent is to make the script available as a reusable, documented example for other MacAdmins who need a practical Acrobat/Reader-specific uninstall path without having to reconstruct the logic from scratch.

At a high level, the script is built around the same layered approach described above:

  • It tries Adobe’s command-line uninstall tool first with the Acrobat APRO product target.
  • If that fails, it checks for Acrobat’s bundled remover and attempts a more application-specific uninstall.
  • If the AdobeUninstaller and bundled remover paths do not succeed, it moves into targeted cleanup for Adobe support files, helper tools, launch agents, launch daemons, preferences, and temporary paths.
  • It logs the actions and exit codes so the removal process is easier to review later.

The more technical shape of the script is intentionally plain shell. It is meant to run well from Jamf Pro, Self Service, a policy trigger, or a root shell during hands-on troubleshooting. The current script is versioned in the header, defines the staged Adobe uninstall binary path as CLI_BINARY_PATH, and defines the Acrobat product target as ADOBE_PRODUCT_NAME="APRO".

CLI_BINARY_PATH="/tmp/adobe_uninstaller/AdobeUninstaller"
ADOBE_PRODUCT_NAME="APRO"

That small editable block is the deployment contract. The Adobe Admin Console tool gets staged at /tmp/adobe_uninstaller/AdobeUninstaller, the script calls it with the Acrobat SAP code, and the rest of the script is fallback behavior for the machines where that first path does not finish the job.

The AdobeUninstaller phase in the current script is direct. If the binary exists, the script logs the command, runs Adobe’s tool, captures the exit code, and treats exit code 0 as a successful primary uninstall:

/tmp/adobe_uninstaller/AdobeUninstaller --products=APRO

If AdobeUninstaller is missing, or if it returns a non-zero exit code, the script does not stop immediately. It records that failure and moves into the Acrobat-specific fallback path. That behavior is important in Jamf because a missing staged tool and a failed Adobe uninstall are different problems, but both should still give the script a chance to remove a real app that is sitting on disk.

That is a slight difference between the recommended troubleshooting workflow and the current production script. For manual validation, --list is useful evidence. For the deployed script, the first action is the direct APRO uninstall attempt, followed by fallbacks if that attempt fails.

The bundled-remover phase searches a list of common Acrobat and Reader app locations:

/Applications/Adobe Acrobat DC/Adobe Acrobat.app
/Applications/Adobe Acrobat Reader DC/Adobe Acrobat Reader DC.app
/Applications/Adobe Acrobat Reader.app
/Applications/Adobe Acrobat.app

The bundled-remover phase checks for Acrobat’s remover inside the application bundle:

Contents/Helpers/Acrobat Uninstaller.app/Contents/Library/LaunchServices/com.adobe.Acrobat.RemoverTool

If that executable exists, the script runs it against the discovered app path with Acrobat’s expected Uninstall argument:

sudo "$BUILTIN_UNINSTALLER" Uninstall "$ACROBAT_APP"

This is the part that makes the script different from a generic Adobe CC app remover. The script is not only deleting /Applications/Adobe Acrobat DC; it is giving Acrobat’s own removal logic a chance to clean up the app in the way Acrobat expects.

The cleanup phase is deliberately a fallback, not the first move. The script first unloads Acrobat/Reader-related Adobe ARM launch daemons and launch agents from /Library/LaunchDaemons and /Library/LaunchAgents, then checks user homes for user-specific Adobe launch agents and unloads those as the owning user. It pauses briefly afterward so services have a chance to stop before files are removed.

The targeted cleanup list includes Acrobat and Reader app folders, Acrobat support folders under /Library/Application Support/Adobe, Adobe PDF and Distiller support, ARMDC/ARMDCx86 updater state, Acrobat-related preferences, launch agents, launch daemons, privileged helper tools, temporary Acrobat paths, and /usr/local/bin/RemoveAdobeARMService. It also includes user-specific preferences, caches, application support, and saved application state for every local home folder except /Users/Shared.

The script also handles receipts in two ways. It forgets matching package receipts from pkgutil --pkgs when the receipt name looks Acrobat-, Reader-, ARMDC-, or Acrobat updater-related. Then it removes matching filesystem receipt files from /private/var/db/receipts. For wildcard cleanup paths, it uses compgen -G rather than passing raw unquoted globs directly into rm, which makes the cleanup behavior easier to reason about in logs.

The final verification step checks a specific TARGET_APP_PATHS array before declaring fallback cleanup successful:

/Applications/Adobe Acrobat DC
/Applications/Adobe Acrobat Reader DC
/Applications/Adobe Acrobat Reader.app
/Applications/Adobe Acrobat.app
/Applications/Adobe Acrobat Next Pro

If those target paths are gone, the script converts the previous failure into success and reports how many items were removed. If any target app path remains, it leaves the uninstall result as a failure. At the very end, the script removes the temporary AdobeUninstaller binary from /tmp/adobe_uninstaller/AdobeUninstaller if it still exists, then exits with the final uninstall exit code so Jamf can report the policy accurately.

A useful review of this script’s output should answer four questions:

  • Which Acrobat path was found?
  • Which uninstall methods ran?
  • What were the exit codes?
  • Which Acrobat paths, if any, remained at the end?

The script is available in the Marriott Library GitHub organization:

The script itself follows the same operational pattern used by the broader Marriott Library Adobe workflow: start with Adobe’s uninstall method, fall back to Acrobat’s own remover when needed, and use a cleanup pass only when the first two steps fail to leave the Mac in a clean state.

Where to Get the Script

From a Web Browser

  1. Sign in to GitHub with an account that has access to the repository.

  2. Open the repository:

    https://github.com/univ-of-utah-marriott-library-apple/adobe-acrobat-dc-uninstall

  3. Open the script page:

    https://github.com/univ-of-utah-marriott-library-apple/adobe-acrobat-dc-uninstall/blob/main/adobe_acrobat_dc_uninstaller.sh

  4. Use Raw to view the file as plain text, or use Download to save a local copy.

  5. Review the history if you want to see how the script changes over time.

With GitHub Desktop

  1. Open GitHub Desktop and sign in.

  2. Choose File > Clone repository.

  3. Use the URL tab and enter the repository URL:

    https://github.com/univ-of-utah-marriott-library-apple/adobe-acrobat-dc-uninstall.git

  4. Choose a local destination and click Clone.

  5. Open the repository in Finder or in your editor to review the script.

With the Git CLI

  1. Clone the repository:
git clone https://github.com/univ-of-utah-marriott-library-apple/adobe-acrobat-dc-uninstall.git
cd adobe-acrobat-dc-uninstall
  1. Verify the remote and current branch:
git remote -v
git branch --show-current
git status
  1. Preview the script:
ls
sed -n '1,120p' adobe_acrobat_dc_uninstaller.sh

That makes it easy to review the script locally, compare versions, and use it as a starting point for your own environment or deployment workflow.

A Practical Workflow for MacAdmins

If you need to remove Acrobat DC from a Mac in a reliable way, a practical workflow looks like this:

  • Inventory the Acrobat app location and verify that the intended app is present.
  • Try AdobeUninstaller first; use --list as preflight evidence when validating or troubleshooting.
  • If that fails, check for Acrobat’s bundled remover and run it.
  • If the app still leaves behind state, perform targeted cleanup for Adobe support files and services.
  • Verify that the main Acrobat app paths are gone.
  • Record the outcome and keep the logs.

That is the workflow I would want in a production environment. It is not flashy, but it is durable. And in the world of Adobe uninstall, durability matters more than elegance.

A Generic Acrobat DC Cleanup Pattern

If I were to reduce the whole process to a plain-language pattern, it would look something like this:

check for AdobeUninstaller
list installed Adobe products and save the evidence
try AdobeUninstaller with the matching Acrobat target
if that fails, look for Acrobat's bundled remover
if that fails, unload Adobe services and remove common Acrobat leftovers
verify the app paths are gone
report the result and keep logs

That is the boring shape of the work, and that is exactly why it is useful. Adobe cleanup already has enough surprises. The automation should not add more.

References

Adobe Acrobat DC is a good reminder that Adobe uninstall work is rarely about one single tool. It is about matching the right tool to the installed reality, handling the app-specific edge cases, and leaving enough evidence behind that the next admin can understand what happened. That is the part that turns uninstall work from guesswork into practice.

No Comments

Leave a Reply