Well, if you’re really adventurous, you could probably test it yourself, but since it would break code-signing, I’m not sure if you could run the test or not.
If you’re the daring type, message me privately and we can talk through it. It shouldn’t be that hard. Especially if you have Xcode which makes editing the plist file easier, but you could do it without Xcode also.
It looks like adding the info.plist setting works for some other applications, specifically “Office for the Mac” and “Atom”. And the link below for Office even shows how to re-sign the code, although I don’t know if this would work for KM or not.
So again, if anyone wants to try this, I can walk you through it in a private message. If you follow some general safety guidelines, which I will lay out, I don’t think there’s any real risk, although this is not a guarantee of future performance, your mileage may vary, use at your own risk, etc. 
These links are for reference only. Don’t make any changes unless you COMPLETELY understand what you’re doing, and/or you talk with me first. Or Peter, of course, but I doubt he’ll jump in and help us hack KM like this. 
No worries, I’m happy to do it and test it out. 
Are we adjusting the primary plist.info file within the package? Want to confirm… I’m comfortable with resigning the application.
There’s at least 2 plists. the main one in the bundle’s Contents folder, and then in the Resources folder there’s “Keyboard Maestro Engine” which has an info.plist inside it.
Not sure if there’s more or not.
I didn’t see any entries for NSSupportsAutomaticGraphicsSwitching in either of them. So my guess is you add the entry, and make it a bool of false.
I was thinking about the code signing issue, and I find it hard to believe you can re-sign it yourself. The whole point of signing code is so someone other than the developer can’t modify the code. If you can re-sign it yourself, then what’s to stop other people from modifying the code and resigning it themselves?
Anyway, I’ll be curious to see if you succeed.
I utilized the command referenced in the MS article to sign the package, it worked as expected.
codesign -f --verbose --deep -s - /
If I edit the info.plist within the main package, everything works as normal – no crashes – but it still uses the discrete graphics.
If I edit both info.plist in main package and the Engine package…The engine fails to start however KB does indeed start as expected.
Not sure why the engine is failing due to the change, need to investigate that.
Thanks!
Since you modified the Engine bundle, you probably have to code-sign that first. Then code-sign the entire bundle.
See if that helps.
Thanks Dan for chiming in with more invaluable information.
I tried it on the Engine and it totally works to keep the app signing.
I’m having problems getting the main application bundle to respond to signing but that is really not a huge issue.
It’s mostly the engine I was concerned with.
I’ll chime back in if I run into any issues.
Glad to hear it. I was just guessing about needing to sign the Engine first - it sort of made sense, but it was a guess.
There may be a different order of doing things, or perhaps there’s something else that needs to be re-signed.
Good luck!
I’m not having as much luck. Unfortunately when I sign both packages it won’t allow me to enable the ‘accessibility’ access to the engine, which it needs to operate.
Eric -
Did you simply break the package apart and sign the engine alone and then run it separately?
I opened the package and edited only the engine plist. I then ran the terminal command pointing to the engine package. Restarted and had to give the engine accessibility rights again. After that everything just works.
I do however have problems with the resigning of the application itself, but as I stated before, it really doesn’t matter that much for me if the editor triggers the discrete graphics or not.
Hope that helps.
Hmmm… You can confirm that your engine runs in the toolbar without issue after doing that? Just want to make sure.
Thanks for your help!
Yes. It works just fine.
This is awesome.
I was fairly worried about recommending you try this route, but I’m thrilled to see it’s working. Like I said. Awesome.
Roger that… I can’t seem to get it to operate properly. Following the exact steps you did, the engine just hits a consistent crash state for me. Shrug, oh well.
I've done quite a bit of researching on this over the past couple of days... and it turns out the code within the application is out of date. The flag NSSupportsAutomaticGraphicsSwitching actually tells the system the the application is capable of using either graphics card. Without having this set to the Boolean of True, it states the there is only one graphics card in the system. This causes the later MacBook pros to utilize the discrete card by default.
It really sounds like this could be updated officially without causing an issue. ... Is this something that is actively being looked at? Mac OS Sierra requires this option going forward or it will always force discrete graphics.
Just a heads up!
My reading of the option is that you should enable it if the application understands graphics cards and can actively switch them as necessary, which is not Keyboard Maestro which has no understanding of graphics cards.
I have a support incident in with Apple to query the situation.
Is macOS Sierra any different? As far as I am aware, this has already been the case for Macs with multiple graphics cards.
Hey Peter -
It appears as if macOS Sierra is becoming more stringent on the overall variable state. I’ve loaded KB Maestro into my dev instance of OS Sierra and the application now triggers the discrete graphics with both application modules (main program and the engine itself).
It is still beta however so this could change, although we are now in B5 which generally is the last release before GM.
Is anyone else running macOS Sierra and able to confirm the same behavior?
Thanks!
Yes, I can confirm this.
Adding the flag mentioned above fixes the issue on my system. At least for the Engine.
/Eric
Out of curiosity I grepped through my Applications folder to see how many —and which— of the apps there are allowing the GPU switch:
The result of
grep -iFlrp --include 'Info.plist' 'NSSupportsAutomaticGraphicsSwitching' /Applications
is this:
result-grep.txt.zip (1.7 KB)
After removing multiple plist hits belonging to the same app I get a total of 89 applications that are using the key. The total number of applications is 440 (including apps in subfolders but excluding apps inside application bundles).
This is 20%. Doesn’t sound like much. However, the key is only applicable for applications with an “OpenGL context”, and I have no clue how to determine how many of the remaining 351 apps are OpenGL apps…
Apple DTS confirmed (claims?) that the option is safe as the sub-systems should ensure they are using whatever graphics card they require, so I have (provisionally) enabled this option for the next version, though it may be reverted if it results in more serious issues than battery usage.