GEMS v.3.11.0 for Macos cannot be installed

[apgysi]

---

📦 Affected Component

• [x ] GEM-Selektor GUI
• GEM-Standalone
• GEMSFITS
• Other (please specify):

---

💻 System Information

• Operating System: Mac OS Sequoia 15.7.3
• GEMS Version: 3.11.0
• Install Method: installer
• Compiler (if built from source): N/A

---

🧪 Issue Description

installer seems broken, error message: "gem-selektor" is damaged and can't be opened

Expected Behavior:

GEMS should install and open

Observed Behavior:

see attached screenshot, gems cannot be opened

---

📋 Steps to Reproduce

1. Go to '...

'
2. Click on '...'
3. Run '...'
4. See error

---

📄 Relevant Files / Logs / Screenshots

• Attach input files (.gems, .json, .tdb, etc.)
• Include error logs or screenshots if applicable

---

💡 Additional Context

v. 3.9.6 .dmg and 3.10.1 file works for installation on Mac.

🙏 Thank you!

Thank you for taking the time to report this issue and help improve the GEMS platform.

[sdmytrievs]

Looks like the problem is the difference between macOS-13 (osx-64) and macos-latest (osx-arm64).
@gdmiron , what do you think about the operating system requirements for the GEMSGUI application?
macOS-13 could be deprecated.
https://docs.github.com/en/actions/reference/runners/github-hosted-runners

[gdmiron]

Is this not related to intel support on Mac? We can have both from intel and arm for mac until these are supported in CI.

[gdmiron]

@apgysi did you try the zip version GEMS3.11.0? Update, I checked and it does not work, it says you can't use GEMS with this OS version. We will fix this and make release that works also with old mac intel version.

[gdmiron]

@apgysi please test this https://github.com/gemshub/GEMSGUI/actions/workflows/deploy-macos-intel.yml (click on latest and then bottom of the page you should have download link to the test build)

[apgysi]

@apgysi did you try the zip version GEMS3.11.0? Update, I checked and it does not work, it says you can't use GEMS with this OS version. We will fix this and make release that works also with old mac intel version.

Just to clarify I don't use an older intel model. All Macs are now on M chips to my knowledge I would support those chips as priority. I have an Apple M4 chip on MacBook Air.

[apgysi]

@apgysi please test this https://github.com/gemshub/GEMSGUI/actions/workflows/deploy-macos-intel.yml (click on latest and then bottom of the page you should have download link to the test build)

this doesn't work on M chips.

[dimitrikulik]

I have the same issue as Alex with GEM-Selektor v.3.11.0 on MacBook Pro M3 with Rosetta 2 emulator for Intel exes.
However, the previous v. 3.10.2 works fine. Perhaps, one should build v.3.11.0 in the same way (using the same toolset) as used for building v.3.10.2 for MacOS. So far, this would be an intel exec, running on Rosetta 2 in ARM Macs.

[dimitrikulik]

As far as I know, it is possible to build GEMS3K (and probably xGEMS) natively on Mac ARM (with M processor). However, to build GEM-Selektor natively, one first has to rebuild Qt on ARM natively (please, check what Qt.io says about that).

[gdmiron]

@dimitrikulik please try the latest release:

https://github.com/gemshub/GEMSGUI/releases/tag/v3.11.1

GEMS3K and xgems are already available natively on arm through conda.

[gdmiron]

@sdmytrievs is the deploy MacOS not made to build for arm MacOS already?

https://doc.qt.io/qt-6/macos.html

[dimitrikulik]

I got the same problem (reported by Alex) also with v.3.11.1, then asked Google. the answer was to go in terminal and execute the following commands:
cd ~
sudo xattr -rd com.apple.quarantine /Users/kulik/GEMS3_11_1/gem-selektor.app
Password:
Then start gem-selektor.app as usual or via rungems3.sh. In both cases, I get another error message:
"gem-selektor quit unexpectedly."
A good news is that the program runs, MacOS just puts it into quaranine. The bad news is that it breaks.
This can be related to the following changes:

• gemsgui starts by default in -c mode, always checking for changes in projects and database folder
  Actually, 7 or 8 years ago, because of similar issues, I've made it in MacOS always start in -d mode. So, I don't get it quite right why it has been changed to -c mode now (with commands in rungems.sh that use -d, it doesn't start either).

[gdmiron]

The issue will hopefully be resolved in the next release. The -c mode was set becuase I got many complaints for the users that the database folder and project folder is not refreshed automatically. I asked for a mode that these folders are always read for changes by gems independent form where is started. This was suggested by @sdmytrievs .

v3. 11.0 does not have this - c by default and still fails in MacOS
v3. 11.1 sohuld have the old way of making the package with the difference that it uses the MacOS latest as environment to build.

Does the Intel version work with Rosetta? see MacOS-Intel in release.

On other note, the Intel package for 3.11.1 is working on your old Mac with - c default and MacOS 26

[gdmiron]

What is interesting, if the Intel package for 3.11.1 works on Intel MacOS 26, why it doesn't work with Rosetta?

In principle the new MacOS package without Intel in the name should build natively for arm.

[dimitrikulik]

Just tried macos-GEMS3.11.1-intel.dmg from release on my MacBook Pro M3 with MacOS 26.3 and Rosetta-2.
It works! Just had to go to Settings Privacy and Security and allow to start it anyway.
This effectively means that releases for "non-intel" MacOS are actually a blend of intel and ARM code.
So, let us so far use on Mac only "intel" variant, also on M3 or M4 Macs.

[gdmiron]

Great that it works. It means we still need to work on the native arm package.