[GaborLajos]

Summary

• Add LSMinimumSystemVersion set to 11.0 to the macOS app bundle Info.plist files for aarch64 and x86_64.
• Update the Cocoa launcher’s runtime macOS version check.

The launcher check uses NSProcessInfo.operatingSystemVersion, which was introduced in macOS 10.10. It therefore cannot reliably display an error on older systems. Declaring the minimum version in the app bundle lets macOS Launch Services enforce the requirement when launching the app.

Notes

This change is targeted at the macOS launcher behaviour and does not alter the other platform implementations.

[github-actions]

Test Results

  234 files  +   78    234 suites  +78   47m 19s ⏱️ + 13m 45s
2 231 tests ±    0  2 182 ✅ ±    0   49 💤 ± 0  0 ❌ ±0 
6 456 runs  +2 152  6 343 ✅ +2 114  113 💤 +38  0 ❌ ±0 

Results for commit 51cd061. ± Comparison against base commit 5608d5d.

♻️ This comment has been updated with latest results.

[Copilot]

🔵 Needs a closer look

The app declares macOS 10.10 as its minimum despite the native launcher targeting macOS 11, allowing startup attempts on unsupported Intel Macs.

No open issues 🎉

What changed in this PR

This PR moves the macOS launcher's minimum-version check into app bundle metadata so Launch Services can enforce it without relying on an API unavailable on older systems.

Changes:

• Declare LSMinimumSystemVersion as 10.10 in both macOS app bundles.
• Remove the Cocoa launcher’s runtime version check, leaving other platforms unchanged.

File	Description
features/​org.eclipse.equinox.executable.feature/​library/​cocoa/​eclipseCocoaMain.c	Remove the runtime macOS version check.
features/​org.eclipse.equinox.executable.feature/​bin/​cocoa/​macosx/​x86_64/​Eclipse.app/​Contents/​Info.plist	Declare the minimum macOS version for Intel.
features/​org.eclipse.equinox.executable.feature/​bin/​cocoa/​macosx/​aarch64/​Eclipse.app/​Contents/​Info.plist	Declare the minimum macOS version for Apple Silicon.

_{Review effort: Balanced}

[HannesWell]

The app declares macOS 10.10 as its minimum despite the native launcher targeting macOS 11, allowing startup attempts on unsupported Intel Macs.

That's correct. It was changed in

• Switch to macOS sdk version 11 on intel architectures #474

@GaborLajos can you please fix that inconsistency and change the value to 11?

Otherwise this change looks good to me and I think it's far superior to have proper OS level metadata defined than checking the OS version in native code. Thank you.

@Phillipus do you want to check this?

[Phillipus]

That might be OK for Eclipse but an RCP app might have it's own Info.plist file (as we do), so the native check is still useful.

[HannesWell]

Understand.
Then I suggest to do both, since the metadata from the plist file can be considered by the OS and presented to the user.

And of course check for macOS 11 in all places.

[GaborLajos]

If I understand correctly, this PR modifies the Equinox launcher's default Info.plist, so it should also benefit RCP applications using the standard launcher bundle. Products providing their own Info.plist would remain free to specify a different minimum OS version.

I can see the benefit of a runtime check for version 11. I originally removed the previous check because it was enforcing 10.10, and that check itself relies on APIs that are not available on pre-10.10 systems. However, if an RCP application defines a higher minimum version in its own Info.plist, the launcher can no longer be the authoritative source of that requirement.

In any case, I am happy to follow whichever approach you consider most appropriate.

Thanks for your review.

[HannesWell]

I originally removed the previous check because it was enforcing 10.10, and that check itself relies on APIs that are not available on pre-10.10 systems. However, if an RCP application defines a higher minimum version in its own Info.plist, the launcher can no longer be the authoritative source of that requirement.

Yes, there are always multiple scenarios to consider, but the current should give everyone the best.
The only drawback is that we now have to maintain the minimal required macOS version in four instead of only two places (from which one was already forgotten the last time it changed). But we'll handle that.

Given that 10.10 is now over 10 years old, I think we can consider it save to use API from it. The pinfo should prevent using anything lower before. And custom apps should follow that.

Thank you for this enhancement and also Thanks to Phil for making it better.