Finder shows warning "Apple could not verify file is free of malware" when setting my app as "Always open with"

Does your app explicitly advertise support for this file type in imported file types?

A recent change to macOS started requiring this explicit support.

Does your app explicitly advertise support for this file type in imported file types?

It does. I tried only with public.text as well as adding net.daringfireball.markdown (imported with an "equivalent type" with extension "md"), both didn't work.

This is definitely a macOS issue. Weirdly, Markdown is an executable format (because it can contain HTML) and thus gains extra scrutiny from Gatekeeper. I see this issue regularly on my main Mac, using BBEdit as my Markdown editor. At the user level you can get around this by opening the file from within the app (using File > Open) or removing quarantine from the Markdown doc.

As to why it happens, I used your question as an excuse to dig into this, but didn’t get very far. The issue is that, when I try to reproduce this on a VM, it doesn’t happen. Specifically:

1. On a macOS 15.5 VM, I installed Xcode 16.4.
2. I then installed BBEdit.
3. I created a Markdown document using vi.
4. In the Finder, I use File > Get Info on that doc to configure all Markdown docs to open in BBEdit.
5. I created another Markdown document using vi.
6. I quarantined that.
7. I double clicked it in the Finder. It opened in BBEdit without any kvetching from Gatekeeper.

Which is annoying because, if I could reproduce the problem, it’s likely I could learn more.

And it’s especially annoying because the same steps reproduce the problem on my main work Mac. But, in order to dig into this further, I need to record private data, and I won’t do that on my main Mac.

If you have any suggestions for what I’m missing in the above steps, I’d love to hear them.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

It does.

Well, for whatever reason, it doesn't seem to be working.

Your original description of the problem, 'choosing in the Finder "File > Open With > Other", then selecting my app and enabling "Always open with"' very specifically describes an app that doesn't advertise support for that file extension. If it did, then it would have shown up in the top-level list, not in "Other". And, by extension, you wouldn't be getting that malware warning either.

it would have shown up in the top-level list, not in "Other"

I didn't say that. The app does show up in the top-level list, as I mentioned: "When choosing my app in the "File > Open With" menu, the file opens just fine in my app".

And, by extension, you wouldn't be getting that malware warning either.

Unless it's a macOS issue as confirmed by a macOS engineer.

The issue is that, when I try to reproduce this on a VM, it doesn’t happen.

I tried using a VM (I haven't done so in a very long time), but when trying to download Xcode in it, the App Store kept telling me that my password was wrong, so I couldn't get further. While this is annoying, it isn't at all surprising to me: I wanted to transition from using separate partitions for each old macOS version (to test my apps) to using VMs instead, but quickly noticed that a VM may not reproduce all issues found on a "real" macOS installation, and vice-versa. So up to this day I create a new separate partition on an external drive for each new major macOS version.

While installing a new partition blocks you from using your Mac for some time, in my opinion it's worth having separate partitions to test things on, since in my experience a VM is not nearly as accurate as the real thing.

In alternative, could creating a new user be an alternative for you? I just remembered that Apple Care always asks to test things with a different user.

I didn't say that.

You were relaying what the end user told you. Obviously the end user's experience was more important than the fact that it worked on your machine.

From what I understand, this was a change made to macOS 15.4. I think that Apple changed this behaviour again in 15.6. I could reproduce the problem on a 15.4 VM, but I can't on 15.6, at least on my developer machine.

A VM is a good way to test software from an end-user's perspective. But I don't think you need to install Xcode on it to test this. Also, modern VMs on Apple Silicon do not have full access to Apple ID services. Some things work and some things don't.

But regardless, always download Xcode directly from the developer site. Never use the App Store.

You were relaying what the end user told you

I stated the opposite: "This is what happens for me". I only wrote that the user brought the issue to my attention.

Never use the App Store.

That sounds like a very generic statement and I don't see a reason why not. Would you like to elaborate?

I tried using a VM … but when trying to download Xcode in it, the App Store kept telling me that my password was wrong

The macOS VM hosting facilities on Apple silicon have some specific limitations. You can find the details in the various docs, articles, and forums threads referenced by Virtualization Resources. One of those is that you can’t sign in to the App Store )-:

Having said that, you don’t need to sign in to the App Store to use Xcode. Instead, download it from Developer > Downloads. Click Applications at the top right to see the latest Xcode, or More to go to the archive.

Honestly, installing Xcode this way is better than install it via the App Store. Somewhere I have a post that explains that… Oh, here it is.

Taking a step back, I’m not actually advocating that you build and run in a VM. Rather, it’s for testing, and specifically reproducible testing. The problem with testing on your development machine is that all of your development could have perturbed the state of the system in a way that undermines your tests. And even if you have real ‘victim’ machine to test on, the issue there is that it takes a long time to restore it to a clean state between each test.

