[macOS] Umbrella: Compatibility with macOS 26 SDK

[HeikoKlare]

Background

macOS 26 (Tahoe) introduces behavioral and visual changes when an application binary is linked against the macOS 26 SDK. macOS enforces these changes based on the SDK version embedded in the process launcher binary (i.e., the eclipse binary from the Equinox launcher or the java binary of the JVM used to launch the application). The SDK versions of SWT's own native libraries do not determine this behavior.

This matters for Eclipse because:

• Eclipse products (e.g., the Eclipse IDE) are started via the Equinox launcher (eclipse binary). The macOS SDK version embedded in that binary determines the runtime appearance and behavior.
• Runtime Eclipse instances launched from within the IDE (e.g., for plug-in development) are started via the JVM (java binary). Most JVM distributions (Temurin, official OpenJDK) embed macOS SDK 14 or 15, so runtime instances are unaffected.

The issues described here were first observed when the Jenkins CI agent used to build the Equinox binaries was upgraded from macOS 11 to macOS 26, causing the Equinox launcher to embed the macOS 26 SDK:

• Trigger PR: [I/Y-Tests] Update to new macOS computers in RelEng Jenkins eclipse.platform.releng.aggregator#3739
• Temporary fix (revert to macOS 15 build agent): [Build] Build macOS native launcher binaries on macOS 15 agents eclipse-equinox/equinox#1273

The temporary fix restored the previous macOS 15 SDK for the Equinox launcher binaries. The goal of this umbrella issue is to track the work required to make Eclipse fully compatible with the macOS 26 SDK, so that we can eventually build against it intentionally and with confidence.

Note: The issues were initially only observed on the aarch64 (Apple Silicon) build, because only the aarch64 CI agent was upgraded to macOS 26. The x86_64 build continued to use a macOS 15 SDK and was unaffected.

---

How to Reproduce (Without Equinox Binaries)

It is not necessary to use Equinox binaries built with the macOS 26 SDK to reproduce these issues. Any JVM binary built against the macOS 26 SDK will trigger the same behavior when used to launch an Eclipse instance from the IDE.

Confirmed trigger: The Homebrew distribution of OpenJDK 25 is built against macOS SDK 26.2 (verified via otool -l):

% otool -l /opt/homebrew/Cellar/openjdk/25.0.2/.../java | grep -A 8 'Load command 10'
  minos 11.0
    sdk 26.2

Compare this to Temurin 23 (sdk 14.0) or Temurin 21 (sdk 14.4), which do not trigger the issues.

Steps:

1. Install Homebrew OpenJDK 25: brew install openjdk@25
2. Launch a runtime Eclipse instance from your IDE using this JDK
3. The issues described below should be reproducible

See also: eclipse-platform/eclipse.platform.ui#3884 (comment)

---

Known Issues

1. Window Title Left-Alignment

Issue: eclipse-platform/eclipse.platform.ui#3884
Severity: Cosmetic
Status: Open — intentional Apple change, no action likely needed

macOS 26 left-aligns window title bar text by default for all applications compiled against the macOS 26 SDK. This matches native macOS 26 applications (e.g., TextEdit).

macOS 15 SDK (current)	macOS 26 SDK
Titles centered	Titles left-aligned

This appears to be an intentional macOS 26 design decision (see community discussion). It is likely acceptable to leave this as-is. However, it should be verified how the alignment appears when targeting a macOS 26 SDK but running on older macOS versions.

---

2. Widget Border and Background Color Changes

Issue: eclipse-platform/eclipse.platform.ui#3885
Severity: Usability — widgets are hard to identify and interact with
Status: Open — needs SWT adaptation

macOS 26 changes default background colors for several UI surfaces. In particular, backgrounds that were previously distinct gray tones are now unified white, which removes implicit visual borders between controls and their containers.

Observed in Preferences dialog:

• In light theme: Text field borders are barely visible; the filter field blends into its background
• In dark theme: Dropdowns have background/border color mismatches; corners of the filter field mix square and rounded edges

The root cause is that the background color semantics for dialog panels changed between macOS 15 and macOS 26:

What needs to be done: The SWT Cocoa implementation needs to adapt to the new background color APIs and ensure that text fields, combo boxes, and other controls have proper explicit borders or correct background colors under the macOS 26 look and feel.

---

3. Open Resource / Open Type Dialog Not Updating (Functional Regression)

Issue: #3230
Severity: High — core Eclipse functionality broken
Status: Open — root cause identified, fix in progress

When typing into the filter field of the Open Resource or Open Type dialogs, the results list does not update. The issue is only reproducible in dark theme. In light theme, or after clicking/tabbing into the results list, the content appears correctly.

