Please disregard swapnali01's unhelpful answer which has nothing to do with the issue. All Intel macs supported DDC/CI, both with AMD and Intel GPUs (or even nVidia when that was available). The lack of DDC/CI support breaks several popular third party utilities (like MonitorControl or Lunar.fyi and others) designed to control the brightness and volume level of most modern external displays. It also breaks and cripples apps designed by display manufacturers specifically for Macs to control external displays (like BenQ's Display Pilot or LG's Screen Manager). For more information on the issue: https://github.com/kfix/ddcctl/issues/86 https://github.com/MonitorControl/MonitorControl/issues/323 https://github.com/alin23/Lunar/issues/210#issuecomment-752405561 The arbitrary way Apple sometimes just leaves out important features from its products is alarming. It hurts the ecosystem, creates confusion and uncertainty. 6 months has passed since M1 was introduced and still there is no resolution to this issue. But the missing DDC/CI implementation is just the tip of the iceberg, external display support is still a mess in general (user forums are full of complaints about resolution issues, washed out colors - M1 Macs switch to limited RGB range for no good reason - on LG displays via DisplayPort over USB-C, broken HDR support etc). It's a shame!

Finally, the problem is now solved, DDC/CI control is now possible for M1 Macs (except through the M1 Mac Mini's HDMI port which seems to have the same problem in this regard as the 2018 Mac Mini's HDMI port). See the developments here: https://github.com/alin23/Lunar/issues/210 https://github.com/MonitorControl/MonitorControl/issues/323 :)

You might want to try BetterDummy to create any HiDPI resolution you'd like, even on sub-4K external displays (which do not allow HiDPI by default on M1 macs).

The app BetterDisplay (https://betterdisplay.pro) can both read and override (!) the EDID on Apple Silicon, so both are definitely doable

Hope this will be fixed otherwise I won't be able to use 14.3...

This is not right even in the final 14.3...

The fix is of course to replace all DEPRECATED(13.0 to DEPRECATED(10.8 in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreGraphics.framework/Versions/A/Headers/CGDisplayStream.h Still, it is a shame Apple shipped this in such a state.

This super annoying bug came up after upgrading to 14.3. Project path is ok, so it must be something else.

Yeah, this message constantly popping up during debug is a new normal since Ventura 13.3. Does not seem to affect anything though and things work just fine.

Hi there - yes, I sent the crash log using the reporter tool popping up after killing XCode + a brief explanation about what I was doing. If it helps I can provide the offending Localizable.xcloc file along with additional details if needed.

Ok, some more info: After waiting several minutes (about 5) the task seems to complete and I can navigate Localization.xcloc. However closing Localizable and opening it again starts whatever is happening again. So the hang is not permanent. Simply opening Localizable.xcloc file directly outside of the project using XCode 16 seems to work without delay and not cause a hang. The XCode is running at 100% CPU usage during the hang. Attached a sample of what's going on with XCode a few minutes into waiting for it to finish whatever it is doing, after clicking on Localizable file in the IDE. Sample of XCode

Hi there, thanks for the response. To clarify, XCode only hangs - as it turns out, eventually (after about 5 minutes of intense work with 100% CPU load) it responds again and I can navigate the Localizable file. The crash log was generated only after (initially) I thought the hang is permanent and killed XCode. Sorry about the inconsistency, it is an xcstrings file, mentioning xcloc was just an old habit. :) I attached the xcstrings file to the Feedback report - however as I mentioned, XCode can open the xcstrings file as an individual file (when not treated as part of the project) without problem, only opening it as part of a project the hang happens. EDIT: I sent the feedback with all the requested info (FB14108294) + added some more context/observations in the description.

I see, thank you for pointing to this! :) Minor note: I always have a somewhat mixed feeling when a change retroactively reinterprets existing code like this (also: no warning given by Xcode about any possible ambiguity or change in interpretation), especially when a modifier that is required to restore existing behavior is available only in the latest version of the OS and therefore will make us live with a lot of #if available() blocks for years to came. It would be great at least to have the #available attribute for single modifiers - now one either needs to create a custom modifier to deal with this issue or put large chunks of SwiftUI codes into if #available() blocks because of a single version specific modifier.

Right, that makes sense. Thanks for the insight and the code, much appreciated! :)

This problem is still present in Xcode 16 beta3. :( I was hoping I could transition to the new Xcode but this prevents it. it seems like XCode is in some kind of death spiral around IDEXclocNavigableFileRep.respondToXclocChange(_:) and IDEXclocNavigableRep.respondToXclocChange(_:), but I see many more mentions of localization related stuff. I really hope this will be fixed. I had a fair share of issues with Localizations in Xcode 15 as well but those at least had workarounds (mostly various crashes on commit or push because of certain offending characters which I had to hunt down manually, sometimes spending hours to figure out what offendeds Xcode), but this is an issue I can't seem to find the workaround for.