Wrinkles in Universal Control

Universal Control was one of the most generally anticipated features coming in Monterey, and one of the last to arrive. After its slightly faltering start in macOS 12.3, it seems to have been fully functional and reliable from 12.4 onwards, provided you don’t try using macOS earlier than 12.4 or iPadOS before 15.4. It also works well with Ventura betas as far as I can see.

All devices to be brought under Universal Control must be:

  • signed into the same iCloud account using the same Apple ID with two-factor authentication enabled;
  • for wireless connections, have Bluetooth, Wi-Fi and Handoff enabled, and be within 3 m (10 feet) of one another;
  • for USB connection with an iPad, the Mac must be trusted on that iPad;
  • Macs mustn’t be sharing their Internet connection, and iPads mustn’t be sharing their cellular/mobile connection.

Controls over Universal Control are simple, once you know where to look for them, as Apple has tucked them away in the Displays pane, which has a certain logic to it when you realise how it overlaps with SharePlay display sharing. Ventura’s new System Settings have a similar organisation.

univcontrol2

univcontrol1

If you have more than one Mac running Monterey or later, or work much across your Mac and iPad, Universal Control is a big advance, and sometimes I use three different pairings between Macs over the course of a single day.

Losing control

Universal Control isn’t entirely bombproof, though, and when it has had problems, mostly with early Ventura betas, they have proved an interesting challenge. The most serious has been complete loss of control when shutting down or restarting the controlled Mac.

What should happen, and almost invariably does, when you use the Controller’s pointer to shut down or restart another Mac connected via Universal Control, is that pointer and keyboard input is returned to the Controller. If that doesn’t occur, Universal Control doesn’t appear to time the disconnected Mac out, or if it does, it takes a long time to do so. So there I was, sat in front of the Controller, and the pointer and keyboard were stuck on a Mac which had just shut down.

Once the initial feeling of panic settles, think as logically as you can. The solution is actually quite simple: because Universal Control operates over Bluetooth, there’s an easy way to regain control of your trackpad without any wireless connection. Simply connect it to the Controller using its charging cable, which uses USB, and both trackpad and keyboard resume normal service with the Controller. Once that has been established, it’s safe to disconnect the charging cable and breathe a sigh of relief.

I’m very grateful to an anonymous comment below, pointing out that pressing the Control-Option-Command and Delete keys will stop all external Universal Control and return both pointer and keyboard to the Controller. That’s explained at the end of Apple’s support article on Universal Control, which of course you can’t read on your Mac until you’ve recovered its pointer and keyboard. I can vouch for this keyboard command, which I generously tested today when the same problem occurred.

I’ve not experienced any catastrophes like a kernel panic while Universally Controlling another Mac, but wouldn’t be surprised if they could have the same effect and solution.

Beeping keyboard

Another occasional phenomenon I’ve encountered when using Universal Control with a connected virtual machine (VM) appears to be the result of lost focus. When you’re controlling macOS running in a VM, you can find that each keypress results in a system beep rather than a character. This always seems to happen when entering a password, sometimes in the login window of the VM. The solution here is to bring a non-virtual window to the front, then bring the VM back to the front, which should allow normal text entry again.

Power and batteries

One invaluable use of Universal Control is when you want to use your Mac notebook with the trackpad/mouse and keyboard you normally use with your desktop Mac. Instead of having to mess around with pairing, you can just push the pointer across from the desktop to the notebook and continue working on both systems at the same time.

With the help of Sleep Aid, I have been following the effects of this combination on notebook sleep and power use. Before pushing through to use a MacBook Pro from a desktop Controller, the notebook functions as expected, sleeping readily and independently. After it has been operated using Universal Control, the additional processes required to support that remain running, even though the pointer is being used on the Controller alone.

Taking back control using the notebook’s own internal trackpad effectively turns Universal Control off again, and its support processes no longer keep the notebook awake, so its power usage returns to normal. This is also accomplished by closing the notebook’s lid, or another action which forces sleep. But, so long as Universal Control remains active on that notebook, its power consumption will remain relatively high. Universal Control is a valuable tool for many, but can have its cost on the battery.

Further reading

Apple’s complete account
Inside Universal Control, this site.