"Prevent App Nap" check box not available for Cocoa builds

Targets macOS
22

Normally crash logs look like this:

[quote]Time Awake Since Boot: 1000000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff93b25f06 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff853a34ec pthread_kill + 90
2 libsystem_c.dylib 0x00007fff8ee066df abort + 129
3 org.python.python 0x0000000105c39f71 Py_FatalError + 65
4 org.python.python 0x0000000105c3bd23 _Py_InitializeEx_Private + 1379
5 com.mothsoftware.fix_encoding 0x0000000100002a1f 0x100000000 + 10783
6 com.mothsoftware.fix_encoding 0x0000000100000f7d main + 333
7 com.mothsoftware.fix_encoding 0x0000000100000e04 start + 52[/quote]

But perhaps the different format comes from the cause of the crash.

The report is full with stuff from code signing:

23

[quote=396252:@Beatrix Willius]Normally crash logs look like this:

But perhaps the different format comes from the cause of the crash.

The report is full with stuff from code signing:[/quote]

It is code signed though. Maybe Sam can put some light on this?

24 
MainWindow.MainWindow.E7_Action%%o<MainWindow.MainWindow>o<Timer> + 506 (ff¬?Works) [0x103063f9a]

This is the last line of the report before it did a code sign check and deep within Apple’s code sign checking system it failed (out of our hands). The most common problem is a failure for it to communicate with Apple’s web servers.

I’ve seen similar issues where the code sign tools can crash if they can’t reach Apple’s code sign servers!

25

I’m running Sierra, and I just noticed that I cannot anymore prevent/allow app nap. But I’m sure it worked before installing Sierra.
My tests done with (1) Sam’s RedBull and (2) using Thomas T’s Preferences (cfr. macoslib).

What I see is that Activity Monitor shows Yes/No only for the Finder and Safari. All other apps are stuck at No.
May be it is time, at least for me, to forget about using Prevent App Nap.

26

This is intentional. Xojo now uses higher Mac SDK version, so Apple expects that you as developer know about it.

e.g. use NSProcessInfoMBS class

27

Now I know. Thanks.

28

[quote=415690:@Christian Schmitz]This is intentional. Xojo now uses higher Mac SDK version, so Apple expects that you as developer know about it.

e.g. use NSProcessInfoMBS class[/quote]
Now that you bring that up - is there a way to prevent it for launched processes as well? I’m still running into situations where my helpers are being “de-prioritized” all the way to Zombie state after 10s of hours of running.

29

Are these helper apps console or GUI apps? I think (thought?) that console apps were immune from app nap. Are you seeing console apps get “de-prioritized” too? I don’t see a priority column option under Activity Monitor > View > Columns so what are you using to verify the de-prioritized state?

30

They are C/C++ console apps. Yes - I’ve actually watched my task drop in priority and finally end up Zombied and disconnected from the UI even though the Shell is still running after a period of days. This can happen when a user starts a long process that may prompt for use input, but they are out for the weekend and don’t see the prompt until Monday.

31

Also, you won’t see these processes in Activity Monitor - you will need to use “ps” or “top”.

32

By default they were; but there’s no guarantee that’s valid now.

In my own application which uses the code documented by Apple, so that it can perform a long task (like 40+ minutes), failed to prevent the machine from going to sleep after 5 minutes. When I returned, I expected it to be completed. I haven’t investigated it further after confirming that I’m using the right code.

There is just so much that’s broke nowadays, it’s really sad.

33

Not only sad but scary. I have helper apps which run on a headless mac mini. The GUI portion (accessed remotely) uses the app nap disable stuff but the console apps I have always treated as app nap proof. This makes me worried about ever upgrading the OS on them. I can’t let those processes be Zombied because they are not monitored frequently.

Do we know when this broke?

34

My advice would be to a) don’t upgrade this machine and b) look into alternative (and less costly solutions) in the future. Remember Xojo can target Windows, Linux and PI, none of which (AFAIK) do these “energy saving” measures. Which to be honest, I am happy Apple implemented that, but sad, they they’re just left broken.

[quote=415886:@Douglas Handy]Do we know when this broke?[/quote] I don’t to be honest. I only recently created a project that does LONG tasks, so I can’t say I ever actually the option that’s meant to stop the machine from going to sleep until this year.

35

@Christian Schmitz If app nap is disabled this way, will that also prevent the OSX screensaver from cutting in while the app is running in the foreground (doing some sort of activity) without the user interacting with either mouse or keyboard? If not, is there another way that I can prevent the screensaver from coming on?

36

If I recall right, one way to prevent screensaver from coming on, is to use a timer set to something like 30000:

Declare sub UpdateSystemActivity lib "CoreServices" (val as integer)
UpdateSystemActivity(1)