I thought I was out of the woods in setting up new Apple Silicon test macOS systems, after finally working around a Sequoia bug to get old versions of macOS to install on an external drive. Then Apple released the first beta for macOS 15.5, and I found that I couldn’t update to it.
After I agreed to the license and entered my password for software update, it would fail saying, “User interaction required. An error occurred while installing the selected updates.” I’ve had lots of problems with the Software Update pane of System Settings in recent years, but the command-line tool had always worked. So I tried sudo softwareupdate -irR, but that also kept failing, saying: “Failed to authenticate.”
This seems to have been caused by a problem with the LocalPolicy. I was aware that ownership is an issue with Apple Silicon Macs, but it had never really caused problems for me before. I would just enter the requested information for a prior account when installing macOS, and it seemed to all just work, albeit with some annoying extra steps.
This external Sequoia drive that I was trying to update to macOS 15.5 had been originally created using a different Apple Silicon Mac, so in retrospect it makes sense that the owner information wouldn’t be right for the Mac where I was trying to do the update. But this never occurred to me because the Mac was able to boot from the drive just fine. Apparently, the owner account is not necessary for booting but is necessary for updating.
A visible symptom of ownership problems seems to be that the Mac won’t auto-boot from the drive. It will either boot from the internal drive or take you to the startup manager. I didn’t notice this because I had been intentionally switching back and forth between different boot drives, always holding down the power key and selecting the drive using the startup manager.
I happened to boot into macOS Recovery and look in the Startup Security Utility, and I saw that it did not have access to change the security policy for the external drive. In order to do that, it said I had to set the drive as the startup disk. This kind of didn’t make sense because don’t the security options get set when booted from Recovery?
Anyway, I went to the Apple menu and chose Startup Disk and clicked on the external drive. Then I went back to Startup Security Utility and nothing seemed to have changed. OK, maybe I have to restart and it will use the Recovery from the newly selected startup disk? So I did that but ended up in the same place. It was still acting as though the external drive wasn’t the startup disk, even though I had selected it.
Maybe the startup disk will stick if I click the Restart button that’s in the Startup Disk window? That turned out to be the key. When I clicked the button, it showed this error:
This volume does not have any authorized users for this computer.
The selected system does not have any users that are authorized to administer this computer. You can continue to try to set the startup disk but some features such as software updates will not be functional. If you know the password of one or more users on this system you may authorize the users by clicking on
“Authorize Users…”
I don’t know why software update couldn’t tell me this or why there is seemingly no direct GUI command to view or edit the authorized users. But restarting from within Startup Disk is apparently the way to get macOS to offer to fix the LocalPolicy. Once I added the user, I was able to do a normal boot from the external drive and software update normally.
Previously:
Mac macOS 15 Sequoia macOS Recovery Security Software Update Startup Disk Startup Security Utility Storage
Howard Oakley:
App extensions, appexes, have become plentiful and widely used by macOS and third-party software, yet discovering and controlling them is patchy and limited. The most coherent access is in System Settings > General > Login Items & Extensions, where some are gathered in the list of Extensions at the end. Others like Safari extensions are controlled in app settings, while most remain hidden out of sight.
To take stock of all these appexes, I turned to the pluginkit command tool, but the lists it generates are seemingly ordered at random, and so extensive that it would require some serious scripting to make any sense. Instead, it’s easier and more effective to put together a little app to do that. So I present you with AppexIndexer, an exploratory utility that displays key information about all appexes recognised by macOS.
Previously:
AppexIndexer Extensions Mac Mac App macOS 15 Sequoia
Atilla (via Chris Turner, Reddit):
A Bauhaus-inspired clock screensaver for Mac, designed to be present even when you’re not.
Watch precision meets digital aesthetics, enhancing your workspace even when you’re away.
$19 for lifetime upgrades.
Previously:
Mac Mac App macOS 15 Sequoia Screensaver Time
Jen Simmons:
Support for text-wrap: pretty just shipped in Safari Technology Preview, bringing an unprecedented level of polish to typography on the web.
[…]
Now, the web has the ability to evaluate the whole passage of text when figuring out where best to wrap. You can ask browsers to do this by using text-wrap: pretty. WebKit is not the first browser engine to implement, but we are the first browser to use it to evaluate and adjust the entire paragraph. And we are the first browser to use it to improve rag. We chose to take a more comprehensive approach in our implementation because we want you to be able to use this CSS to make your text easier to read and softer on the eyes, to provide your users with better readability and accessibility.
[…]
While support for pretty shipped in Chrome 117, Edge 177, and Opera 103 in Fall 2023, and Samsung Internet 24 in 2024, the Chromium version is more limited in what it accomplishes. According to an article by the Chrome team, Chromium only makes adjustments to the last four lines of a paragraph. It’s focused on preventing short last lines. It also adjusts hyphenation if consecutive hyphenated lines appear at the end of a paragraph.
[…]
Perf concerns emerge as the pretty algorithm takes more and more lines into consideration as it calculates what to do. In WebKit-based browsers or apps, your text element would need to be many hundreds or thousands of lines long to see a performance hit — and that kind of content is unusual on the web. If your content is broken up into typical-length paragraphs, then you have no reason to worry.
[…]
Basically, the text-wrap: balance rule tells the browser to wrap in such places to make every line be about the same length as the others. I think of it like folding a piece of paper into halves, or thirds, or quarters.
Stephanie Stimac (via ktguru):
With text-wrap: balance;, because there’s a limit to how many lines the browser will wrap, this should only be used on headlines, headings, and subheadings. Applying it to large paragraphs will have no effect and comes at a performance cost because the browser is trying to calculate optimal balance even though it won’t apply anything.
John Gruber (Mastodon):
I have mixed feelings about the results. Here are saved PDFs showing the rendering of my “How Many New iPhones Can Fit on a Freight Plane?” article from earlier today: first with traditional text-wrap: auto line wrapping, and second with WebKit’s new text-wrap: pretty in STP 216. Looking at each paragraph by itself, there’s no question this new layout algorithm is, well, prettier. The problem I see is going from one paragraph to another. Within a paragraph, WebKit’s new pretty wrapping definitely makes lines a more uniform width. But in some cases it so narrows an entire paragraph that it makes going from one paragraph to the next jarring. Line-to-line the new algorithm looks better, but paragraph-to-paragraph I think it looks worse.
CSS iOS iOS 18 Mac macOS 15 Sequoia Safari Typography WebKit
