With extended running time on battery and fast charging, your MacBook Air or MacBook Pro probably doesn’t spend long on mains (AC) power. What you may not have realised is that it does require mains power to perform some tasks, so there are benefits to periodically leaving it awake and running when connected to a mains power supply, to allow it time to catch up on those. This article examines the benefits.

Background tasks

If you look through the property lists used for macOS LaunchDaemons and LaunchAgents you’ll come across two keys used for their activities and background services that determine whether they run when powered by battery alone:

• AllowBattery is set to true when the service can be run on battery, or to false when it can’t;
• RequiresExternalPower, its converse, is set to true when it can’t be run on battery, or to false when it can.

Unfortunately Apple doesn’t explain either of these, and they’re omitted from the last systematic account of those property lists, which was last revised ten years ago. Neither are they mentioned in man launchd.plist. There is evidence, though, that they may not both apply to macOS. For XPC activities there’s a global variable XPC_ACTIVITY_ALLOW_BATTERY, whose default value is false for activities with a maintenance priority, but is true for utility priority activities. However, requiresExternalPower is normally used for Background Tasks in iOS/iPadOS/etc., and thus doesn’t appear to apply to macOS. Clear, up to date documentation would be very helpful, please, Apple.

Of the 878 property lists in /System/Library/LaunchAgents and LaunchDaemons in macOS 26.5, 47 set a value for the AllowBattery key, and many more assign maintenance priority to activities. Among the activities and services that appear unlikely to run when on battery alone are:

• com.apple.corespotlightd.updateContacts in corespotlightd, which presumably updates search information for Contacts’ database;
• com.apple.calendar.daemon.databasecleanup, performing maintenance on Calendar databases;
• com.apple.cloudphotod.maintenance, performing maintenance on iCloudPhotos;
• com.apple.photoanalysisd.backgroundanalysis and several other photoanalysisd services, used to analyse media content, particularly for indexing by Spotlight;
• com.apple.photolibraryd.periodicmaintenance, performing maintenance on Photos libraries;
• com.apple.Safari.SafeBrowsing.BrowsingDatabases.Update, updating Safari’s Safe Browsing databases.

Of these the most noticeable are photoanalysisd services, which can flood the E cores when a laptop Mac is left connected to mains power, particularly when many images have been added or modified since the last session on mains. Those can in turn trigger copious Spotlight indexing activity with mds and related processes.

XProtect Remediator

Regular scans performed by XProtect Remediator (XPR) to detect and remove known malicious software can busy a whole E core for well over half an hour, and are accompanied by intense disk activity. Because of that, some of its services will only be run when a Mac is powered by mains.

Current property lists in XPR call for three types of scan:

• Fast scan, run every 6 hours, when AllowBattery is set to true;
• Regular scan limited by a timer, run every 24 hours, AllowBattery false;
• Slow scan without any time limit, run every 7 days, AllowBattery false.

You should therefore expect daily XPR scans only to take place when your laptop is awake and connected to power. Fast scans don’t result in any of the distinctive reports from scan modules that are checked by utilities like XProCheck and SilentKnight, and appear to pass unrecorded in the log.

You can observe this yourself after starting your Mac up for the day. If it’s running on mains power and left alone for 10-15 minutes, XPR will usually start scanning with each of its modules. However, if you start your Mac up on battery and leave it for a couple of hours, there’s no sign of those scans starting.

Sparse bundles

Sparse bundles (disk images that store files inside a bundle folder rather than in a single file) need to be compacted occasionally to ensure they don’t grow larger than they need. Because compaction can take a long time and can’t be interrupted without risking the whole sparse bundle’s contents, by default it won’t be performed when a Mac is running on battery power. That can be overridden in some utilities like my own Spundle, and in the hdiutil command.

Catching up

If your MacBook Air or Pro spends much of its waking life running on battery, it’s a good idea to give it a break every few days by leaving it awake and powered from its mains adaptor for an hour or two. How often you should do that is more flexible. If you like to run a regular routine, scheduling it every 2-3 days should be sufficient, with a minimum frequency of once a week. An ideal routine for a laptop in frequent heavy use might be for a daily break at lunchtime.

If you want to tailor this more to demand, observe how long your laptop is running heavy loads from photoanalysisd and others when it’s taking a break on mains power, and adjust the frequency of those breaks until those periods of heavy load are sufficiently brief to fit in with your schedule.

These will also ensure your Mac gets at least one complete scan by XProtect Remediator each week.

I’m grateful once again to Michele for raising this question.

In my review of macOS virtualisation on Apple silicon, I quoted performance figures that were obtained some time ago, and didn’t consider minimum specifications for a usable VM. Given current interest in running a VM on a MacBook Neo, I thought it would be worth examining these afresh, from macOS Tahoe.

How fast?

Using the same host, a Mac mini M4 Pro, this time running macOS 26.4.1 on its 14 cores (10 P + 4 E) with 48 GB RAM and a 2 TB internal SSD, Geekbench 6.7.1 scores are slightly faster, on both the host and a guest given 5 virtual cores and 16 GB of virtual RAM:

• single-core CPU VM 3,855, host 3,948
• multi-core CPU VM 13,222, host 23,342
• GPU Metal VM 106,896, host 111,970
• Neural engine CoreML VM 5,291, 8,577, 6,877; host 5,973, 41,251, 56,616

The last of those gives single precision, half-precision and quantised test results, in that order.

Comparing CPU single-core figures, the VM runs effectively at 98% of the speed of the host. Comparison between the multi-core CPU results is difficult, as the host has more than twice the number of cores, although four of them are E cores. However, given that the host has twice the number of P cores alone, the VM appears to perform rather better than the host on this test.

GPU performance isn’t quite as good, with the VM delivering performance of 95% of that of the host, when the latter isn’t contending for the GPU as well.

The only real disappointment here is the virtual neural engine, which performs far slower than the host on half-precision and quantised tests. We might hope that macOS would process AI tasks using the CPU and GPU rather than the neural engine, when running in a VM.

How small?

With the arrival of the MacBook Neo, some wondered whether it would be able to run VMs. While there’s no doubt it should make a good host for Linux, I doubted whether it would be able to do anything useful with macOS in a VM. I was wrong.

To assess how small a macOS VM could be, I ran the same VM of macOS 26.4.1 on progressively smaller CPU core and memory allocations, using my virtualiser Viable. The VM’s display window was set to a standard 1600 x 1000, and I ran Safari through its paces and performed some lightweight everyday tasks, including Storage analysis in Settings.

Starting with 4 virtual cores and 8 GB vRAM, where the VM ran perfectly briskly with around 5 GB of memory used, I stepped down to 3 cores and 6 GB, to discover that memory usage fell to 3.9 GB and everything worked well. With just 2 cores and 4 GB of memory only 3.1 GB of that was used, and the VM continued to handle those lightweight tasks normally.

The only thing to be careful of when creating VMs on Macs with small internal SSDs is their size. Any macOS VM significantly smaller than 50 GB isn’t going to be able to update its macOS, and for comfort and safety you should aim for at least 60 GB. Fortunately, APFS comes to your aid here, as VMs are stored as sparse files, and a basic 100 GB VM should only require about 54 GB on disk. That would be better accommodated on the MacBook Neo with a 512 GB SSD.

Although not the place to try running your LLM, a macOS VM given only 2 virtual cores and 4 GB of memory, as should be feasible in a MacBook Neo, is thoroughly usable and capable of everyday tasks. Bring on the Neos!