We've got a hard to repro issue on Intel only when performing UI layout. It seems the collection view code gets into a recursive loop of doom and eventually the app crashes. This is only happening on Intel, the ARM version is fine. It seems related to this issue: https://developer.apple.com/forums/thread/732580 There an Apple Dev acknowledges that there are issues with the Intel version of the OS. Here's the simplified stack we're seeing: -[NSISEngine _coreReplaceMarker:withMarkerPlusDelta:]" -[NSISEngine constraintDidChangeSuchThatMarker:shouldBeReplacedByMarkerPlusDelta:]", -[NSISEngine tryToChangeConstraintSuchThatMarker:isReplacedByMarkerPlusDelta:undoHandler:]", -[NSLayoutConstraint _tryToChangeContainerGeometryWithUndoHandler:]", -[NSLayoutConstraint _setSymbolicConstant:constant:symbolicConstantMultiplier:]", -[NSLayoutConstraint setConstant:]", -[NSView(NSConstraintBasedLayoutInternal) _updateSimpleAutoresizingConstraintsInPlace:forAutoresizingMask:]", NSViewUpdateConstraintsForFrameChange -[NSView setFrameSize:]", -[NSView setFrame:]", -[NSClipView _updateOverhangSubviewsIfNeeded]", -[NSClipView _reflectDocumentViewFrameChange]", -[NSView _postFrameChangeNotification]"," -[NSView setFrameSize:]", -[NSCollectionView setFrameSize:]", -[NSView setFrame:]", NSViewActuallyUpdateFrameFromLayoutEngine", -[NSView resizeSubviewsWithOldSize:]", -[NSView setFrameSize:]", -[NSClipView setFrameSize:]", -[NSView setFrame:]", -[NSScrollView _setContentViewFrame:]", -[NSScrollView tile]", -[NSScrollView _tileWithoutRecursing]", -[NSScrollView reflectScrolledClipView:]", -[NSClipView _reflectDocumentViewFrameChange]_block_invoke", -[NSClipView _reflectDocumentViewFrameChange]", -[NSView _postFrameChangeNotification]", -[NSView setFrameSize:]", -[NSCollectionView setFrameSize:]", -[NSView setFrame:]", -[NSCollectionView _resizeToFitContentAndClipView]", -[_NSCollectionViewCore setContentSize:]", -[_NSCollectionViewCore _updateVisibleCellsNow:]" -[_NSCollectionViewCore _updateVisibleCellsNow:]" -[_NSCollectionViewCore _updateVisibleCellsNow:]" -[_NSCollectionViewCore _updateVisibleCellsNow:]" . . It seems to be limited to macOS 13.1 too. Hoping someone might have a clue? Thanks, Robert. Here's a link to the full stack: https://www.icloud.com/notes/076h1RXj4rvv7TzS5ICnvG6vw#NSCollectionView_crash_stack:

Got an issue with XC UI Testing where I can't open documents without them being marked as locked (the Locked label is shown in the titlebar). The document in question is a testing asset and copied into the testing bundle for easy access. I've checked the file in bundle in Finder and the document is not marked as locked. I've also tried copying the document to a temp directory before opening it and it's still locked?! What's the trick for getting it to open without being locked?

Exploring support for document conflict resolution on iOS (Mac is well covered automatically by NSDocument) and I've run into a mystery. Conflict Situation: Two apps (one iOS, one Mac) have the same iCloud document open. Both make changes and iCloud detects a conflict. Both apps present conflict resolution interfaces (Mac automatically, iOS with my code, modeled on Pages). Resolution: Resolve a conflict on the iOS side, the Mac side syncs up perfectly. Repeat the situation, but now resolve on the Mac side and the iOS side just sits there with its conflict resolution UI presented and the last UIDocumentChangeState received is set to Conflict. Discussion: I thought I would get one last UIDocumentChangeState that would tell me that the Document is back to Normal (so I could dismiss the conflict sheet and reload the contents, if necessary). But no further notifications are sent (until I close the document - and then I get a "Closed | Conflict" state!) Is there some other notification I'm missing? Pages, when put into a similar situation, of course detects the resolution and dismisses its sheet. Surely I can't be the first to trip over this, but there's very little discussion on the web. Thanks for any pointers, Robert.

Trying to build a proper Mac menu system with the new UIMenu/UIKeyCommand system and running into an issue with the UIKeyCommand requiring an input key. Of course this is needed on iOS as the keyboard is the way to trigger these commands, but on MacOS it is normal to have menus without associated accelerator keys. Are we expected to assign keys to every menu item in our MacOS interfaces? Hoping an update addresses this. (I've filed a feedback report on these, but hoping another developer might have figured out a work around for now?)

I simply want to close a window by clicking on the standard red close button while testing and the identifier is provided by the Framework, but getting a match is proving tricky. Has anyone had success with that? Of course I can use the menu to close but would like this to work. I have a query with the window, so I would imagine: XCUIElement *closeButton = [window matchingIdentifier: XCUIIdentifierCloseWindow].element; would suffice, but no luck.