Modernisation
A little background into the multi-year modernisation of Power Manager.
Three years ago, in late 2023, we launched a new Scheduler for Power Manager. The launch was the first release of a transliteration task that had begun many years before.
Despite being transliteration rather than rewriting or reimagining, mistakes and oversights made their way across into the new version. Updates since then have largely focused on fixing those mistakes, ensuring stability, and some minor improvements.
Our continuing aim is to ensure Power Manager is predictable and reliable. Power Manager seeks to remain constant and steadfast, even as the operating system shifts beneath. So making sure the Scheduler was stable before making further changes was important.
A year ago, in early 2025, we launched a new macOS status menu bar. This seemingly small change helped prove technical choices in how the user interface talked to the Scheduler.
Yesterday, we completed1 the modernisation of Power Manager with the launch of a new macOS application. The previous application launched with Power Manager 4 in 2010 and supported back to Mac OS X 10.42. The design choices we made sixteen years ago served Power Manager well. The implementation was of course improved and revised throughout the following years. It quickly became a treasure trove of hard won knowledge and methodology.
So why modernise? What changed? The need was not prompted by a single cause or failure. Little is ever so simple.
The modernisation was not driven by the development language.
Power Manager’s new macOS application is written in the same development language as the previous version, Objective-C. We have not migrated to Swift, despite the pressure to do so. The churn of the Swift language, it’s tooling, and the difficulty of supporting older versions of macOS simply do not meet Power Manager’s needs. A long lived product demands predictable tooling.
With predictable tooling in mind, we did change the development language for the Scheduler in 2023. We moved from C to Go. That change gained us an important compatibility statement and an excellent standard library. Had the Scheduler still been written in C++, I suspect we would have moved to Rust.
Modernisation was a chance to tighten security.
Security has always been a challenge. Power Manager has to be trusted and mistakes have consequences. Changes in the operating system have too often prompted significant changes in how Power Manager addresses authentication3.
Power Manager 4 delegated authentication to macOS’s Authentication.framework4 but, with the introduction of application sandboxing, the critical framework was denied5 to sandboxed applications.
Power Manager 5 switched to Pluggable Authentication Modules (PAM). PAM was able to replace the core functionality of the Authentication.framework but left messy user interface problems as Power Manager’s responsibility; applications should not be crafting their own interfaces for the inputting of user credentials.
We put the work into implementing a flexible user interface on top of PAM. Power Manager’s interface supported not only password based credentials but multi-step authentication. That solution has been in place since 2019.
With modernisation, we saw we had the opportunity to avoid needing passwords, user credentials, and secrets entirely. We could build a new approach on standards that were now widely available and trustworthy.
Yesterday’s improvements in security grasps that opportunity. Power Manager no longer prompts for user credentials or Keychain unlocks. The reduction in friction and avoidance of security prompt fatigue are huge positives. Reaching the point where this is possible is wonderful.
Driven by the improved authentication, Power Manager 5.13 moves entirely to using HTTP for interprocess communication. The existing proprietary pm protocol is deprecated6 and will be removed in a future update. Using HTTP allows Power Manager to adopt common security approaches, including Mutual Transport Layer Security (mTLS).
At least in part, modernisation was also imposed by the platform.
The platform is the ever evolving environment Power Manager operates within. Much of the functionality offered by commercial platforms, such as macOS, is proprietary and subject to change – or even removal – sometimes with little notice. For a long running product like Power Manager, the platform can become a risk. Judging the scale and exposure to that risk is our responsibility.
The modernisation of the Scheduler gave us the opportunity to isolate platform specific functionality from the agnostic core. This means separating what is specific to Mac hardware and it’s operating system, from functionality that could work on any device. The Mac specific part of the Scheduler turned out to be tiny.
So modernisation allowed us to better demarcate platform boundaries and move towards common standards not tied to any single commercial organisation.
With the new macOS application, we stuck with a well understood but legacy language and user interface framework: Objective-C and AppKit. Legacy does not mean bad but it does mean every new line written is immediately considered esoteric.
Objective-C is practically an Apple-only language and a language that Apple no longer recommends for new development. AppKit is being replaced by SwiftUI.
Power Manager’s new macOS application is focused on the unique aspects of being a Mac application. Non-interface work has been moved into the Scheduler and the macOS application has been pared back.
Today’s Power Manager macOS application is not a web view. It is not HTML rendered to look like a Mac application. It is a Mac application, albeit an oddball application, just like the application it replaces.
Power Manager started life in 1997 as a Control Panel on System 7, transformed in a Preference Panel7 for OS X, and transformed again into an application.
Yesterday’s update has further transformed Power Manager’s macOS application. This update adds support for multiple event editor windows and introduces a new editor.
The new event editor has been a hard problem to solve.
We know that many customers never venture beyond the Schedule Assistant. The jump in complexity from the Schedule Assistant to editor was too great. Power Manager is incredibly capable but at the cost of being overwhelming when all the options are revealed.
Our focus with the new editor is to bridge the gap from creating events using the Schedule Assistant to editing your events in the editor.
The editor can represent any arbitrary event – at least within reason, as editor limits do exist. If you encounter these limits, get in touch, but expect to be told that the event’s approach should be reconsidered or sub-divided.
Choosing what to maintain and what to modernise is difficult.
There are few Mac only applications that have lasted as long as Power Manager. It is not alone but it is increasingly rarefied. This modernisation ensures Power Manager will remain around for years to come.
As the latest update to Power Manager rolls out, the guide and reference material are being updated. Given the decades of material that needs revising, I hope you will forgive our incremental approach.
Thank you for continued support. We are lucky to have so many great customers.
Is modernisation really complete if we still use
perlscripts during the build? These scripts are in the queue of tasks to update. ↩︎Mac OS X 10.4, aka Tiger, launched in 29th April 2005. ↩︎
We also got burnt with authorisation changes in the operating system, but only once. ↩︎
The original macOS Authentication.framework, not Apple’s replacement Single-Sign On for Enterprise focused framework. ↩︎
A decision that we will forever question. ↩︎
The
pmprotocol is available via Application Layer Protocol Negotiation (ALPN) during the TLS negotiation. ↩︎Power Manager’s Preference Panel had undo support decades ago. Why is undo support still not implemented in today’s System Settings?! ↩︎