What this work needed to become.
NoSleep controls macOS power-management assertions while keeping display and system behavior separate. A user can keep the Mac awake without automatically forcing the display to stay on.
The interface is small, but the controller behind it must handle timers, sleep and wake events, charger changes, application lifecycle, and failure cleanup predictably.
The hard part was in the edges.
A naïve keep-awake implementation can leak assertions, ignore battery conditions, or leave the interface showing a session that no longer matches system state.
The product needed to make the safe choice by default and recover cleanly when power conditions or operating-system state changed.
Constraints that shaped the solution
- System and display sleep must remain independently controllable.
- Assertions must be released on stop, deinitialization, and failure paths.
- Indefinite battery sessions need stronger safeguards than short timed sessions.
- Notifications and launch-at-login should use native macOS services.
Choices made explicit.
The implementation follows from these boundaries. Each choice solves one problem while accepting a clear trade-off.
Use separate IOKit assertions
NoIdleSleep and NoDisplaySleep assertions are managed independently so the default session preserves display sleep.
Centralize session state
One controller owns timers, assertion handles, wake behavior, and stop conditions to keep UI and operating-system state aligned.
Make battery policy explicit
Indefinite sessions are blocked on battery by default, timed sessions warn, and low battery can stop a session at the configured threshold.
Test the state transitions
The current repository has 47 named unit tests across six files, concentrating on controller, policy, and state behavior.
Useful, shipped, and honest about its limits.
Version 1.0 is distributed as a macOS application and through a Homebrew cask. The release source and current repository are aligned.
The project demonstrates a useful principle: a small product deserves serious lifecycle and failure handling when it touches system behavior.
What I would carry forward.
Automated tests are valuable, but system utilities also need repeatable manual checks across sleep, wake, charger, notification, and menu-bar behavior.
Future work should add those smoke-test steps to release documentation and complete the public licensing and notarization story.