Bundle the app for MacOS

[Tyrrrz]

Version

v2.43.3

Flavor

GUI (Graphical User Interface), CLI (Command-Line Interface)

Platform

OSX

Export format

No response

Steps to reproduce

Explained below

Details

If you try to run the app after downloading, it won't launch due to macOS's security policies. You need to manually bypass the app signing check to work around this issue: #1234 (reply in thread)

Packaging the app as .app bundle may help resolve this issue. Ideally, we'd want to integrate the bundling stage in the existing CI process.

Checklist

• I have looked through existing issues to make sure that this bug has not been reported before
• I have provided a descriptive title for this issue
• I have made sure that this bug is reproducible on the latest version of the application
• I have provided all the information needed to reproduce this bug as efficiently as possible
• I have sponsored this project
• I have not read any of the above and just checked all the boxes to submit the issue

[toadchild]

Commenting from the other thread, since I brought up the app bundle.

If you have an unsigned bundle, it is treated similarly to how Windows treats an unsigned .exe file. You have to right click -> open the first time in order to confirm that you want to run unsigned code, but after that it remembers the app and won't prompt you again.

I haven't done mac app stuff in a while, but iirc there's nothing magic about what xcode does when making a .app bundle. You just need the correct layout and an info.plist file that tells the OS how to set up the runtime.

https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19

[DannyDorito24]

Due to changes in Sequoia, it is likely this will no longer fix the issue, but it probably wouldn't have before either. The right click > open workaround now requires you to authenticate in settings (sometimes twice) to open the main process, and any child processes also have to be authenticated for (depending on how they are launched, I can't say I completely understand it). I've also heard rumors that some people are having their machines completely refuse to run unsigned code but I personally haven't seen this even on a completely stock machine straight out of the box, and people in the linked MacRumors thread call it out as fake.

Anyway, likely the only way to avoid the error is to sign the binary, which of course requires a developer license from apple. Even before Sequoia, executables being in a bundle don't magically make them run, they still have to be signed. For now, some detailed instructions on how to work around this issue would be good, which I could certainly make if nobody else has a Mac (I daily drive one). I personally have gatekeeper disabled but this is not a good idea for the average user as it's akin to turning off SmartScreen and UAC in windows. So for now, the annoying workaround in settings is the best it'll be.

In terms of the app bundle, while more user friendly for an applications folder, there would need to be some changes to how the app works. Applications on macOS are pretty static and use ~/Library/Application Support to store any changing data, which as far as I can tell doesn't happen now (but may not be needed? I haven't read through the code thoroughly).

All in all, I'm not sure it would accomplish anything, and macOS is pretty finicky with unsigned app bundles in general, especially if they're made through github actions in my experience, often claiming that the app is damaged, and there is no workaround for that (other than disabling gatekeeper).

[Tyrrrz]

Anyway, likely the only way to avoid the error is to sign the binary, which of course requires a developer license from apple. Even before Sequoia, executables being in a bundle don't magically make them run, they still have to be signed.

I see. I guess with a bundle at least you'd only need to manually allow the app once, at least of once per every file?

[DannyDorito24]

In the past that has been the case but with the restrictions now extending to dylibs, that may no longer be true. I can't easily test it without trying to put together the app myself, so maybe I'll try that. As toadchild mentioned, it's really just an info.plist and a basic folder structure. .app is basically just a styled folder, as are many packages on macOS.

There's also the issue of Microsoft's discontinuing of VS for macOS, instead directing users to VScode which does not have the same support as the old VS did... Thanks Microsoft. That's going to make things a bit more difficult.

[DannyDorito24]

With a bit of googling, it looks like publishing directly to an app bundle is annoying. However, I got it to launch by just moving files into place and creating app.plist manually. Cursed, but it works. Sadly it's only for one architecture at a time, but I suppose that's what it is now. I can't tell what gatekeeper is doing to it since it was made on my local machine, but I'll try it on another machine later.

[Tyrrrz]

However, I got it to launch by just moving files into place and creating app.plist manually.

Can't we also just do that as a way to "publish directly to an app bundle"? Or is there something else to it that we'd be missing?

[toadchild]

That had been my initial thought, yeah. Make a build rule that copies all the files into the directory structure and adds a very basic plist.

[Lewiscowles1986]

So I do see download for OSX arm64, however they contain a lot of dll files...

[DannyDorito24]

That’s unavoidable. There is no official app bundle yet (afaik) but even when there is one it’s still going to be .NET on macOS so DLLs are to be expected.

[DannyDorito24]

Can't we also just do that as a way to "publish directly to an app bundle"? Or is there something else to it that we'd be missing?

That should work, but I didn’t find a way to do that directly in the editors that exist on macOS. Not sure about VS on Windows. It should be super easy to script it though. Not sure what the Microsoft intended way to do it is, if there is one.