Root cause: This is a symptom of the infinite Text widget redraw loop described in issue #4 below. The UI event queue becomes saturated with redraw events, preventing asyncExec-scheduled updates (such as list filtering) from executing.

---

4. Infinite Text Widget Redraw Loop (SWT Bug — Root Cause of #3)

Issue: eclipse-platform/eclipse.platform.ui#3920
Severity: High — causes 25–100% CPU usage and UI freeze
Status: Open — fix under investigation in #3260

The SWT Text widget's Cocoa implementation contains a drawing loop that becomes infinite when the process is launched with a macOS 26 SDK binary.

Symptoms:

• Opening Preferences and typing in the filter field causes 25–100% CPU core usage
• The tree does not update to show filtered results
• Resizing the dialog or removing focus from the filter field works around it
• Also reproducible in Error Log view, History view, and any Text widget with SWT.SEARCH | SWT.ICON_CANCEL and a custom background color set

Expected:

Actual (macOS 26 SDK):

Root cause (technical):

In Text.drawInteriorWithFrame_inView_searchfield(), a call to NSControl.stringValue() is made. Under the macOS 26 SDK, this call internally triggers setNeedsDisplay(), which schedules another redraw. This creates an infinite loop:

Text.drawRect()
  → Display.windowProc()
    → Text.drawInteriorWithFrame_inView_searchfield()
      → NSControl.stringValue()   // triggers setNeedsDisplay() under macOS 26 SDK
        → Text.drawRect()         // infinite recursion

The loop only fires when:

• The Text widget has a custom background color set (set by dark theme theming asynchronously)
• The process launcher was compiled against macOS 26 SDK (confirmed: Homebrew OpenJDK 25 with sdk 26.2; not triggered by Temurin 23 with sdk 14.0)

Visual detail of the changed drawing behavior:

The macOS 26 SDK renders focus selection on the Text widget with more rounded corners than macOS 15:

Old SDK	New SDK (macOS 26)

What needs to be done: The drawInteriorWithFrame_inView_searchfield method in the SWT Cocoa Text widget implementation needs to be adapted to avoid triggering setNeedsDisplay() from within a draw call, and/or to correctly handle the updated focus selection rendering of macOS 26.

---

Approach and Plan

The proposed approach is:

1. Keep the macOS 15 SDK for Equinox launcher binaries (already done temporarily via [Build] Build macOS native launcher binaries on macOS 15 agents eclipse-equinox/equinox#1273) until all known issues are resolved and verified.

2. Fix the known issues in SWT's Cocoa implementation listed above, specifically:

   • The infinite Text widget redraw loop (highest priority — causes CPU freeze and functional regressions)
   • Widget border and background color adaptation for macOS 26 look and feel

3. Verify fixes using Homebrew OpenJDK 25 as a test launcher (built against macOS 26.2 SDK), which reproduces the issues without requiring a special Equinox build.

4. Discuss when to switch the Equinox launcher build to macOS 26 SDK once the above is complete and verified.

---

Related Issues and PRs

Reference	Description
eclipse-platform/eclipse.platform.releng.aggregator#3739	CI agent upgraded to macOS 26 — triggered the issues
eclipse-equinox/equinox#1273	Temporary fix: revert Equinox binaries to macOS 15 SDK
eclipse-platform/eclipse.platform.ui#3884	Window title left-alignment
eclipse-platform/eclipse.platform.ui#3885	Widget border/background color changes
#3230	Open Resource/Type dialog not updating
eclipse-platform/eclipse.platform.ui#3920	Infinite Text widget redraw — root cause
#3260	Fix attempt for infinite Text redraw

[Phillipus]

Thanks for opening this issue.

I wonder it it's possible to get access to a JDK 21/25 that has been compiled against macOS 26 that isn't the Homebrew version? I for one don't want to install Homebrew. Perhaps someone who has it could zip it up and post it somewhere, or does anyone know of a bundle?

[Phillipus]

Switch the Equinox launcher build to macOS 26 SDK once the above is complete and verified.

I have some doubts about this...for now. If this is done there will be a mismatch between running Eclipse or an RCP app with the Equinox launcher and 90% of current versions of Java.

[HeikoKlare]

Switch the Equinox launcher build to macOS 26 SDK once the above is complete and verified.

I have some doubts about this...for now. If this is done there will be a mismatch between the running Eclipse with the Equinox launcher and 90% of current versions of Java.

I enhanced the issue description stating that we discuss when to that switch once the prerequisites are fulfilled.

The "incompatibility" of JDK builds and Equinox launcher is probably unsolvable. There is already an ongoing discussion about that:

• Detect incompatible libraries #3264

Probably, the only "good" solution would be to adopt Apple's policy and basically only support the latest OS version and see everything else as a legacy burden that we may not support. Not that I want to propose to do this, but that's basically the direct consequence of macOS and the SDK changes.