Macs have always been driven by events. When the largest network that most Macs saw, amounted to one or two other computers and a laser printer, almost all those events were generated by the user, with mouse and keyboard.

Our phones, of course, are almost entirely driven by events other than us: a call comes in, a calendar reminder pops up, new mail arrives, and we’ve got several tweets to catch up on. Macs are currently somewhere in between where they used to be, and more immediate devices like iPhones. Keeping them in a happy medium is not always easy, but essential if you also want to get on with work, or something else.

Notification modes

User notifications started with simple system beeps and modal alerts. They were fine when only one thing was happening at a time, but as our Macs (and we?) became more multi-tasking, something more sophisticated was needed. That is now the elaborate system of local and remote notifications, centred on the Notifications drawer at the right of the screen, and the pane in System Preferences of the same name.

Apps and other services have access to a range of modes for alerting us of their notifications. These currently include:

• Traditional alerts, either in a drop-down sheet or a separate window, when the app is running.
• New-style alerts which appear in a separate window, and stay on screen until we dismiss them.
• Banners, lightweight alerts which appear in the top right of the screen, and go away automatically.
• Entries in the Notification Centre drawer at the right of the screen.
• Sound alerts.
• Dock icon badges, such as counters.
• Bouncing dock icons and other effects.

No doubt with the advent of augmented and virtual reality, this vocabulary of notifications will expand in innovative ways.

There are two levels at which you control notifications through its pane in System Preferences: globally, and per-app. Each app which is registered with the Notification Centre has settings in which you control their alert style and extent, and the Do Not Disturb item at the top of the app list enables you to hide and silence the whole lot when you wish.

There’s one other pane which has an important bearing on what you may not get notified about: downloaded updates from the App Store. Its pane sets when your Mac will download and/or install app and macOS updates automatically, for example. Every user should enable the option to Install system data files and security updates, though, as that allows Apple to push out enhancements to your Mac’s security protection, such as Gatekeeper, XProtect, and MRT. Without those, your Mac would quickly fall behind and remain vulnerable to security threats.

Internals

This notifications system is not built on a traditional Unix architecture: there are no config files, command tools, and Terminal wizardry which you can use to achieve fine control. Instead it is built into complex and largely undocumented parts of macOS. I have been unable to discover any command line tool which does anything useful with notifications, unless you know of any.

If you want to read about how apps and their developers interface with both local and remote forms of notification, Apple’s manual is well-maintained and covers its other operating systems in gory detail.

There is a fundamental difference between local notifications, which are made by local apps via macOS to the same Mac, and remote notifications, which are pushed from remote servers over the internet with the help of the Apple Push Notification service (APNs).

Local notifications are the simpler. An app configures an intended notification when it is running, and passes that to macOS to handle. These can even include custom sounds, for example. Each notification is then passed to the Notification Centre, with details of when the notification is to be presented to the user. If the app is running, it can then handle any user responses, as appropriate.

Remote notifications have to be set up by an app before they can happen, and the app should normally ensure that you know what you are signing up to, and give your explicit consent (something all too often downplayed or glossed over). The app then has to register with APNs, and send a device-specific token from that to the remote server which is going to push notifications through APNs to that Mac. When the remote notifications are pushed back to the Mac, the app needs to be ready to receive and handle them.

Remote notifications are much less commonly encountered than local ones.

In macOS, for an app to handle a remote notification, or to handle your response to its scheduled local notification, the app or a component from it needs to be running at the time. If that app is not running, the notification will still be displayed, but it will not be processed by that app until the app has been opened.

This doesn’t apply to macOS itself, of course, which is always running unless your Mac is asleep or shut down.

Problems and solutions

There are several concerns that arise with notifications, other than their potentially disruptive effects.

Accepting pushed notifications from external servers relies on a series of stringent security precautions. Although Apple has strict conditions which it imposes on such servers, there may come the time when an external push server is compromised, much in the way that other vendors’ servers have been in the recent past. The prospect of malware being pushed at large numbers of Macs (or other devices) is too horrible even to contemplate, but relies on Apple’s security precautions remaining fully effective.

For example, it is well known that one or two vendors of security certificates are not as stringent in their use as they might be. To ensure that there is no risk of those easily-abused certificates from becoming involved in pushing malware, Apple requires servers working with APNs to install a specific class of certificate from a specific vendor. The third-party provider and Apple’s APNs then work in tandem to guarantee and deliver the pushed notification.

Apple currently only makes APNs available to apps distributed through its own stores, and to enterprise apps. However, those vendors can also use the remote notification system with APNs to deliver updates silently, at least on iOS.

This explains why remote notifications are much less common than local ones.

The controls provided over notifications are straightforward, but very limited, and offer little to help the advanced user or system administrator. Notifications can and do get stuck, or fail, and the App Store app has suffered repeated problems with displaying an incorrect Dock badge, etc. Other than restarting, rummaging through the log, or twiddling with the few controls in the pane, there seems little or nothing to be done. And apart from Do Not Disturb, the user is given no controls over macOS’s use of notifications, and often little choice over pushed updates.

Perhaps it is macOS that is really in charge after all.