Use macos_helper.disable_appnap at startup

[JSchoreels]

Hello @dae

I'm on the latest beta and I tried the solution to disable the appnap quoted here

But apparently, after reading more, it doesn't really get preserved through executions

You'll want to make sure to keep a strong reference to the token returned by -[NSProcessInfo beginActivityWithOptions: reason:], because App Nap may resume again automatically when the token is deallocated.
Prevent App Nap Programmatically

I added the call to disable_appnap() in the qt/aqt/main.py, rebuild the library and run the app with the Dock, because with the terminal ./run I think it doesn't get to sleep.

Now it seems to be running OK.

Is it OK for you to enable it by default ?

[iamllama]

Maybe this could be added to ankiconnect instead of disabling it for all macbook users by default

[JSchoreels]

I mean, Anki power usage is not that high anyway, and having to potentially investigate this for future add-ons that would have to rely on Anki not being put to sleep feels like a massive headache. Especially that this is a platform specific behaviour that addon devs would have to keep in mind. I'm also unsure about expecting addon devs to tweak how the OS and Anki talk to each other if it can be done on the app level.

For reference all the prior workarounds I tracked down :

# 2025
defaults write net.ankiweb.launcher NSAppSleepDisabled -bool true
# 2021 : 2021-08-06
defaults write net.ankiweb.dtop NSAppSleepDisabled -bool true
defaults write net.ichi2.anki NSAppSleepDisabled -bool true
defaults write org.qt-project.Qt.QtWebEngineCore NSAppSleepDisabled -bool true
# 2018 : Anki 2.1.6 2.1.7 changed it's app domain name, 
defaults write net.ankiweb.dtop NSAppSleepDisabled -bool true
defaults write org.qt-project.Qt.QtWebEngineCore NSAppSleepDisabled -bool true

Now that Dae himself found a pretty good way to disable that behavior at user request, I don't really see why it would be a stretch to allow users to have that improvement for the app itself without having to open the debug console each time they want to start Anki to mine.

For what it is worth, I have no other macos apps that behave like this. If they kind of expect to be able to be run in the background, they just declare it. At this point, with AnkiConnect being a cornerstone of most other integration, I think it's pretty safe to assume Anki also has to be able to run in the background without having to enter a python console to enter a "don't put me to sleep" each time you boot it.

[iamllama]

I mean, Anki power usage is not that high anyway

This assumption is going to need supporting data. Even then, this seems to be caused by a singular addon (that you assume to be a cornerstone). Not fair to penalise everyone for it, especially given that Anki doesn't need to run in the background.

You're also assuming that ankiconnect users will upgrade their version of anki to ingest the "fix" and risk breaking their other addons

[GithubAnon0000]

Are you suggesting anki should always run in the background even if the user didn't open it yet? I know this change is for macos, but I personally would be absolutely against that.

(Also: on linux you can easily set up apps to autostart in the OS settings if you really want to do that. Does mac not allow something similar? Does this really have to be included on an application level?)

[JSchoreels]

Are you suggesting anki should always run in the background even if the user didn't open it yet? I know this change is for macos, but I personally would be absolutely against that.

(Also: on linux you can easily set up apps to autostart in the OS settings if you really want to do that. Does mac not allow something similar? Does this really have to be included on an application level?)

It has nothing to do with that. If you close it, it's closed. If you minimize it, it won't get suspended and keep on running like a normal process instead of being frozen to any API interaction.

[JSchoreels]

This assumption is going to need supporting data. Even then, this seems to be caused by a singular addon (that you assume to be a cornerstone). Not fair to penalise everyone for it, especially given that Anki doesn't need to run in the background.

This is my Anki running without the App Nap mode, it's at ~60 for the 12hr Power while most apps are pretty higher.
As you can also see, there's not much App letting App Nap freezing the process once it enters the background.

As you can also see, even without the App Nap enabled, the current Energy Impact is at 0. I'm checking at it right now and it has some spike to 0.7

You're also assuming that ankiconnect users will upgrade their version of anki to ingest the "fix" and risk breaking their other addons

There's nothing to ingest, it's how the OS prioritizes and freezes some apps if not interacted with for the past few minutes. I don't understand why add-ons should even meddle with how Anki and the OS interact.

App Nap is basically some kind of auto-suspender of process

[iamllama]

There's nothing to ingest

Not sure what you mean by this. My point is that fixing ankiconnect (which supports anki 2.1.45+) will ensure almost all who use it will benefit, whereas fixing it in future anki versions won't mean that it gets backported to earlier anki versions and will worsen it for the rest

I don't understand why add-ons should even meddle with how Anki and the OS interact.

Because this addon specifically forces anki to need to run in the background. If there are many more addons like this in the future then a case could be made