Like with the iOS Simulator, you have to know what things to test in a VM and what things to test on real hardware. I’ve got a pretty good handle on that over the years, and I will say that VMs have much greater fidelity than the simulator.

But back to the issue in play here, previous I wrote:

4. In the Finder, I use File > Get Info on that doc to configure all Markdown docs to open in BBEdit.

This is where I was going wrong. The trick is to not configure all Markdown docs to open in BBEdit, but rather to override this specific doc. Once I did that, I was able to reproduce the problem on my VM.

Sadly, I’ve now run out of time to look into this further. I’ll try to pick it up next week.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Sadly, I’ve now run out of time to look into this further. I’ll try to pick it up next week.

Thanks, I'm looking forward to it. In the meantime, I've created FB19468486.

I've created FB19468486.

Thanks. I’ve updated your bug with my findings.

Originally I thought that this was related to Markdown, in that Markdown can contain HTML which can contain JavaScript and thus could be unsafe. However, I can reproduce this with a vanilla text document:

1. On macOS 15.6, install and run BBEdit.
2. Using Terminal, create a test.txt file.
3. Using Finder > File > Info > Open with, configure the file to open in BBEdit.
4. Quarantine the file.
5. Back in the Finder, double click the file.

You get a quarantine alert:

“test.txt” Not Opened

Apple could not verify "test.txt" is free of 
malware that may harm your Mac or 
compromise your privacy.

[Done] [[Move to Bin]]

Looking in the system log [1] I see this:

type: info
time: 2025-08-12 03:28:21.419703 -0700
process: XprotectService
subsystem: com.apple.xprotect
category: xprotect
message: SecAssessment results: {
    "assessment:authority" =     {
        LSDownloadRiskCategoryKey = LSRiskCategoryHasRedirectedBinding;
        "assessment:authority:flags" = 0;
        "assessment:authority:source" = "no usable signature";
    };
    "assessment:remote" = 1;
    "assessment:verdict" = 0;
} (null)

That LSRiskCategoryHasRedirectedBinding value is inserted by Launch Services because of the “Open with” binding in step 3. That causes Gatekeeper to be more ‘paranoid’, which eventually results in this alert.

So:

• The alert is most definitely a feature, triggered by the quarantined document having an “Open with” binding.
• Speaking personally, I wish this alert had an ‘Open Anyway’ button, but we’ll have to wait to see how your bug pans out.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Once I enabled the recording of private data.

Also, not sure if the original poster's app is sandboxed, but if your app is sandboxed then it looks like the situation is potentially worse:

It seems like if the reason the file was quarantined was that it was modified by a sandboxed app, Gatekeeper instead says that the file is damaged and can't be opened, and should be trashed (FB19623735) rather than the malware warning. In that feedback I list similar user-level steps:

1. Install Microsoft Word and Apple Pages from the App Store.
2. In Word, create a new document and save the .docx on your Desktop.
3. In Finder, right click > Get Info on the Word document.
4. Set Pages to open that specific Word document (do not set Pages to open all Word documents).
5. Double click the file to open it.

Then Gatekeeper tells you the file is damaged (both Word and Pages should be sandboxed apps since they're from the App Store). IMO that wording is even worse since it would imply to a typical user that the file is somehow corrupted... not that it might be dangerous. Then they might lose data if they try to mess with it or simply delete data that is perfectly fine. If an astute user notices that it happens after they set a file to open with your sandboxed app, it works once (say it starts out unquarantined), and then the system tells them it's damaged after any modifications are made, they're likely to blame your app, too, rather than the system's antimalware checks.

For reference this is the wording of that alert:

I get the security implications of having a file set to open with some arbitrary app (I mean, regardless of the file type, if it contains the contents of a script it could be dangerous if you open it with an unsandboxed script interpreter app installed on the system - if a sandboxed app could do that then that would be a fairly simple sandbox escape) but I hope a better balance exists... or at least that the wording is changed.

Also, not sure if the original poster's app is sandboxed, but if your app is sandboxed then it looks like the situation is potentially worse:

My app is sandboxed, and I'm not sure if I ever saw the wording you encountered. But that it indeed worse. In either case, the default action is to move the file to the bin.

You're absolutely right (and I failed to point out) that these alerts make the user think that something's wrong or suspicious with the app, and possibly uninstall it. Personally, since the file can be opened once with "File > Open With", I don't see a reason why opening it permanently with "File > Open With > Other" would need such a scary alert.

if your app is sandboxed then it looks like the situation is potentially worse:

Indeed. I’ve been testing with BBEdit and it is sandboxed, and so I hit this with some regularity on my main work Mac.

FB19623735

Thanks for filing that. It was gonna be my next ask (-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"