#MarsEdit 5 for apple instal free update#
#MarsEdit 5 for apple instal free mac#

Disabling Touch Bar support entirely in the short term will be preferable to subjecting my customers to unpredictable crashes that are out of my control. I haven’t decided for sure yet whether to ship with this in place, but unless I find a more suitable workaround, I think I will. When it sees that NSFunctionBarAPIEnabled is set to NO, it will kindly avoid initializing the classes which are evidently making many apps prone to crashes on Touch Bar Macs. You want to put this early in your app’s launch, so that it’s registered before AppKit’s Touch Bar infrastructure loads up. NSDictionary* myDict = standardUserDefaults] registerDefaults:myDict] If you wanted to do something like this in an app, you could add a few lines like this to main.m: By registering a default value in the app itself I will not force users to save any permanent value in preferences, and will also give them the ability to override my judgement as they see fit.

#MarsEdit 5 for apple instal free update#

Getting back to my motivation to eliminate these crashes as soon as possible for my customers, I think that I will ship an update to MarsEdit that disables the Touch Bar, but does so in a transient manner. Be aware, however, if you do this that you’ll lose Touch Bar functionality for that app forever, or at least until you remember you set this funny default value. In a situation like this, if you are suffering many crashes as a user, you might decide to do something like the above, writing a custom NO setting to the NSFunctionBarAPIEnabled value. The Touch Bar works when you’re focused in on some system-standard UI element such as a text view, but it doesn’t do anything special throughout most of the app.

#MarsEdit 5 for apple instal free mac#

Other apps are not so clear cut: you might have an affected app on your Mac that “works with the Touch Bar,” even though it doesn’t do anything special to support it yet. 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.