The application "Finder" does not have permission to open "(null)“ error message in macOS 15.1 when trying to open unsigned application

Is this an application that you’re creating? Or are you seeing this with apps created by other third-party developers?

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

It is a macOS application that we develop.

It's based on the Eclipse RCP framework and is not signed.

Well, there’s two problems here:

• The fact that the app won’t launch.

• The fact that the error includes (null).

The latter is clearly a bug in macOS, and I encourage you to file it as such. Please post your bug number, just for the record.

Having said that, there’s probably something about your built app that’s triggering this. As with any third-party tooling, you can approach this in one of two ways:

• You can escalate this via the support channel for your tooling.

• You can take on this issue yourself.

For that last point, my advice in this case is:

1 Build a simple app with Xcode.

1. Build a simple app with your tools.

2. Verify that the first doesn’t have this problem and the second does.

   Note If you see the problem with your Xcode version, I’d love to hear about it because that’s something I can help you with.

3. Compare how the bundles are assembled. It’s likely that there’s something wonky with the Info.plist the failing app.

As to what’s causing the app to fail to launch, there are a variety of potential reasons for that. I talk about a bunch of them in Resolving Trusted Execution Problems. The best first step is to run syspolicy_check against your app.

However, lemme clarify some specific points…

macOS won’t run unsigned Apple silicon code. If the code is truly unsigned, this issue is not a surprise (unless you happen to be buildding Intel code). In most cases, if someone says they have unsigned Apple silicon code, they actually have ad hoc signed code. Cross-platform tools typically rely on a process calling linker signing to generate that ad hoc signature.

macOS can run ad hoc signed (or unsigned, on Intel) code. If the code is quarantined then you need to bypass Gatekeeper, but there’s a documented process for doing that.

You can test this for yourself with Xcode. If you create a project from the macOS > App template and thes select Sign to Run Locally in Signing & Capabilities, the resulting app is ad hoc signed.

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

Our application is a pure Intel application. So I guess the following applies to our application:

"...macOS can run ad hoc signed (or unsigned, on Intel) code. If the code is quarantined then you need to bypass Gatekeeper, but there’s a documented process for doing that..."

Not sure how to interpret "...or unsigned, on Intel..." does that mean that a pure unsigned Intel application should be able to run on both Intel and Apple Sillicon Macs ? Or does it mean that it's only on Intel based Macs that a pure unsigned Intel application can be launched ?

All of the above of course using the "...documented process..." for launching the application.

We have been able to create a workaround for launching our application under macOS 15.1.

The workaround consists of the following steps:

1. Launch the app executable from the Terminal (the executable in the MacOS folder of the package).

2. Dismiss the alerts shown (click "Done")

3. In "System Settings" in "Privacy & Security" click the "Open Anyway"

4. Dismiss any alerts shown

5. Launch the app executable from the Terminal again (the executable in the MacOS folder of the package). Enter admin username & password to accept the app

This launches the app under macOS 15.1.

Launching it again requires the use of the terminal as in 1) above.

We have created a small Automatic app encapsulating the workflow above.

Obviously this is not ideal...seems that the issue is with the Finder ?

Hi, I am having this exact issue when I try to open MATLAB.

I just updated to macOS 15.1 two days ago.

I tried accessing "Show Package Contents" -> "Contents" -> "MacOS", but clicking either file within just opens the terminal but still does not open MATLAB. What would be the next steps / workaround? Thanks!

The steps are:

1. Open the Terminal

2. Open the "App Package -> Contents -> MacOS -> <yourApp> in the finder (do not double click it)

3. Drag the <yourApp> executable to the Terminal window and press <enter>

4. Dialogs will appear, click "Done", don't select to move it to the trash

5. Open the "Privacy & Security" pane in the "Systems Settings...", scroll down and click the "Open Anyway" button in the little area that has appeared with the <yourApp>. Nothing happens

6. In the Terminal redo 2) -> 3) again, this should open your app (barring security dialogs appearing).

After that opening <yourApp> should be done like 2) -> 3). This time no dialogs should appear.

One question: we have gotten signing, notarisation and stapling working for our app in our CI pipeline. One thing though, on the build Macs we use a separate keychain file with the certs for signing etc. To get the separate keychain file into the keychain search list we use the security "-s" option to add it.

The problem is when we remove it. It feels very risky to reset the whole keychain search list just to remove one item from the list ? What we fear is that the removal operation might clear out the whole keychain search list if some kind of error happens.

Is there another more fail-safe way to remove entries from the keychain search list ?

Sorry I didn’t reply sooner. Due to issues at our end, I missed the updates on this thread )-:

Not sure how to interpret "...or unsigned, on Intel..."

Yeah, I was trying to be succinct and ended up being confusing )-: Let’s try a table instead.

Code                x86_64      arm64
----                ------      -----
unsigned            OK          -
ad hoc signed       OK          OK
‘properly’ signed   OK          OK

Note that this table refers to the code’s architecture. So, Rosetta on an Apple silicon Mac will run unsigned x86_64 code.

Our application is a pure Intel application.

You have a plan to bring that to Apple silicon, right? While we’ve not made any announcements about this, and I most definitely can’t predict the future, every previous time we’ve made a transition like this (68K, traditional Mac OS, 32-bit, PowerPC) we have eventually removed the compatibility shim.

seems that the issue is with the Finder ?

Well, the (null) in the error is clearly an issue with macOS and you should file it as such.

However, the fact that you have to run such a convoluted path to launch your app is something you can and should fix. Even if things were working perfectly, the user still has to jump through hoops to run unsigned code. Those hoops have got hoopier on macOS 15. See Safely open apps on your Mac from Apple Support.

If you signed and notarised your app, the user would be able to run it with minimum fuss.

I am having this exact issue when I try to open MATLAB.

This is something you should escalate via that product’s support channel. They’re in the best position to offer you definitive answers about how to run their product.

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