Unable to Open on M1 Mac
IdleEndeavor opened this issue · 14 comments
I use an M1 MacBook Air
It shows the error 'This Application can't be opened'
I've run it from the Downloads folder and by dragging it to Applications too.
Thanks for reporting. This is a duplicate of #28.
I'd like to help but I need more info about this: I'd be thankful if you could launch the app from a terminal, so we can see some debugging output.
This is the output when using the 'open' command to run the app from the Terminal
The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600000d819e0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}
Thank you for the follow-up.
I am not quite sure about what causes this issue. A quick search makes me think it might have something to do with code signing.
Since I am preparing for an important final exam in six weeks and a group trip to France after that, it might take some time and patience before I actually can get to this.
Feel free to try whatever might work by yourself though. I don't have a M1 Mac to test anyway.
My first approach would be to clone the repo, update all the dependencies, especially fyne and grab the new compiled binaries from the github build pipeline. You might need to resolve minor things if the build pipeline fails for some reason with updated dependencies.
there is a workaround working on my MacBook Pro 2019 w/ Intel Core i9
hope it works for you.
- extract zip file, there will be Anarchy-Droid.app.
- Open a Terminal to where the Anarchy-Droid.app exists, then:
cd Anarchy-Droid.app/
cd Contents/
cd MacOS/
chmod +x anarchy-droid
./anarchy-droid
- it will give the famous error, select cancel and open System Preferences -> Security & Privacy -> General. You will see the application below "All apps downloaded from" section. Allow your app there.
Thank you for the comment @gokhantuna.
If I am not mistaken, die M1 Mac has got an Arm processor which is a different architecture than the more common x86_64 processors. If the M1 Mac has no emulation layer for x86_64 binaries, I guess we will have to try and compile a version of Anarchy-Droid for Arm processors. Go should support this, but we will have to look into fyne and see what needs to be done to actually make the compilation work.
Setting up a github action for this should probably be the first thing to try. My free time is still scarce, but anyone can fork the repo and try to set up a github action similar to the normal MacOS one.
@gokhantuna's work-around confirmed working in macOS Monterey on an Intel Mac.
@amo13 you simply need to set the permission of the binary inside the app correctly to begin with .. ;)
I am not sure how I would implement this. The build pipeline simply calls fyne package which creates the macOS app. Is this maybe an issue with fyne?
Unfortunately, I have no Mac to debug and test...
I (and probably also others) would be grateful, if a M1/2 Mac-user could fork the repo and tinker a bit with the build process. I guess I'd update the project to the latest dependencies (especially fyne) as a first try.
@amo13 FYI, in v1.3.0 and below, the chmod +x permission on the binary inside the package was set correctly. If you didn't change anything then yes, very most likely changed in the automated build pipeline system.
Again, I'm on Intel, so this is not Apple Silicon specific.
Wish I could be of more help with this. But I bet other devs here on GH experienced the same issue, and the solution already exists and just has to be hunted down and applied :)
I've added a chmod +x to the MacOS build pipeline.
Hopefully the issue is now gone. Please reopen if not.
sorry to report, @amo13 , but the issue persists. Am on an Intel Mac. I double-checked the version number of the unzipped Anarchy-Droid.app - v.1.4.2.
After applying chmod +x to the binary, the app again runs as it should, so it's definitely still the same issue :(
Thank you for double-checking.
Apparently, github removes the executable bit on the binaries uploaded as release files. Still, after downloading and doing chmod +x and reuploading, it looks like the executable bit set inside the zipped macOS app is kept. Could you please try again with the zip in the latest release?
But I don't understand why the executable bit set inside the build pipeline is not kept...
👍 thanks Amaury, confirmed - your manually treated 1.4.2 zip launches and works fine (macOS Monterey, Intel).
Smells very much like a bug in the fyne system worth reporting to them.
Thanks!