Ya the connection bubbles are gone in source files it seems. I wouldn't be terribly surprised if this was on purpose as a "optimization" / way to clean out source from Xcode to make room for ...er never mind. You can still connect outlets/actions by just writing the property in your interface: @property (nonatomic, weak) IBOutlet NSTextField *label; -(IBAction)methodName:(id)sender And then making the connection in Interface Builder from the Connections Inspector. I use to use the Assistant editor and make connections the way you describe all the time back in the day when I was learning UIKit but I do find it faster to just type the property with IBOutlet and then connecting it in the Connections Inspector in IB. A shame not to see those nice little connection bubbles anymore in source files. I don't care what anyone says about "live previews" or whatever...IB was the thing. It's a shame Apple doesn't make improvements to it anymore but I still find it useful.

So it sounds like a long shot I guess but I filed FB22492490 anyway because I don't really understand the point of failing with NSFileWriteFileExistsError if the existing file isn't going to be protected. Also suggest in the FB that documentation should be added.

Well when I first wrote this code (probably ~8 years ago or so), using the atomic flag with RTFD file wrapper would overwrite an existing file. Without the atomic flag, the operation would fail if the file exists but the existing file would remain (which is my desired behavior). At some point this changed and now not specifying the atomic flag, does not overwrite an existing file as I already mentioned but for some reason fails while also discarding the existing file. I cannot think of a situation where that behavior makes any sense or is useful other than to make it easy to write code that causes accidental data loss. If overwriting is always desired (atomic or not) then an existing file shouldn't ever be an error reason I don't think. I guess I'm grumpy about the behavior changing unannounced in a way that impacts the behavior of apps. If the plan is to keep it this way going forward I think a big bold note should be added to the documentation "if you try to save to a URL that already exists, the operation will fail and the file will disappear"). In any case I've modified my code to write to a temp file first, and then try to move it afterwards. I guess you could argue that this is a better design and I'd agree. Perhaps I should have always done it this but the way I had it wasn't "wrong" until the rug got pulled.

I'm working on rewriting a little piece of code in my app. I have a label that displays a date and adjusts the date format (growing and shrinking based on available width). I take measurements using -sizeToFit and also make sure I don't end up in an infinite loop. But I get: **The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. ** On this particular label I'm not using constraints because in this case that would seem to add a lot more complexity and I turn off translatesAutoresizingMaskIntoConstraints. At least in UIKit, I don't recall ever having issues calling -sizeToFit in -layoutSubviews or -viewDidLayoutSubviews. I guess I'm going to have to modify my approach and take my measurements offscreen. Autolayout is cool but I think it is sometimes too strict.

I was able to cook something up with constraints and computing the styles for the date formatter with an offscreen label, then taking the best fitting style and using it on the onscreen label. BUT I'm still a teeny bit nervous about all this because: Changing the date format style causes.. the stringValue of the NSTextField to change which can cause.. The text field to invalidate its intrinsic content size (sometimes I guess). I don't really know my bounding width until I'm in layout. It's easy to avoid infinite loops in my code but autolayout with its strict exceptions and rules, implicit layout invalidation etc., it is not so easy to guard against rules that are not well documented. B/C autolayout claims it is not legal to change layout in the middle of layout how can I change the date format safely during layout? I'm not hitting the exception anymore which is good but as an extra precaution I have my NSTextFIeld subclass override -invalidateIntrinsicContentSize and do nothing..because I don't want setStringValue: to invalidate the layout, I want to adjust the .stringValue to live within the layout I already have. I hope that makes sense. Please don't be so strict throwing exceptions in Autolayout! Layout bugs, overlapping views, etc are typically not fatal errors IMO. Sincerely, Macho

Err so 304 is the design time height of the first row I have in Interface Builder. And for some reason NSTableView tries to force that as the line scroll from within -tile. All my other rows are not that big. I guess I can reorder the rows in the xib, or just keep calling super with my own value. Edit: Also changing "Row sizing style" from "Match Canvas" to "Custom" allows me to change the row height to whatever I want. NSTableView apparently forces the value of row height as the scrollView's lineScroll. Does it need to be reset in every -tile call? I'm not sure. But I'm implementing heightOfRowByItem: so just setting the row height in the xib is the way to set line scroll without actually changing the height of the rows (which are not all the same)

I experience this issue every day, across many different apps, all the time on my iPhone SE 3rd gen. I've just been ignoring because I've been kind of busy with macOS. But really an annoying bug. Happens in Safari all the time. Usually after playing a video on YouTube. But it happens other times too. Seeing this thread was posted way back in September is kind of demoralizing I think.

You should be able to do this. Try using: + (void)restoreWindowWithIdentifier:(NSUserInterfaceItemIdentifier)identifier state:(NSCoder *)state completionHandler:(void (^)(NSWindow * _Nullable, NSError * _Nullable))completionHandler NS_SWIFT_UI_ACTOR API_AVAILABLE(macos(10.7)); https://developer.apple.com/documentation/appkit/nswindowrestoration/restorewindow(withidentifier:state:completionhandler:)?language=objc Appkit restores window frames automatic but if something funky is going on and that is being done too late you can ensure the window size is restored early by setting it yourself in +restoreWindowWithIdentifier:state:completionHandler: before you call the completionHandler.

IFIRC I’ve had success working around this kind of issue by getting the transitionCoordinator and adding an empty animation alongside it and then presenting the view controller in the completion handler. Fallback and just present it if transition coordinator is nil. https://developer.apple.com/documentation/uikit/uiviewcontroller/transitioncoordinator?language=objc I don‘t SwiftUI though so Albert‘s answer might be the better one for your project

This seems to avoid the issue: -(void)rightMouseDown:(NSEvent*)theEvent { if ((NSEvent.pressedMouseButtons & (1 << 0)) != 0) { // Not at the same time, dog. return; } [super rightMouseDown:theEvent]; }

I filed FB22716998

No problem. I also just noticed if you do the selection quite rapidly the selection box can also get stuck (no right click required). Seems to happen when collection view is grouped though I'm not sure exactly if that has anything to do with it (so in Finder "Use Groups" with section headers). Also if you mouse drag while you are doing the selection box outside the collection view (to the point where your cursor extends into the sidebar in Finder) things sometimes stop working. What things stop working? Mouse clicks. The collection view temporarily stops responding to mouse clicks. Using the arrow keys to move the selection 'fixes it' then mouse clicks start working again. My app uses an NSSplitView and has sidebar and a collection view so my app is impacted the same way. My hope is because Finder is impacted they may fix. Fingers crossed. In my app when this mouse clicking problem happens I am getting -mouseDown: in my NSCollectionView subclass (and calling super) but the collection view just doesn't modify the selection when you click on items nor does it deselect when you click on the background.

Is it only with objC code or Swift as well ? Xcode 26.5: In new iOS storyboard project I can connect IBOutlets from the Assistant editor in Swift...looks fixed there. Connection bubbles show. But in Objective-C the connection bubbles are completely gone from source files so in ObjC the problem is not fixed, actually worse. You can connect from the Connections Inspector though, but Xcode won't display "connection" status in ObjC source. So for me, because I still use ObjC the problem is worse. Hope that's not intentional. That would be very very negative evolution. You mean typing xibs by hand doesn't make you more productive!? 😂