The application can’t be opened

macOS 'The Application Can’t Be Opened' Error: Real Fixes That Work

When macOS blocks an app because of Gatekeeper, a corrupt download, or mismatched permissions. Here's how to actually fix it, from the most common cause down.

Cause #1: Gatekeeper’s quarantine flag is blocking the app

What's actually happening here is that macOS tags every app you download from outside the App Store with a special extended attribute called com.apple.quarantine. When you try to open it, Gatekeeper reads that flag and—because the app isn't notarized by Apple—refuses to launch. This is a security feature, but it's also the reason why a perfectly safe app you downloaded from a developer's website won't open.

The most common trigger is downloading a fresh build of something like a browser or a utility from GitHub, then double-clicking it. You get the “The application can’t be opened” alert, and the app just sits there in your Downloads folder.

Here's the fix that works about 90% of the time, and it's simpler than most people think: right-click the app and select Open. macOS will show a slightly different dialog with an Open button you can click. That tells Gatekeeper “I know what I'm doing” and adds the app to the allowed list. It's the quickest fix, and you can use it on any app that's blocked this way.

But right-clicking doesn't always work, especially if the app is a command-line tool or a .pkg installer. In that case, you need to remove the quarantine flag manually. Open Terminal and run:

xattr -d com.apple.quarantine /path/to/app.app

For example, if you downloaded MyApp.app to your Downloads folder:

xattr -d com.apple.quarantine ~/Downloads/MyApp.app

The reason this step works is because you're deleting the metadata that tells Gatekeeper the app came from the internet. Once the flag is gone, the app behaves like any other local file. You can verify it's been removed by running xattr ~/Downloads/MyApp.app—if it returns nothing, you're clear.

One caveat: don't strip the quarantine flag from apps you don't trust. You're bypassing a security check. Only do this for apps you're fairly certain are safe.

Cause #2: The app is genuinely damaged or incomplete

Sometimes the error message says “The application can’t be opened because it is damaged.” That's not always about security. It can mean the downloaded file is incomplete or corrupted—maybe the download dropped a few bytes, or you're on a flaky Wi-Fi connection and the browser didn't warn you.

This happens a lot with older apps downloaded from third-party mirrors, or when you've used a download manager that didn't resume correctly. The result is a .dmg that mounts fine but contains an app that's missing part of its executable.

What you should do:

  • Delete the downloaded file completely. Don't just move it to the Trash—empty the Trash too.
  • Re-download it from the official source. If you're on a Mac with Apple Silicon, make sure you grab the arm64 version, not the x86_64 one.
  • Check the file size against the site's listed size. If it's a few KB off, that's your signal something went wrong.

Another angle: the app might be old and not 64-bit. Starting with Catalina, macOS only runs 64-bit apps. If you're trying to open a 32-bit app from 2011, it won't launch, and the error message can look the same. You can check an app's architecture by running lipo -info /path/to/app/Contents/MacOS/binary in Terminal. If it says “no architecture specified” or mentions i386, you're out of luck.

Cause #3: Permissions or ownership are messed up

The third cause is less common but still pops up, especially after you've copied an app from another Mac or an external drive. The file permissions might be wrong—the app might be owned by a user that doesn't exist on your system, or the execute bit isn't set.

The error message in this case is often the same generic “The application can’t be opened,” but sometimes you'll see “You don't have permission to open the application” instead.

Here's how to fix it:

chmod -R u+rwX /path/to/app.app
chown -R $(whoami) /path/to/app.app

The reason this works is that the chmod command sets read/write/execute permissions for your user on every file inside the app bundle, and chown changes ownership to your current user. Without execute permission, macOS can't run the binary, even if everything else is fine.

This happens a lot after you've used rsync or cp to move an app from a Time Machine backup. The files arrive with the original owner's UID, which doesn't match yours.

If you want to avoid Terminal, you can also go to the app's folder, select it, and press Cmd+I to Get Info. At the bottom, expand “Sharing & Permissions” and make sure your username has Read & Write. That's the GUI way, but it's slower and doesn't always propagate to subfiles.

Quick-reference summary

CauseSymptomFix
Gatekeeper quarantine flag“can’t be opened” on first launch, no “damaged” messageRight-click → Open, or xattr -d com.apple.quarantine
Corrupt or incomplete download“damaged” or unexpected crash on launchDelete and re-download, verify file size
Permissions/ownership“You don’t have permission” or silent failurechmod -R u+rwX and chown -R $(whoami)

That's the whole story. Start with the right-click trick—it's the fastest, and it's the one you'll use most often. If that fails, move to the quarantine flag, then check for corruption, then permissions. In my experience, those three cover 95% of “can’t be opened” errors you'll ever see on macOS.

Related Errors in macOS Errors
-1008F Fix macOS Error -1008F: Unsupported App or Corrupt Download Fix com.apple.launchd.peruser Crash Loop on macOS Fix com.apple.launchd.peruser Error Crash Loop on macOS Mac Finder crash on ejecting external SSD on Ventura 13.3

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.