There are inconsistent behaviors in sleep/wake notification callbacks across different MacBook devices and macOS versions when the device is not connected to power, with or without external displays, entering sleep mode by closing the lid, and waking up from sleep by opening the lid.
Yes, that's basically what I'd expect to find. Indeed, it's not unusual to find a difference between machine configurations that were IDENTICAL at the hardware and system software level, due to a difference in how the system was configured and what apps were used. The core issue here is that the power management system isn't a straightforward system with fixed logic. Instead, clients throughout the system are supplying data to it while simultaneously sending requests to it and receiving commands from it. The "final" behavior is driven by how all those pieces interact, not any "fixed" logic.
I'll also note that there is a significant gap between the data our APIs provide:
When monitoring the following Objective-C notifications: NSWorkspaceScreensDidSleepNotification NSWorkspaceScreensDidWakeNotification NSWorkspaceWillSleepNotification NSWorkspaceDidWakeNotification
...and the functionality the system provides. For example, "Dark Wake" (where the system wakes up without lighting the screen) is a longstanding system behavior which the public API doesn't expose at all. Depending on how your app is set up and being run, it's also possible for an app to miss these notifications because the system chose not to run your app’s main runloop (to deliver the notification), not because the notification itself didn't occur.
These inconsistencies make it challenging to implement reliable sleep/wake detection logic across different MacBook models and macOS versions.
Yes, that's very true.
My main question here is "what are you actually trying to do"? If your only goal is to gather sleep data, then you might get slightly better data by moving to a lower level API (see QA1340), however, there will always be inconsistencies that will be hard to explain or handle.
However, if your goal isn't actually tied to sleep, then it's possible there are other API options that will work better for you.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
