[Bug] Apple Silicon version crashes on opening

[tokamac]

System

I paste here the information copied from the INTEL version (same build number), as the Apple Silicon version cannot be opened:

UVtools v4.3.2 X64
Operative system: Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:16:51 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T8103 X64
Processor: Apple M1
Processor cores: 8
Memory RAM: 3.91 / 5.00 GB
Runtime: osx.14-x64
Framework: .NET 6.0.29
AvaloniaUI: 11.0.10
OpenCV: 4.8.1

Sreens, resolution, working area, usable area:
1: 2240 x 1260 @ 100% (Primary)
    WA: 2240 x 1177    UA: 2240 x 1177

Path:       /private/var/folders/mm/pzbcq3sx7xncs5r7wbyscbvr0000gn/T/AppTranslocation/B903C0E0-7425-4A38-BC2C-047DC22EF196/d/UVtools.app/Contents/MacOS/
Executable: /private/var/folders/mm/pzbcq3sx7xncs5r7wbyscbvr0000gn/T/AppTranslocation/B903C0E0-7425-4A38-BC2C-047DC22EF196/d/UVtools.app/Contents/MacOS/UVtools
Loaded file: UVtools_demo_file.sl1s [Version: 0] [Class: SL1File]

Printer and Slicer

Irrelevant

Description of the bug

On an iMac M1 with latest macOS Sonoma 14.5, the native Apple Silicon version of UVtools (version 4.3.2) crashes directly and systematically on opening before any window can appear.

How to reproduce

The Intel version works fine on the same machine and OS (with a performance hit, obviously) in Rosetta 2.

Files

[github-actions[bot]]

This is your first time submitting an issue with UVtools 🥳Please review your issue and ensure that the submit template was followed, the information is complete, and not related to any other open issue. It will be reviewed shortly. Debugging is very important and make the program better. Thanks for contributing and making the software better! 🙌

[sn4k3]

Have you installed UVtools via auto install script?

[tokamac]

No, why would I do that? I simply went to the Release v4.3.2 page, downloaded UVtools_osx-arm64_v4.3.2.zip then extracted the Zip archive, which gave UVtools.app that I moved to my /Applications/ folder. Same when I tested successfully the osx-x64 version afterward.

BTW, it's a bit surprising to distribute macOS apps as a Zip archive. The usual way is to securely encapsulate them within a DMG disk image.

[sn4k3]

That won't work, as macOS now blocks not signed / untrusted app. Use auto installer to bypass that.

BTW, it's a bit surprising to distribute macOS apps as a Zip archive. The usual way is to securely encapsulate them within a DMG disk image.

DMG is a nightmare for auto updater, with ZIP is much easier to handle. Also there are still users that don't know how to install via DMG and running directly from dmg. When I was reading about DMG vs ZIP the most dev's was toward ZIP due this two problems.

[tokamac]

You're mistaken, this has nothing to do with Gatekeeper. The error message pictured in my first post above is displayed just before the usual macOS warning and does not trigger any "Open Anyway" button in the Privacy & Security settings. By the way, my security settings are set to open apps from "anywhere" thanks to sudo spctl --master-disable so I can perfectly install and run unsigned apps. Also, an unsigned app is often welcomed by the "this app is damaged, would you want to trash it" type message (yet usually resolved with an xattr command in the cli): nothing of the sort here. Finally, if your hypothesis was right, the Intel app downloaded the same way would not open either.

I get your point about the path of least effort favouring ZIP over DMG. It's just that "most devs" is just false in my experience. When I said it was unusual, I meant it. "A few devs" would be correct. However, if the Zip archive is unrelated to the issue described, it's really not important.

[tokamac]

Use auto installer to bypass that.

It worked! Thank you very much for having provided the solution. I close the issue.

[sn4k3]

See... Never discard a troubleshoot option just because you think that's not the case, more when the action to perform is fast and easy. Most of the times dev's know about it own stuff. And of course others came with exact same issue as you, a search on github will reveal many open tickets about this. This is a problem since "recent" macOS and all arm64 versions. You can read more about here.

About ZIP, when you put both in a scale, zip wins: Can be open, extracted, created easy from any device (windows/macos/linux). The same is not true with DMG. And UVtools releases are compiled/made in Windows and Linux. it never touch macOS.

Most posts I read about the topic most complained about macOS dmg distribution which is OLD and require user interaction to make it right. I would hate Windows if I had apps distributed under ISO and had to mount ISO to extract/install app. ZIP isn't fool-proof either but at least prevent user from run app from a mounted disk, a double click will extract app to disk which can be run from there, is then up to user to move it or not, as UVtools is portable the install location is not important. A "much better" package is the .pkg (If I'm not mistaken in extension name) which runs an installer and do things properly (fool-proof). You can read much of this conversations on reddit over distributing DMG vs ZIP for macOS. As a security factor all present same risk, all can be installed, extracted in a macOS so doesn't matter much.

For me just the fact I can bundle the app under any system, revise it without big effort is a big win to me. As user "must" use auto installer script it also doesn't matter as the process runs under the hood and keep no left-overs.

Some users also ask: If manual release is unusable why it exists? A: Because UVtools need it for auto-update/install. And again, auto-update from zip extract and merge is much more easier than DMG which require painful bash scripts and process calls to mount/extract/unmount a img, higher risk of going wrong.

Also there is no point in having dmg + zip. So I opt for the simplest.