With Xcode 14.3.1 on macOS 13 (Ventura), I found that you cannot put SwiftUI.Menus inside Lists without breaking the key event loop – iff you also set the menu button’s .buttonStyle(.plain)! Once that button style is used, menu item interactions will make the app
Variable row heights in your NSTableView might be broken in your apps on macOS Ventura 13.0 – it’s fixed with the upcoming 13.1, but that’s only available as a beta at the moment. When you replace table contents by calling aTableView.reloadData(), this will ingest the new data as usual, but the old row heights won’t be forgotten. This can affect scrolling. The row height cache, it seems, isn’t properly invalidated or cleared.
Today I found that NSTextView has a bug where it won’t automatically scroll to keep the insertion point visible when you hit Enter or Return to insert a line break. Update 2022-04-26: This bug is resolved on macOS 12 Monterey! So I’d suggest something like:
If you run macOS 10.13 High Sierra, try not to use the Help menu. It will appear to freeze the app for which you invoke the Help menu: it will not accept keyboard input anymore, emitting the NSBeep “invalid action” sound in most circumstances. The reason seems to be that the nifty Search bar inside the Help menu will acquire focus so you can search for a menu item or help book entry. This is taking away focus from the app window. You notice this when the blue focus ring around an active text field in the window goes away; instead, the Help menu’s Search bar obtains focus and the accompanying blue focus ring. All this is supposed to happen. This process just isn’t reverted for some reason since at least macOS 10.13.3, maybe earlier. When you click back into the app outside of the Help menu, the key window status will not be assigned back to the window you click on. That means keyboard input will not work at all. (As a non-native English speaker, I asked if “key window” was supposed to mean “window that responds to key events” a while back. While people agreed this wasn’t the intention, I still cannot help to think that way. The app has no key window, so key events are not handled, resulting in NSBeep.)
“Month 13 is out of bounds” appeared in my Xcode console logs today. But I don’t do date arithmetics.
When you create an empty macOS Cocoa app from the template, the message shows, too. It’s emitted before applicationWillFinishLaunching(_:) is called.
Looking at the Console.app output of other processes, I saw this was all over the place. TextMate, loginwindow, User Event Agent – every app is triggering this message.
Rdar or GTFO, right? – rdar://35792221
Let’s hope this does not indicate any important framework part is broken.
This is both humbling and worrying. Humbling, because Apple engineers make just the same silly mistakes as us app developers. Worrying, because having a working macOS is rather important to a lot of people around the globe, and while this message does not prevent me from using my Mac or any apps so far, bugs like these could have people killed in other contexts (think aerospace or autonomous cars).
Update 2017-11-06: (Yes, I’m back on Nov. 6th! :) Seriously, it’s now Monday, Dec 4th.) Like some other people I was suddenly suffering from 100% CPU usage by the process UserEventAgent which also consumed RAM at a rate of about 4GB/ every 3 minutes. Disk swapping galore, my Mac turned unusable quickly. Only way I found to get rid of this:
UserEventAgent processNote that this only happened after rebooting. So if you can, do not shut down your Mac for a while just to make sure.
There’s a lot to learn in terms of company culture from Basecamp (former 37signals). Shawn Blanc has written about a workshop by Basecame. One thing I just had to share immediately is this: “Bugs are the edges of what works”:
Software simply has bugs. And so if it’s not a critical bug — (such as: if it’s not losing customer data) — then they probably won’t ever fix it. Because to fix an edge bug and chase them all down means they’re not making new things or improving features that really matter.
That’s no excuse for a crappy user experience. But not every edge case has to be solved.