Is there a SwiftUI version of NSControl.allowsExpansionToolTips? That is, showing a tool tip with the full text when (and only when) a text item is truncated? Or do I need to use a hosting view to get that behavior?

When the user makes changes in my document, I call document.updateChangeCount(.changeDone) which seems to successfully mark the document as changed - the close button has a dot, the proxy icon is disabled, and when closing/quitting I get the save prompt. The problem is that the File > Save command is never enabled, so saving/quitting is the only way I can get it to save. I'm not overriding any menu validation methods in my NSDocument subclass. I do have a validateMenuItem() in my main view controller, but it's only for a popup menu, and setting a breakpoint there confirms that it only gets called for the popup. What else could be preventing Save from getting enabled? Edit: I tried overriding validateUserInterfaceItem() to return true when appropriate, which works, although the Save command then appears as "Save..." so apparently I'm also responsible for updating the title. In any case this seems like it shouldn't be necessary. I wonder if it's because I implement saving in save(to:ofType:for:completionHandler:) rather than one of the other possibilities. I was going to try wirte(to:ofType) instead but that is surprisingly nonisolated, so I'm not sure how I'm expected to safely access my data model from there. I can't do data(ofType:) because saving may involve writing to multiple files.

My goal is to create a communication mechanism between the UI test runner and my app. That way I can tell the app to display specific data (without laboriously going through the UI steps of getting the app into that state) and also read the values stored as a result of simulated user actions. So, what are the best options for that kind of IPC? So far I have tried NWListener and friends, but it looks like I'd have to add entitlements to my app, which I'd rather avoid since this is only for testing. Can I have the app listening for some kind of IPC connection without requiring entitlements?

I'm working on this project for the first time in a while, so I'm not sure if this issue started with Xcode 15 or what, but now when I run my UI tests I get the warning "“MyAppUITests-Runner” is from an unidentified developer and differs from previously opened versions. Are you sure you want to open it?" Code signing identity for the UITest target is set to "sign to run locally". Changing it to "Apple Development" doesn't help, and neither did a clean build. How do I need to configure it to eliminate the warning?

Anyone else having trouble getting Xcode to expand nested Swift macros? The outer macro expands fine, but when I try to expand the inner macro it just beeps. My macro is used like this: @ThrowingImplementation(MyError.unimplemented) protocol MyProtocol { func something() throws } expanding first to this: @ThrowingExtension(MyError.unimplemented) protocol ThrowingMyProtocol: MyProtocol { // func something() throws } ...which is supposed to expand to this: extension ThrowingMyProtocol { func something() throws { throw MyError.unimplemented } } but I can't get Xcode to expand this second macro. I have to use a nested macro because only an extension macro can introduce an extension. The function is included as a comment so the extension macro can see it. I have unit tests for both macros, and in the tests everything is fine. My problem is that, in some cases, when I do struct MyThing: ThrowingMyProtocol {} I get an error that it does not conform to MyProtocol even though that macro-generated extension should have taken care of implementing all functions. Not being able to expand the nested macro makes it hard to diagnose why this is happening. (this is with Xcode 15.0.1)

When I try to use the new WebAuthenticationSession (introduced in iOS 16.4), it throws an error about not having a presentation context. WAS doesn't have a way to specify the context, so it must be automatic and something is messing up the automatic detection. One thing I noticed is that my call to webAuthSession.authenticate() ends up happening off the main thread because of how the enclosing Task gets scheduled (in spite of my adding @MainActor in various places to try to get it back on track). Before I go too far down that rabbit hole, can anyone confirm that the authenticate() call will throw that presentation context error if called off the main thread?

I have a segmented control in my app's toolbar with menus assigned to each segment, so that clicking the segment triggers a command, but click and hold opens the menu. This is using standard NSSegmentedControl behavior. After building with Xcode 14, however, I find that the behavior is changed: click and hold still opens the menu, but the menu closes as soon as you release the button. The menu used to stay open until you select an item or click outside to dismiss it. This is a problem because my automated tests rely on the menu staying open if you click and hold without moving the mouse. I'm having trouble finding a workaround. I tried changing my click(forDuration:) call to click(forDuration:thenDragTo:) so that it selects the menu item before releasing the button, but that doesn't work because it tries to resolve the menu item's XCUIElement before executing the click, so it fails because the menu isn't open yet. (I filed feedback for this problematic behavior - FB11513016) Is there another workaround I can try? Or a way to restore the popup menu "sticky" behavior?

I've discovered that my app has a memory leak, where when I close a window, it disappears from the screen but it (along with all its views, view controllers, and associated objects) actually doesn't get released. Instruments doesn't register it as a leak. It does show a few unidentified malloc leaks, but nowhere near enough to account for a window full of stuff. Xcode's memory graph doesn't show any leaks either, and I've combed through it looking for retain cycles or unwanted captures in blocks. I've fixed a few, but it hasn't been enough to actually get the window released. What other tactics are there for finding this kind of leak? The project is here for anyone feeling adventurous: https://github.com/Uncommon/Xit

I'm working on adding support in my app for full-height sidebars, as introduced in macOS 11. The trick is, when the window tab bar is visible, I want to turn the full-height sidebar off. The two don't mix well when the sidebar content is different in each window, as it is in my app. See Xcode for an example of what I want to do (View Show Window Tab Bar). See Preview for an example of what I want to avoid (open two multi-page PDFs and put them in a single tabbed window). What's working: I observe the window's tabbedWindows property, and toggle the fullSizeContentView flag in its styleMask accordingly. Thus the window's style updates as needed when I hide and show the tab bar. What's not working: I need to have a sidebarTrackingSeparator item in my toolbar in order to have some items above the sidebar. But when fullSizeContentView is off, that item appears as a plain separator. I don't want it to be visible at all in that state. There isn't a straightforward way to hide a toolbar item, especially if it doesn't have a view, which it turns out this one doesn't. I tried removing the separator item and re-adding it when the window state toggles, but that leads to Cocoa throwing exceptions, complaining that only one tracking item can be registered at a time. This would seem to be a bug, but Xcode manages it somehow. So how can I properly toggle my window and toolbar state without having that visible separator?

In AppKit, there is NSHostingController and NSHostingView. In UIKit, there is only UIHostingController. So what gives? Sure, you can use UIHostingController, grab its view, and ignore the controller (ie not bother adding it as a child view controller). But it seems reasonable to assume that the omission of UIHostingView is intentional and you need the view controller properly connected to make things work right. But which things? The problem is that incorporating UIHostingController into a view controller hierarchy can be difficult because you might not know at that point it the code what the parent view controller is (unless you add some otherwise unnecessary contortions). And yet the docs say you're supposed to add the child view controller to its parent before you add the view to the superview. For example, you could have a situation where your UIView is sandwiched in the hierarchy in between SwiftUI components - both embedding and embedded in SwiftUI. In my experiments this works fine in may ways, but UIViewRepresentable doesn't give you a view controller to be the parent of your UIHostingController. So you're stuck with the consequences of an orphan view controller... whatever they are.