Apple is a famously tight-knit business. Its press releases and media conferences routinely drum the integration of hardware, software, and services as something only Apple is capable of doing. So it sticks out when features feel like they were developed by people who do not know what another part of the company is doing. This happened to me twice in the past week.
Several years ago, Apple added a very nice quality-of-life improvement to the Mac operating system: software installers began offering to delete themselves after they had done their job. This was a good idea.
In the ensuing years, Apple made some other changes to MacOS in an effort to — it says — improve privacy and security. One of the new rules it imposed was requiring the user to grant apps specific permission to access certain folders; another was a requirement to allow one app to modify or delete another.
And, so, when I installed an application earlier this month, I was shown an out-of-context dialog at the end of the process asking for access to my Downloads folder. I granted it. Then I got a notification that the Installer app was blocked from modifying or deleting another file. To change it, I had to open System Settings, toggle the switch, enter my password, and then I was prompted to restart the Installer application — but it seemed to delete itself just fine without my doing so.
This is a built-in feature, triggered by where the installer has been downloaded, using an Apple-provided installation packaging system.1 But it is stymied by a different set of system rules and unexpected permissions requests.
Another oddity is in Apple’s two-factor authentication system. Because Apple controls so much about its platforms, authentication codes are delivered through a system prompt on trusted devices. Preceding the code is a notification informing the user their “Apple Account is being used to sign in”, and it includes a map of where that is.
This map is geolocated based on the device’s IP address, which can be inaccurate for many reasons — something Apple discloses in its documentation:
This location is based on the new device’s IP address and might reflect the network that it’s connected to, rather than the exact physical location. If you know that you’re the person trying to sign in but don’t recognize the location, you can still tap Allow and view the verification code.
It turns out one of the reasons the network might think you are located somewhere other than where you are is because you may be using iCloud Private Relay. Even if you have set it to “maintain general location”, it can sometimes be incredibly inaccurate. I was alarmed to see a recent attempt from Toronto when I was trying to sign into iCloud at home in Calgary — a difference of over 3,000 kilometres.
The map gives me an impression of precision and security. But if it is made less accurate in part because of a feature Apple created and markets, it is misleading and — at times — a cause of momentary anxiety.
What is more, Safari supports automatically filling authentication codes delivered by text message. Apple’s own codes, though, cannot be automatically filled.
These are small things — barely worth the bug report. They also show how features introduced one year are subverted by those added later, almost like nobody is keeping track of all of the different capabilities in Apple’s platforms. I am sure there are more examples; these are just the ones which happened in the past week, and which I have been thinking about. They expose little cracks in what is supposed to be a tight, coherent package of software.
-
Thanks to Keir Ansell for tracking down this documentation for me. ↥︎