![]() It’s probably a case where having the default on by default is exposing it to bugs in the Touch Bar infrastructure, even though it will never benefit by having Touch Bar support enabled. ![]() SystemUIServer is an interesting example, because I can’t honestly imagine what I’m giving up by disabling Touch Bar support in the app. To my satisfaction, setting the value explicitly to NO for any of the affected apps completely eliminates the crashes:ĭefaults write NSFunctionBarAPIEnabled -bool NO I have very reproducible test cases for many apps, including Apple’s own SystemUIServer process, so I decided to play around with the NSFunctionBarAPIEnabled user default and see how things go. It defaults to YES, but if it’s set to NO for an app, I think the app remains more or less invisible to the Touch Bar. Poking around the AppKit infrastructure supporting the Touch Bar, I discovered a secret NSUserDefaults setting, NSFunctionBarAPIEnabled, which seems to determine whether the system exposes an app to the Touch Bar at all. I don’t know if Apple considers the crashes a problem worth pursuing, and if so, how soon they plan to deliver a fix. This left me feeling obligated to my customers to find a solution that I can deploy soon. I had hoped that we might see a fix from Apple in macOS 10.12.2, but alas the issue is still there. For example, some of my apps that are still built against a 10.6 SDK crash on Touch Bar Macs, either frequently or infrequently, depending upon the user. Most likely it affects all apps that were built against an SDK of a certain vintage. ![]() These crashes seem to affect all apps that were built with a certain toolchain. I wrote previously about crashes related to Apple’s Touch Bar.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |