Over the last week or so, it has become apparent – and Apple has admitted it – that iOS controls device performance in a way that could appear to disadvantage those using older models with older, worn-out, batteries.

John Poole’s posting about this was prompted by discussion on Reddit, and quickly became headline news. Poole based his account on kernel density plots, a reasonably sophisticated statistical method of looking at random variables, of the device’s Geekbench 4 benchmark scores.

Looking across different iPhone models, he demonstrated visible differences between iPhone 6s running iOS 10.2.0 and 11.2.0. These indicate that, when running more recent versions of iOS, Geekbench 4 scores were distributed unevenly, with a total of five peaks in their score. In other words, iOS 11.2.0 was often running iPhone 6s at any of four significantly lower performance levels.

The same analysis applied to iPhone 7 showed a reduced effect, with those additional peaks only starting to appear with iOS 11.2, and (unlike the iPhone 6s) no visible change until after iOS 11.1.2.

The tempting conclusion, to which everyone seems to have jumped, was that Apple had rigged iOS to deliberately degrade the performance of older iPhones, and possibly iPads too.

Apple admitted, surprisingly quickly, that it had released “a feature for iPhone 6, iPhone 6s and iPhone SE to smooth out the instantaneous peaks” in battery demand “only when needed to prevent the device from unexpectedly shutting down” in cold conditions, when it has a low battery charge, or as its battery ages over time.

This was specifically to address a problem of unexpected shutdowns which many users had been reporting on iPhone 6, 6s, and SE, and does not of itself explain Poole’s observations on the iPhone 7.

To anyone who is familiar with Apple’s approach to energy management, none of this should be surprising. Nor would it be for MacBook/Air/Pro models built over the last five years or more, since Apple started using processors with variable clock speeds.

Over that period, Apple has developed far-reaching systems for monitoring the internal environment of its computers and devices, in what is termed CoreDuet, or sometimes simply Duet. Although almost all of this is kept in private frameworks and services, and meticulously undocumented, Apple has provided its developers with a brief glimpse in its Energy Efficiency Guide for Mac Apps, one of its most up-to-date and best-maintained developer guides.

Processor speed is a crude control in this system. Working with other systems such as the Duet Activity Scheduler (DAS), Duet influences the execution of background and scheduled tasks, of which the most obvious is the making of Time Machine backups.

Many of us still go around with a naïve concept that our Mac’s processor cores simply run our apps’ code as quickly as their clock permits, time-slicing through a handful of other tasks like the kernel as required. A little study of what goes on in Activity Monitor, and in scheduling systems such as DAS and the sibling Centralized Task Scheduling (CTS), shows that much of the workload on our Macs is carefully controlled not by us, but by macOS. If you have ever had mdworker choke on a troublesome file, you’ll know exactly what this means.

Apple has ample opportunity to modulate the performance of macOS and iOS systems, in ways which are far harder to detect than merely changing the effective clock speed of processors.

Although I am not suggesting for a moment that it has done, does, or even would, it could, for example, degrade the performance of products competing with its own, or selectively slow older Macs so as to encourage users to replace them with new. In fact, developers who follow the recommendations in its Energy Efficiency Guide are for the most part handing over more control of their app’s performance to Duet and its associates.

At the moment, all this comes down to trust. As Mac users, supporters, and developers we either have to trust Apple to use these features to our benefit, or quit the platform for one which we can trust.

Given the events of the past year – gaping security vulnerabilities, fumbled High Sierra launch, rampant bugs in key tools, and limitations of APFS to think of just a few – this is probably not an ideal time for Apple to put that trust to any sort of test.

An easy solution would be for Apple to make (Core)Duet and other performance-modulating systems open source, or to document them so thoroughly that we can all see what they do and how they do it. Given the work that has gone into their development, and their importance in iOS and macOS now, I think that is never going to happen.

Whatever Apple does, it is going to have to be more transparent about what it likes to call ‘energy management’, which in many cases is actually perceived by the user as ‘performance management’ – words with often painful associations. This won’t be the last time that someone raises the spectre of intentional degradation of performance, I’m sure.