Posting on macOS: Fixing the “App Is Damaged” Error the Right Way

Posting (app) on macOS: The “App Is Damaged” Error That Wasn’t

I installed Posting (app) on a MacBook Pro M1 running macOS Sonoma 14.3 because I needed a lightweight publishing client for drafting and pushing content without living inside a browser all day. Nothing fancy. Downloaded the latest macOS build, dragged it into Applications, double-clicked.

And macOS immediately slapped me with this:

“Posting is damaged and can’t be opened. You should move it to the Trash.”

That message is dramatic. It sounds like the binary fell apart on the way down from the server. In reality, nine times out of ten, it’s Gatekeeper doing its thing.

Apple documents this behavior here:
https://support.apple.com/en-us/HT202491

The wording “damaged” usually means the system doesn’t like the code signature or the notarization state. It’s not corruption. It’s trust.

Here’s how I worked through it — including the two things that didn’t fix it.

---

First Attempt: Redownload and Reinstall

My instinct was simple: maybe the download actually was broken.

So I deleted the app, cleared the browser cache, downloaded the build again from the developer’s site (Posting’s official page is here: https://posting.sh), moved it to /Applications, and tried launching it.

Same error.

That ruled out corruption.

I also checked whether there was a Mac App Store version to avoid this entirely (App Store builds are always signed and sandboxed). A quick search here showed nothing official:
https://apps.apple.com/us/search?term=Posting

So this was going to be a direct-build situation.

---

Second Attempt: Right-Click → Open

Sometimes macOS just needs the manual override. You right-click, choose Open, confirm, and it whitelists the app.

Did that.

Still got the “damaged” message.

At this point I knew it wasn’t Finder-level permission drama. It was quarantine metadata combined with a non-notarized binary.

Apple’s notarization process is explained in detail here:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

If a developer doesn’t notarize the build (common with smaller utilities), macOS marks it as suspicious when downloaded via a browser.

---

What Actually Worked

I opened Terminal and checked the extended attributes:

xattr Posting.app

Sure enough: com.apple.quarantine.

So I removed it:

xattr -dr com.apple.quarantine /Applications/Posting.app

Then I tried launching again.

This time it opened instantly. No warning. No crash. Just the app window.

That’s it.

The system wasn’t telling me the truth when it said “damaged.” It was saying “I don’t trust this.”

Once the quarantine flag was gone, the OS stopped interfering.

---

The Subtle Permission Glitch

There was one more small hiccup after launch.

The first time I tried exporting a draft, the save dialog appeared, but nothing was written to disk. No error pop-up. Just… nothing.

That turned out to be a folder permission issue in ~/Documents caused by an earlier test where I had created a subfolder using sudo (don’t ask).

Quick fix:

sudo chown -R $(whoami) ~/Documents/YourFolderName

After that, exports worked fine.

This wasn’t Posting’s fault. It was my file ownership mess. But because it happened right after fixing Gatekeeper, it looked like the app was unstable. It wasn’t.

---

Why macOS Behaves This Way

Modern macOS attaches a quarantine attribute to anything downloaded from the internet. If the code isn’t notarized or signed the way Apple expects, it blocks execution.

It’s not random.

If you’re browsing mac OS software resources like this page I bookmarked for reference on macOS systems behavior and this specific build —
https://smohamad.com/office-and-productivity/33636-posting.html —
you’ll notice this pattern repeats across smaller utilities that distribute outside the App Store.

The OS assumes “downloaded = potentially unsafe.” That’s reasonable. It just produces scary wording.

---

What I Didn’t Do

I did not disable Gatekeeper globally with:

sudo spctl --master-disable

You can, but it weakens system-wide protection. Removing quarantine for one specific build is precise and reversible. Disabling Gatekeeper entirely is lazy.

Also, I didn’t move the app out of Applications or run it from Downloads long-term. Some builds behave unpredictably if launched from random folders.

---

If I Knew Then What I Know Now

If I had to set this up again on a fresh Sonoma install, I’d do it in this order:

• Download the correct macOS build.
• Move it directly to /Applications.
• Remove quarantine with xattr.
• Avoid using sudo in user folders unless absolutely necessary.
• Launch normally.

That’s it. Total time: five minutes instead of forty.

The tool itself runs perfectly fine on Apple Silicon. No Rosetta translation needed. CPU usage stays low, memory footprint is modest. The only friction was macOS security layers enforcing policy.

And honestly, that’s expected.

The takeaway isn’t that the app is broken. It’s that macOS defaults to distrust for unsigned downloads. Once you understand that model, these errors stop feeling mysterious.

You’re not fixing something “damaged.” You’re telling your system, calmly and deliberately: I trust this binary.

After that, everything just works.