no we don't. I re-installed macOS 26 with Xcode 26.2 and the problem persists

Sure: ❯ xcodebuild -showComponent metalToolchain ; xcrun -f metal ; xcrun metal --version 2025-10-31 19:42:19.179 xcodebuild[11856:231862] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.1.324.0.Qp6DBA” couldn’t be opened because you don’t have permission to view it. 2025-10-31 19:42:19.414 xcodebuild[11856:231864] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.1.324.0.Qp6DBA” couldn’t be opened because you don’t have permission to view it. 2025-10-31 19:42:19.417 xcodebuild[11856:231860] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.1.324.0.Qp6DBA” couldn’t be opened because you don’t have permission to view it. Asset Path: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData Build Version: 17A324 Status: installed Toolchain Search Path: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.Qp6DBA /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain

I still experience this problem with Xcode 26.1 ~ ❯ xcodebuild -downloadComponent MetalToolchain Beginning asset download... 2025-10-28 23:23:43.391 xcodebuild[1151:10353] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.1.324.0.wLDum9” couldn’t be opened because you don’t have permission to view it. Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData/Restore/022-17211-415.dmg Done downloading: Metal Toolchain 17A324.

Same problem. Reported Sep, 9, still happens to me FB20178568

Still happening in Xcode 26.0 (17A321) RC

Xcode 16.3 on macOS 15.4 still crashes the debugger. In different situations, but it crashes in the same places. eg. can't debug SwiftUI on iOS simulator.

For the record, the final release macOS 15.4 (24E248) and Xcode 16.2 still crashes debugger.

The crash is still here with macOS 15.4 RC2 (24E247). Xcode Version 16.2 (16C5032a). For me it crashes when debugger is about to start.

in that case what is the meaning of .list and .table options it does not affect the allowed result? It's not clear to me.

That difference is that I adjust the viewport position so the text at end of the document is displayed in the current visible rect (NSView.visibleRect). thank you, let me summarize the approach: receive an estimated (too big or too small) content height update content size with the estimated height move viewport to the end of that height (either it is final or estimated) layout end of the document there do you think that approach translate well to any location in the middle of the document? What about the scrollview scrollbar that depends on the total content Size and updates as layoutmanager update its size, do you have any trick for that?

@DTS Engineer thank you for your suggestion. I tried that approach now (and before) and it looks like calling enumerateTextLayoutFragments yields approximate/estimate layout positions. Specifically, calling the suggested routine multiple times returns different values: var lastLayoutFragment: NSTextLayoutFragment! textLayoutManager.enumerateTextLayoutFragments(from: textLayoutManager.documentRange.endLocation, options: [.reverse, .ensuresLayout]) { layoutFragment in lastLayoutFragment = layoutFragment return false } let lastLineMaxY = lastLayoutFragment.layoutFragmentFrame.maxY print(lastLineMaxY) in my test case case result with these values: 4302376.62016702 4092451.6843738933 3979224.5583475474 4565598.13343745 4332115.927268179 4331192.884374112 4331192.884374112 4331192.884374112 4331192.884374112 4331192.884374112 as we can see, the value eventually get "stable" and that is actuall height of the document. The initial values jumps (estimate) up and down without the pattern. That behavior is aligned with values reported by usageBoundsForTextContainer and is a root of many issues. In the example you provided is not different, hence I'd like to ask how does it suppose to work with estimated layout values?

the origin x = 5 most likely comes from NSTextContainer.lineFragmentPadding. The default value of this property is 5.0.

paragraphSeparatorRange is a newline/paragraph_separator itself paragraphContentRange is just paragraph content, without the newline values are available once the layout happen.

Content manager allows to addition one or more layout managers. let layoutManager = NSTextLayoutManager() layoutManager.textContainer = textContainer let contentManager = NSTextContentStorage() contentManager.addTextLayoutManager(layoutManager) that you can later assess via contentManager.textLayoutManagers. Additionally there is a flag automaticallySynchronizesTextLayoutManagers (defaults to true) to facilitate synchronization of multiple layout managers for that content manager.

I don't think NSTextView / UITextView ever gets support for NSTextContentManager. That's one of the reasons I created STTextView, which is a custom TextKit 2 based text view implementation, you may want find useful in that regard.