Howard Oakley:

Now move the pointer to the right edge of the list of folder contents, just far enough to the left to avoid moving the window divider, but not so far as to fully select items from within that folder. Click there and the item will be selected, but in grey, the same as would appear if it had been fully selected but its window was no longer in focus. At this stage, the original folder will still be fully highlighted, as if nothing had been selected inside it, but you can drag that grey unfocussed selection to include other items inside the folder.

On my Mac, if I click on a file icon in the second column, the first column retains focus. The second column only gets focus if I click on a filename (or even farther to the right).

Now using the up and down arrow keys doesn’t move within the items inside that folder, but back with the fully highlighted folder. With a few of the items inside that folder in grey, so they’re selected but not in focus, press the spacebar for a QuickLook preview, and you’ll see the greyed items, not the folder that’s still fully selected to the left.

[…]

In other situations, this becomes infuriating.

In my log browser LogUI, separation of selection from focus can leave you clicking wildly without being able to select log entries.

Previously:

• Tahoe Broke Resizing Finder Column View
• Viewing Metadata in the Finder
• Mojave Finder’s Preview Column Shouldn’t Prioritize Thumbnail Size

Update (2026-10-21): Philip Savoulidis:

I too was wondering if there was something peculiar with my Mac. Focus seems so broken in Golden Gate that I was expecting macOS reviews to mention it. In this regard, I am glad to see focus problems mentioned here.

The behaviour seems inconsistent. For example, in Finder and Mail the sidebar does not gain focus on click, but it does in Contacts and NetNewsWire (a third-party app). The Passwords app seems like the worst offender: the password list itself does not gain focus on click (e.g. click the search field then click an item and focus remains in the search field).

I spent some time investigating this, and I think it comes down to a SwiftUI bug. List and Table in SwiftUI are affected. Both use NSTableView under the hood, but they never become first responder on click.

But I don’t think NSBrowser is built on SwiftUI, so there are probably multiple issues here.

Artem Novichkov (via Fatbobman):

Xcode also ships two command-line tools for the new format:

• xcprojformatter came with the format in beta 2. It’s a formatter for project files, like swift-format for code: it checks that a project.xcproj file is valid and rewrites it with sorted keys and consistent layout.
• xcodeproj arrived in beta 3. It reads and edits projects from the terminal: targets, build phases, groups, build settings, xcconfig files, and Swift packages.

Neither is on your PATH, so run them with xcrun.

Previously:

• Xcode’s New .xcproj Files Are JSON

Seth Willits (2024, bug):

There’s a deprecation warning in Xcode for URL.path that reads:

WARNING: path will be deprecated in a future version of macOS: Use path(percentEncoded:) instead

The problem is something like this:

Bundle.main.url(forAuxiliaryExecutable: "tool")!.path

… which returns the expected file path (ex: /Applications/MyApp.app/Contents/tool)

would be quickly rewritten as suggested to:

Bundle.main.url(forAuxiliaryExecutable: "tool")!.path(percentEncoded: false)

… which simply returns tool, because the URL returned is relative to a base URL.

[…]

I’ve always found it not-completely-obvious to newcomers how to get a standard file path string from a file URL and this only makes it more confusing.

There are at least three issues here:

1. url.path returns an absolute path, but url.path(percentEncoded: false) returned a relative path as of his writing. I tested this on macOS 26, and now it returns an absolute path. The documentation now says, “This function will resolve against the base URL.” It seems the behavior of the method changed without it being documented when, so be careful if you’re deploying to a mix of OS versions.

2. percentEncoded has a default value of true, whereas path did not return an encoded string. In other words, url.path() and url.path are completely different. So this is another case where Apple updated the API but flipped the default—a good way to introduce bugs.

3. It’s not obvious how to get the full file system path out of a URL. With NSURL, url.path was natural and did the right thing. Now, the URL equivalent is deprecated.

   The natural replacement, url.path(), is wrong. So is Xcode’s recommendation of url.(percentEncoded: false).

   url.absoluteURL.path(percentEncoded: false) is correct but verbose.

   url.absoluteURL.standardizedFileURL.path(percentEncoded: false) is possibly better but even more verbose.

   FilePath(url)?.string uses a newer API but gives you an optional, even though for a file URL it should never fail.

   This seems like such basic functionality, but there’s no API that’s the obvious right choice, concise, and ergonomic.

Previously:

• The Switch From File Paths to URLs
• Swift URL Improvements at WWDC 2022
• Proposed Foundation URL Improvements
• URL Path Retrieval Cheat Sheet
• NSURL Path Handling

Giovanni Colantonio:

Seven years later, Apple Arcade hasn’t gone anywhere, and Apple itself hasn’t slowed its broader gaming efforts either. Between courting major publishers like Capcom to release their games on Mac to launching a proper gaming app, it’s clear that Apple still has its sights set on being a major player.

The latest example of that came this week as Apple launched an App Store event dubbed Indie Games Week. The week-long initiative saw Apple welcoming games like Vampire Crawlers to iOS and announcing an ambitious mobile version of No Man’s Sky. At the center of that push was Carson Oliver, the new head of App Store Worldwide following Phil Schiller’s sudden departure from the role this past August. The fact that one of his first acts in the role was spearheading an indie gaming showcase hints at where Oliver’s priorities might lie.

[…]

While Oliver sells the narrative with carefully worded precision, questions still linger around Apple’s wider gaming efforts. Continued investment in mixed reality gaming is uncertain given that Apple has reportedly cut down production of its Vision Pro headset due to underwhelming sales. And though Apple continues to court publishers and get games on iOS, we haven’t seen the full-throated support from major players like Capcom and Ubisoft in 2026 that was crucial to raising Apple’s gaming profile in 2023.

Previously:

• Apple TV 4K 2026
• App Store Moves From Phil Schiller to Eddy Cue
• Apple Games App
• Testimony on External Purchase Fee and Scare Screens
• App Store Business Reorg
• Monument Valley 3 in Netflix Games
• Inside Apple Arcade
• Hearing for Apple Violating Epic’s Injunction
• Apple Arcade’s Uncertain Future
• Apple’s Mac Gaming Push

Brent Simmons:

We’ve released NetNewsWire 7.2 for Mac with a new column view layout: choose View > Use Column Layout to switch.

I really missed this feature from the old NetNewsWire, so I was happy to see its return. Now that I’m using it, I have mixed feelings. I love the columns, how I can scan the titles without the feed names and dates getting in the way. But some titles aren’t very informative, so I miss how the iOS-style view shows a little preview of the article’s body. I wish I could see that, either appended after the title itself or in a second line below it.

We’ve also added a second long-requested feature: you can now hide unread counts or replace them with a •, so you don’t have to deal with the anxiety of an ever-increasing unread count and the feeling like you have to get caught up.

Here are the other changes.

Previously:

• NetNewsWire 7.1

DropDMG 3.7.2 is a maintenance update of my app for disk images and archives.

• It still works back to macOS 10.13, but this will probably be the last such release. There’s no reason the code can’t continue to run there, but soon I will be switching to Xcode 27, which deploys back to macOS 12.

• From some reason, this build was hard to submit to the Mac App Store. altool kept retrying, or something, right at the end of the upload. There’s usually a delay before a build shows up in App Store Connect, but this time I saw it there before altool had finished running.

• I also ran into trouble submitting the app for review. It kept showing a spinner or reporting errors when I tried to save the build, and also when adding it for review.

• The actual review was pretty quick by modern standards—three days including a weekend. It warned me ahead of time that review “can take up to 48 hours.”

• When I was approving the build for release, it asked if I was “enjoying” App Store Connect and wanted me to rate the app.

Previously:

• Ending the Golden Era for Backward-Compatible Apps
• Mac App Store Review Times Increasing
• DropDMG 3.7.1

Apple (xip, downloads):

Xcode 27.1 includes Swift 6.4 and SDKs for iOS 27.1, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27. Xcode 27.1 supports on-device debugging in iOS 17 and later, tvOS 17 and later, watchOS 10 and later, and visionOS. Xcode 27.1 requires a Mac running macOS Tahoe 26.6 or later.

Christian Beer:

You can’t run macOS UI tests on Xcode cloud as soon as your app uses „restricted entitlements“[…]

Previously:

• Jumping to 27.2
• Xcode 27
• Developing for iPhone Duo

Glenn Fleishman:

The odds of this change in standards causing a security breach and your messages being exposed seem unlikely, at least right now. But after scrolling through conversations and seeing what’s going on, I feel Apple has omitted important signals for users when iMessage suddenly stops being used during a conversation.

[…]

The impact of that hit me while revising my book: when iMessage isn’t available, Apple tells you only inline. Despite all the information Messages displays about iMessage being encrypted, the inverse state is faint. This kind of negative knowledge, or information about something not happening, can often be as important as something that does happen. A warning about a fuel tank approaching empty is the kind of information every driver (or pilot) needs, for instance. If you think end-to-end encryption—or Apple-based encryption—is critical for you, then a pop-up message or other warning is what you would expect.

[…]

If you’d like to prevent Messages from downgrading security, you have options, although they may not be fully desirable. All of these are managed on an iPhone at Settings: Apps: Messages. You can’t control these message settings from an iPad or Mac.

This recently happened to my mother, and it was very confusing for her. For unknown reasons, while at home on Wi-Fi, she got signed out of iMessage. But it was not clear to her that this had happened or that she should try to sign back in. She was not aware that the Messages app supports multiple protocols or what the different bubble colors mean. All she noticed was that certain messages (e.g. ones sharing files) would no longer send and that she was not receiving some of the messages that people were sending to her. She saw the inline warning about encryption and interpreted it as that the sender was using a newer form of encryption that her phone didn’t support, so maybe she needed to upgrade.

I went over to take a look and quickly figured out that she was signed out of iMessage, but I couldn’t fix it. I kept getting errors that iMessage couldn’t be activated, even after rebooting the phone. Eventually, much later and again for unknown reasons, activation succeeded.

Update (2026-10-20): Boris Yurkevich:

My concern is that the Retry as Text Message toggle no longer exist. Just a couple of weeks ago my sister sent me an iMessage while I was flying. I was not reachable. Later she told me that messages turned from blue to green.

The Hack (Hacker News):

Like the Trojan Horse, passkeys are legitimately elegant on the surface, but there is something troubling inside.

What’s important to know is that unlike with any other kind of login credential, you do not have ultimate control over your passkeys. With passwords, you can choose where to write them down; with authenticator apps, you can decide for yourself which ones to use (they’re pretty interchangeable); and with physical security keys you can hand them to your colleague if you really trust them. But with passkeys come a hidden dial that lets the websites you use them on gradually remove your ability to do as you please with them.

[…]

This is the feature that means you no longer get to make the calls about your passkeys. Fortunately, attested passkeys are not yet required on most websites. But the FIDO Alliance standard makes attestation a part of the passkey ecosystem, whether you want it or not. And even if the website doesn’t require attestation now, simply by using passkeys you indicate to the website that your setup supports the FIDO Alliance’s passkey standard and that you as a user are capable of using passkeys. This means that once Twitter (formally X) is satisfied that the overwhelming majority of its users would be unaffected, they can flip the switch – perhaps not all at once, perhaps just for ten thousand users at a time so as not to cause a fuss – and start rejecting non-attested passkeys.

[…]

My expectation is that the industry will start off with very few constraints on your passkeys, and gradually add more and more, not all at the same time, but staggered on different sites, and then in a few years people will forget that they were ever offered a choice in which security measures they want to enable on their passkeys (if they even knew there were different kinds of passkeys at all).

[…]

Remote attestation can allow them to verify that your device is not capable of, say, sending and receiving encrypted messages, or running a competitor’s app, or using social media without verifying your ID.

Apple’s passkey implementation currently does not support attestation, but it sounds like this is only until they can work out how to do syncing:

Attestation was designed to attest to a specific device, exclusively at the point of creation, with a specific set of security properties. It doesn’t make sense for synced credentials for a number of reasons, including syncing to devices with different security properties, changes in security properties that happen after key creation, security properties of the sync fabric, sharing the passkey, or exporting to other passkey providers. We’re working hard with W3C and FIDO to solve these problems.

Ricky Mondello:

The post is predicated on the idea that a feature of WebAuthn called “attestation”, which is only used in high-assurance and usually corporate scenarios, and usually with physical hardware security keys, will be leveraged to hurt people, somehow.

The post posits that a website like X will bait and switch users: first, you get a passkey. Then, later, scary “attested” passkeys! This simply isn’t possible to do because attestation isn’t supported on the web for mass market, consumer authentication.

Attestation for passkeys (software-based, syncable credentials) is antithetical to their mass market goals, and would freeze out independent, non-corporate-backed credential managers. It’s an explicit non-goal of the designers of passkeys, who work together in a forum anyone can join.

And trust me, websites and apps like banks repeatedly asked for attestation at the beginning of the industry’s passkey journey. The platforms, browsers, and credential management apps have held firm that the goal of passkeys is reducing phishing and not some kind of trusted computing scheme. (And I will note: over my dead body!)

I believe this is not the goal of Mondello and some of the others working on this, but so far I’ve not been convinced that they will be able to control it. It sounds like Apple is working on it, and once the technology is out there, what’s to prevent key sites from forcing it on users? It seems like all this would take is the cooperation of a few big credential managers. This would be to their benefit in the sense that it would make their products required. Smaller credential managers who resisted would be frozen out.

varx:

The fact that websites and apps have been asking for attestation just reinforces the main point of the passkeys post! Sure, browsers aren’t supporting it yet, but that’s the sort of thing that can change, and the sort of thing that has changed in the past. See the footnote on Widevine and Firefox. (“Currently not supported” is also very subject to change.)

And we already have sites and apps allowlisting passkey vendors. That’s no theoretical, slippery slope fear -- it’s a real restriction on user freedoms that’s already happening right now.

I don’t think that a couple of bad points (e.g. the TOTP thing) invalidate the main point of the post, because the post wasn’t an argument from authority. The author makes some good points that stand on their own.

Ricky Mondello:

To be clear, the websites have stopped asking for attestation. Or at least, they’ve stopped asking me. Why? Because they know there’s no use in asking — that the OS vendors, browsers, and passkey managers are unified on this front. And now they’ve seen firsthand that passkeys without attestation are awesome and a big step forward.

iinuwa:

This is antithetical to users, as the types of authenticators that can pull this off are difficult to use (security keys). Companies with IT departments who can do account recovery for the user can handle this, an average user cannot. Synced passkeys are the answer to this for consumers and therefore attestation does not belong in the consumer space. Which is why password managers are in the spec groups pushing back against this every time it comes up.

Scott Helme (Hacker News):

If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that?

[…]

If you’re worried about attestation creeping into consumer logins, then that’s worth pushing back on, loudly (if it ever happens). But it hasn’t happened, the biggest providers don’t support it, and avoiding passkeys today while you wait for it won’t protect you from anything, it just leaves you open to phishing.

It seems like rejecting passkeys is the only way the average user has to push back. The main thing protecting us is that sites don’t want to lock out their users who rely on passwords and 2FA. Once most people have adopted passkeys, if Apple and Google sell us out, I don’t think it matters much what the rest of the alliance thinks. Sites would be able to require attestation with the assurance that users could easily comply. Safari would probably opt everyone into attested passkeys, as it currently opts you into passkeys in general (unless you uncheck “Allow Automatic Passkey Upgrades”).

Previously:

• Attestation News
• Locked Down Passkey and Keychain Backups
• Forcing Passkeys
• Passkeys Credential Exchange
• Web Environment Integrity

TheLastProject (Hacker News):

In the [EU age verification] README, the following is listed:

App and device verification based on Google Play Integrity API and Apple App Attestation

I would like to strongly urge to abandon this plan. Requiring a dependency on American tech giants for age verification further deepens the EU’s dependency on America and the USA’s control over the internet.

Bobby Borisov (Hacker News):

The European Union’s open-source age-verification project has drawn criticism after a maintainer confirmed that hardware-bound attestation is a mandatory architectural requirement, raising concerns about Linux, custom Android ROMs, and independently compiled applications.

[…]

The solution lets users prove they are over a certain age without revealing their name, exact birth date, or full identity document. To prevent credentials from being copied, cloned, or reused by modified clients, the project relies on keys stored in protected hardware like Android TEE, StrongBox, or Apple’s Secure Enclave.

However, critics claim that this approach endangers the system by making it dependent on a small number of approved devices, operating systems, and attestation providers.

Positiveblue (Hacker News):

Cloudflare’s new “signed agents” pitch sounds like safety but it’s a wolf in sheep’s clothing. They’ve built an allowlist for the open web and told builders to apply for permission. That’s not how the internet works. An application form is not a standard.

GrapheneOS:

Apple and Google are gradually expanding their use of hardware-based attestation. They’re convincing a growing number of services to adopt it. Google’s Play Integrity API and Apple’s App Attest API are very similar. Apple brought it to the web via Privacy Pass, which Google intends on doing too.

Google’s Play Integrity API requires hardware attestation for the strong integrity level and is gradually phasing in requiring it for the more commonly used device integrity level. Apple already has it as a requirement. Over the long term, this will increasingly lock out hardware and OS competition.

The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google. This is wrongly presented as being a security feature. Banks and government services are the main ones adopting it but Apple and Google are encouraging every service to use it.

German National EUDI Wallet Architecture Documentation (Hacker News):

When issuing the PID, the WB confirms to the PP (via OpenID4VCI Key Attestation) that the keys to which a PID is to be bound are controlled by an authentication means that meets certain security requirements with regard to resistance against attackers with a certain attack potential (see ISO/IEC 18045).

Simon B. Støvring:

It’s great that App Attest is coming to Mac with macOS 27. It means I can ship Canvases’ intelligence and sharing features with much more confidence, knowing I can protect the endpoints with App Attest.

Previously:

• Instagram Charging for Links
• The Age Verification Trap
• Apple Platform Security Guide (January 2026)
• EU Council Approves New “Chat Control” Mandate
• Google Abandons Web Environment Integrity API
• Web Environment Integrity
• App Attest

Howard Oakley:

Of all the privacy protections in macOS, those for local networking are among the most recent and the least understood.

[…]

All non-exempted apps and other processes start without any privilege. Those that try to make a local network connection result in the user being prompted to allow or deny their access. Your decision is then recorded in that app’s new entry in the Local Network section, and you can then set that to allow or deny its future access. For that to happen, the responsible app needs an additional item in its property list to explain to you why it requires that access, something that should appear in any prompt for access.

[…]

A process with a short life that immediately fails if it can’t complete a local network operation may not trigger a user prompt, and can continue to fail repeatedly as it can’t be granted the privilege. Apple recommends changing the code so that it doesn’t exit immediately after failure, to allow the prompt to be displayed and access granted.

Howard Oakley:

Another clue came in the statement in that note that “on macOS there’s no way to reset your program’s Local Network privilege to the undetermined state”. This contrasts with pretty well every other category of privacy protection, which are handled by the dreaded TCC, Transparency Consent and Control.

This has now changed in macOS 27.2.

TN3179:

During testing, you might want to reset your program’s Local Network privilege to the undetermined state. Your options for this vary by platform.

On iOS, the easiest option is to delete your app.

Alternatively, if you don’t want to delete your app for some reason, reset the entire privacy subsystem using Settings > General > Transfer or Reset > Reset > Reset Location & Privacy.

On macOS, the list in System Settings > Privacy & Security > Local Network has add (+) and remove (-) buttons. To reset your program’s Local Network privilege, select it in the list and click the remove button.

Previously:

• Local Network Privacy on Sequoia
• Local Network Privacy FAQ

Toni Sagrista Selles (Hacker News):

In a dramatic turn of events, the Chromium team has reversed its Obsolete tag, and has decided to support the format in Blink (the engine behind Chrome/Chromium/Edge). Given Chrome’s position in the browser market share, I predict the format will become a de factor standard for images in the near future.

[…]

I’ve been following JPEG XL since its experimental support in Blink. What started as a promising feature was quickly axed by the team in a bizarre and ridiculous manner. First, they asked the community for feedback on the format. Then, the community responded very positively. And I don’t only mean a couple of guys in their basement. Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita, and many more. After that came the infamous comment[…]

[…]

To top it off, a couple of weeks ago, the PDF Association announced their intent to adopt JPEG XL as a preferred image format in their PDF specification.

Michael Larabel (Slashdot):

JPEG-XL image support is back in the very latest Google Chrome/Chromium codebase. Back in December they merged jxl-rs as a pure Rust-based JPEG-XL image decoder from the official libjxl organization. At the end of December they did more JPEG-XL plumbing with the enums and build flags for the support.

Luca Versari et al. (via Jarek Duda):

We’re excited to announce that Chrome is shipping decoding support for the JPEG XL (.jxl) image format starting from Chrome 155. JPEG XL is a next-generation image format designed to meet the needs of modern web developers and photographers. It offers 30-50% better compression than JPEG, lossless compression, built-in HDR support, lossless JPEG transcoding, and more.

In general, we recommend trying both AVIF and JPEG XL to get the best results. We expect that JPEG XL is most helpful for high-fidelity or lossless compression, especially of photographic images or in cases in which fine-grained progressive decoding is preferred.

Previously:

• Chrome Doesn’t Support JPEG XL
• iPhone 16 Adds JPEG XL

Jeff Benjamin:

A drawback of using an HDR-ready third-party monitor on macOS 26 Tahoe was the inability to activate High Dynamic Range at the common 2560 x 1440 scaled resolution. Fortunately, the newest macOS release resolves this problem.

Alexander Cohen:

• Symptom: scrolling is choppy on the Studio Display XDR at 120Hz or Adaptive (47–120Hz). At 60Hz, and on the MacBook’s own screen, scrolling is smooth.
• What devices are affected: M5 Pro MacBook Pros have reproduced the problem; other repots suggest the Mac mini with M5 Pro chip is also affected. Apple lists M5 Pro MacBook Pro models as supporting the Studio Display XDR at 120Hz.
• Likely cause: measurements suggest the GPU stays at a low clock speed while scrolling and misses frame deadlines.
• Workaround: MacRumors Forums poster Tiguanito’s M5ScrollBoost, a small menu bar app that encourages the GPU to run faster while you scroll.

Previously:

• MacBook Pro 2026
• Studio Display and Studio Display XDR

Update (2026-10-14): Timuçin Kabak:

Another issue I encountered is that the True Tone also applies to some external displays and applies a tint. I created a tool for it.

John Voorhees:

Earlier this week, I was at OpenAI’s annual DevDay conference where it launched Dots, a personal agent that lives inside the ChatGPT app.

[…]

Dots are persistent, cloud-based agents that use the plugins and other tools you’ve connected to ChatGPT, after you allow them to do so. Your Dot has its own virtual Linux computer to assist you with your work. And at first, your Dot, which is depicted by a colorful character you can customize, doesn’t have access to anything else. However, as you give your Dot tasks that need access to other tools, it will ask for your permission to access other tools.

[…]

But being a cloud-based agent has its downsides, too. Out of the box, your Dot can’t access your computer’s files and apps. That’s easily fixed by clicking or tapping on your Dot and granting it access to your Mac, so it can use the Mac alongside its own VM.

Previously:

• Unspecified Full Disk Access Screw Tightening
• OpenClaw 2.0
• Meta AI for Mac and Muse
• Grok Bot
• Siri AI Ships (But Still Beta)
• ChatGPT Work and ChatGPT Classic
• Claude Desktop App
• Gemini App for Mac

Adam Engst:

Apple has significantly improved dictation in iOS 27 by adding a few capabilities for editing text from the Voice Control system. In other words, Apple has finally done some of the things I requested in “How iOS and macOS Dictation Can Learn from Voice Control’s Dictation” (31 August 2020). Remember, dictation is what you get when you tap the microphone button on the keyboard, while Voice Control is an all-encompassing system that you turn on in Settings > Accessibility > Voice Control. The problem with leaving Voice Control on permanently is that it’s constantly listening and thus inserting text when you don’t want that, and at times I have felt that its dictation isn’t as good.

Most notably, when you’re using iOS’s regular dictation, you can now change the case of words and phrases by saying “Capitalize phrase” or “Lowercase phrase.” Incorrect capitalization of words drives me up the wall. Equally useful is the ability to fix misheard or misspoken words by saying “Replace phrase1 with phrase2.” Most other Voice Control commands aren’t available in dictation, but you can say “Select phrase” and “Undo that.”

[…]

Unfortunately, while Apple added some of Voice Control’s capabilities to dictation in iOS 27, it didn’t extend that effort to macOS 27 Golden Gate. Put simply, when you use dictation in macOS, you don’t have access to any text-editing commands.

Previously:

• Apple’s 2026 Accessibility Feature Preview
• 2025 Apple Vision Accessibility Report Card

Tower 18:

But something has changed: thanks to AI coding agents like Claude Code and Codex, even the most devoted GUI fans are now spending more and more time in the terminal. You kick off a task, the agent does its thing… and then you want to actually see what happened.

That’s where Tower shines, so we felt the path from the terminal to Tower deserved a serious upgrade. With Tower 18, the Tower Command Line Tool (gittower) is no longer just a way to open a repository — it takes you to exactly the place you want to look at.

I’ve been wanting this for 15 years or so. Thanks, AI! You still can’t open a file in Tower by dragging it onto the Dock icon. Nor can you just pass it to gittower and have it figure out which repo it belongs to. But if your working directory is already within the working copy, you can now use gittower to open the file history. I’ve written a script that finds the current file in the frontmost app (BBEdit, Xcode, or Finder) and opens it in Tower.

Previously:

• Xcode’s New .xcproj Files Are JSON
• Git Tower 16
• Tower 2.0

Apple (Hacker News, MacRumors, Lobsters, TidBITS Talk):

Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac. Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems—including files, mail, messages, and even browsing history—without users’ full knowledge and understanding.

[…]

Going forward, we will introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action. Addressing this is critical. As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially.

Guy English:

It was pretty obvious something like this would happen after the Muse accessing Messages news.

Jeff Johnson:

What we have is just one noisy, confused journalist, Jason Aten. He granted FDA to Muse but refuses to admit it, to the public or even to himself.

I see several issues with the current Full Disk Access system:

1. Backup apps need FDA, but so do many other types of apps. Often, they don’t need full disk access but rather they need to work around a missing or broken API. All of my apps except ToothFairy use FDA, not because I want to or because it’s easier to code, but because without it the user experience would be much worse or key features wouldn’t work at all.

2. There is no API for apps to see whether they have FDA or to request it from the user. It’s not like, say, accessing the user’s Contacts where macOS pops up a standard dialog and the app supplies a “reason” string to specify why it wants access. Instead, each app presents its own set of instructions for how to enable it deep in System Settings. It requires the confusing maneuver of first adding the app to the list; it doesn’t automatically show up with a slider switch next to it, like with other privacy settings. This adds an obstacle for users to get up and running with an app but doesn’t really provide additional security, just obscurity.

3. FDA is not granular. There’s no way for apps to request only the permissions they actually need. For example, SpamSieve wants to be able to access the user’s mail, but it doesn’t need or want to see their iMessages or browser history. This is bad for users because they may be exposing more information than they want to and bad for developers because some users will think your app isn’t worth the risks.

4. There is no way for the user to see what the app actually did. If it tells me that it wants FDA to access my mail but actually it mucked around with my Time Machine backup, how would I know?

5. Apple’s wording in System Settings is not very clear. I don’t think most users really understand what FDA is doing.

6. The previous items combine to create opportunities for malfeasance. It’s normalized that many apps that seem like they wouldn’t need full disk access do need FDA, so this makes it easier for apps to trick the user into granting it under false pretenses. Apple requires that apps coach the user through the process, so it’s normal that users mostly see text from the app (which might not be trustworthy) rather than standard text from Apple, as with other permissions prompts.

But the problem in the Muse case was not malfeasance. Rather, it seems that Muse asked Aten to enable FDA, but he doesn’t remember doing so or didn’t understand what he was doing. It sounds like Apple wants to make this consent more clear, which is good, but other issues would remain. As with the recent keychain story, this feels like a bandaid rather than a thoughtful solution to the real problem. The issues with FDA were clear when it was introduced 8 years ago, and many Radars were filed, but it’s been virtually unchanged since.

Apple seems to think that by making a scarier warning they can convince more users not to grant FDA—or at least perhaps deflect blame from Apple to the user if they later regret it. Maybe that solves Apple’s problem, but it doesn’t really solve the user’s problem. The user is installing Muse because it’s more capable than Siri. They probably do want it to access some protected data, e.g. so it can find information in their mail or messages. So they actually do need to give it FDA. Aside from deterrence, Apple is not actually protecting the user. And the deterrence is kind of sketchy. Rather than providing a safe way for users to choose what to share with a competing product, Apple is saying the only option is to share everything, and then discouraging that. Meanwhile, there’s no switch to turn off Apple Intelligence. It’s like they expect you to stay on eWorld and not download Netscape. I actually really liked eWorld, and the broad Internet wasn’t totally safe (though neither was eWorld), but that doesn’t seem like much of a strategy.

Jeff Johnson:

Below I’ve embedded […] a screen recording of a macOS Virtual Machine showing the first run experience of the Meta Muse app.

[…]

It’s important to note that macOS has no API for an app to request or acquire Full Disk Access. The only way for an app to receive Full Disk Access is via the Full Disk Access pane of System Settings, as shown in the video. Thus, the only thing an app can do is open the System Settings pane for the user, as also shown in the video. Once the user is in System Settings, it’s up to the user to manually grant Full Disk Access.

Without Full Disk Access, Muse cannot access the user’s Messages database. If it could, that would be a macOS zero day vulnerability.

[…]

Aten oddly writes as if the “if you give it Full Disk Access” earlier in the article were counterfactual, merely hypothetical, still insisting that he did not give Full Disk Access to Muse.

John Gruber (Mastodon):

I really worry about just how much Apple is going to lock Full Disk Access down. I use it with several apps that couldn’t function properly without it, and would be severely hampered if I needed to authorize it manually every time they do something.

Ben Lovejoy:

However, what Apple absolutely must not do is to make the mistake it made with macOS Sequoia over screen recording. Sure, this is also incredibly dangerous and very strong warnings are appropriate, but what Apple did then was to force us all to confirm these permissions on a weekly basis, as well as after every restart.

Dave Nanian:

Well, this is certainly ominous news for backup programs.

Like it’s not hard enough to turn this stuff on…

Nick Heer:

Is Apple suggesting this capability could be limited in the future to backup applications alone? I do not like that.

[…]

Because of the lack of information available at present, I do not want to get too far ahead of myself, but I am concerned that it could be a significant curtailing of application permissions. It has the potential for further self-preferencing, as Apple will surely exempt Siri from the kinds of permissions requests it requires of third-party apps, even as it is updated with additional capabilities.

[…]

Call me a naïve little baby if you want, but I do not think preserving Siri’s dominance on Apple’s devices is the company’s reason for locking down Full Disk Access. But Apple’s existing restrictions are part of the reason Siri was awful for a decade. If it had the opportunity to compete with third-party replacements, I doubt it would have languished in a miserable state for as long as it did.

John Voorhees:

[Only] a handful of apps to which I’ve granted Full Disk Access are backup apps. Others include the Finder replacement Bloom, launchers like Alfred, the wonderful selection utility PopClip, Apple’s own Pixelmator Pro, Setapp, TestFlight, Supercharge, Madden NFL 27 Arcade Edition, Hazel, and many others. It’s a diverse selection of apps covering everything from Apple’s own apps to Mac utilities that are longtime favorites of MacStories readers, and even one Apple Arcade game.

[…]

On the one hand, it seems to suggest that users will simply have to jump through additional explicit hoops to grant Full Disk Access to their agents and other apps. On the other hand, claiming that Full Disk Access was designed solely for backup apps raises red flags that could signal that the company intends to restrict the kinds of apps that can use Full Disk Access. I sure hope not.

Dan Moren:

But there are plenty of legit uses for Full Disk Access. Just looking at my MacBook Air this morning, I’ve given that permission to three apps: Terminal, BBEdit, and SuperDuper. All apps that I trust with that level of power because of their long history and because in order to do what they do best (or at all), they need that access. (Interestingly, on my Mac mini, that list also includes SpamSieve, KnockKnock, and Shortcuts—though not BBEdit, for whatever reason.)

[…]

I think there is a good argument for protecting Full Disk Access further, but there’s also only so much you can do to protect a user from themselves. Ultimately, this is a cat-and-mouse game, and while I don’t want my data purloined or misused, I also don’t want my computer locked down to the point that I can’t use it for all the things I want to do.

Ben Thompson (Hacker News):

To say that I’m nervous about what Apple’s solution will entail is a massive understatement. There is one aspect in which the Mac is the perfect agent host: Apple has, for decades, invested in a combination of scriptability, automation, and accessibility APIs (these are very often the same thing) that makes it remarkably well-suited to computer use. Then there is the fact that macOS is a certified Unix system; this means that agents — which are perfectly suited to the command line — have access to the entire universe of tooling built for Unix systems. And, of course, Mac hardware is amazing.

The problem is that for my particular use case — a headless, always-on Mac Mini that I primarily access from other computers and my phone through the ChatGPT and Claude apps — macOS is incredibly hostile. The biggest issue is GUI-only permission prompts that are invisible to software running on said computer, including agents.

[…]

This system is annoying but manageable on your primary Mac; it’s a disaster on a headless Mac running agents, for two reasons. First, agents write new programs all of the time, and in my case, those programs need access to devices on my network (SMB shares, for example, trigger a TCC warning). What I need is a permission layer for agents, not the programs they create; TCC is operating at the wrong level of abstraction.

Second, the TCC subsystem exposes its prompt in a protected space that no program can see; that means that programs silently fail and the agents don’t know why; what I have to do is remember that there is probably a permissions prompt on screen, log into the Mac Mini with screen-sharing software, and click OK.

Wade Tregaskis:

Apple’d get a long way by just renaming the privilege. How many laypeople understand what a “disk” even is? Regular people just talk vaguely about how much “memory” their computer has - if they think about it at all other than when they run out of disk space - at which point, how many just think that means they have to buy a new computer? So, how about just “Full Access to All Your Data”? Call it what it basically is.

Jason Anthony Guy:

If Apple has time (or is especially motivated), it might also add more granular options to control what data apps can access. For example, instead of today’s single toggle that grants an app access to the broadly defined “data like Mail, Messages, Safari, Home, Time Machine backups, and certain administrative settings,” it might instead allow you to enable access to specific data on a per-app basis. This would allow, for example, Muse to access Mail and Safari, but not Messages or Time Machine.

Kevin Grant:

With all the levels of entitlements and crap they added, I find it ironic that SIP is “only” implemented as “open up every damned thing to everyone” without more refined levels.

John:

I was frankly surprised when I learned FDA was for a machine, across user accounts, rather than for a single user. It seems like granting root, something the *nix community has tried to reduce and lock down for decades.

I certainly don’t trust anyone’s AI with root, and creating a weak, non-admin, user for AI experiments should be a safe path.

Jimmy Callin:

While [Gruber sees] this as a “why we can’t have nice things” moment, I see it as another case of Apple using privacy to limit competition in areas it currently lag behind.

I’d prefer to decouple trust in how my personal data is handled from trust in a particular platform or software vendor. That’s what I personally value about EU’s approach: give people rights over their information, make mishandling it a legal liability, and severely punish companies that break those rules.

Apple getting unique privileges to access sensitive data simply because they own the platform, and thus there is an implicit trust in their handling of it, feels like a brittle long-term strategy. If this works without causing anti-trust issues, it only makes Apple more dominant while locking out potentially useful software.

Previously:

• I Said No and Apple Said Yes
• Locked Down Passkey and Keychain Backups
• Meta AI for Mac and Muse
• Mandatory Apple Intelligence
• Reporting a Full Disk Access Bug to Apple
• Terminal and Full Disk Access
• macOS 11.4 Breaks Full Disk Access for Helper Tools
• The Alert Hammer
• Mojave’s New Security and Privacy Protections Face Usability Challenges

Update (2026-10-06): See also: TidBITS Talk and Vitor.

Howard Oakley:

Whether or not you would ever want to unleash AI agents on your Mac, Apple does need to refine Full Disk Access as a matter of urgency. But its design and engineering cannot be rushed. Merely adding to the complexity of current Privacy settings wouldn’t help users, many of whom already find privacy protection confusing and opaque.

Sherief, FYI:

it’s clear there’s consumer demand for automated access to iMessages, and instead of offering a proper API with audit trails and fine-grained controls Apple would rather force users to FDA then cry fowl when they grant FDA.

Previously:

• The Difficulty of Accessing Old iMessages
• Search in Messages.app

Update (2026-10-14): Adam Engst:

63% of the more than 200 people who voted said they had granted Full Disk Access to 6 or more apps, with over half of those people saying they had given 11 or more apps that level of access. In short, Full Disk Access is essential to how many of us use our Macs.

At the same time, Full Disk Access feels a bit like a Band-Aid, partly because Apple hasn’t put enough thought into more granular permissions, forcing many apps to rely on Full Disk Access even when they don’t need all its capabilities.

[…]

Given that Apple’s statement about Full Disk Access seems to have been prompted by the release of Meta’s Muse AI agent, I would suggest Apple think more carefully about how such agents should be handled. They may legitimately need Full Disk Access, along with numerous other permissions, but beyond what would appear in an App Privacy Report, I would like to see them maintain complete logs of every permission-enabled action they take on your computer. Preferably in human-readable form.

Howard Oakley:

In Golden Gate there are currently three sources of records of AI transactions. Those handled entirely on-device appear only to be recorded by Unified log entries, while interactions with Siri are provided in a detailed transcript in the new Siri app.

[…]

Although that transcript includes external references implying that an off-device model was used, no explicit information is given, and entries don’t make clear what information left the device, or whether that was handled by PCC or Apple’s secure implementation in Google Cloud.

Apple’s documentation refers users to the Apple Intelligence Report (AIR) available from Privacy & Security settings. When enabled, this will generate at the user’s request, a report covering the last 15 minutes or 7 days of AI interactions which “may include personal data such as messages and text you enter in intelligent writing tools.”

Glenn Fleishman:

Because of the peculiar nature of AI large language models (LLMs), Apple has to “talk” to Siri AI just like we talk to ChatGPT or Claude. But what does Apple say in these system prompts?

[…]

The report is formatted in JSON (JavaScript Object Notation), which is not meant to be read by humans. However, you can open it in a JSON reader, such as the free JSON Viewer, for a color-coded view that’s easier to examine, or cut and paste it into a text editor or word processor. Reports can get large, though, and JSON Viewer only handles files up to 10 MB. Try OK JSON if you hit that limit ($24.99 with a 7-day free trial). Neither app soft-wraps long lines, so I copy the prompts into BBEdit ($59.99, free mode available) for searching and viewing.

Howard Oakley:

I pointed out that the bulk of most AIRs are privateCloudComputeRequests, metadata for requests processed by PCC, whose main contents are attestation bundles. Those are provided in Protobuf format, and encoded using Base64, making them difficult to access.

However, Apple states that “you can parse, canonicalize, and verify attestation bundles from the Apple Intelligence Report using the pccvre attestation subcommands.” This article explains how you can do that without compromising the security of your Mac, using a Virtual Machine.

Howard Oakley:

Once you’re happy the AIR will be worth browsing, return to that setting and click on the Export Activity button. Be sure to save that AIR with the default .json extension.

[…]

Provided you’re running macOS Golden Gate, download the first beta of my new app AIRer from here: AIRer100

[…]

If there are records in that AIR, they will be listed by time and date, with the oldest at the top, in the left sidebar. Select one of them, and its useful contents will be displayed in the main part of AIRer’s window.

Previously:

• I Said No and Apple Said Yes

anonymoussingh:

We maintain a macOS product whose installer uses custom InstallerSection plugin bundles to show configuration panes during install. Starting with macOS 27 beta 6, all of our plugins stopped loading in Installer.app — the panes never appear and the install fails because our preinstall step depends on data the panes collect.

HirohikoKihara (via Ric Ford):

A third-party PKG installer that ships a custom Installer Plugin no longer displays one of its selection panes. The plugin bundle appears not to be loaded, so the pane that it provides is silently skipped and the user cannot choose the intended installation option.

FE:

This is regression for all latest updates eg. 15.8, 27.7, 28.0. This bug refuse open installer plugin for security reason in spite of the plugin and installer are correctly signed, notarized and works seamlessly in previous macOS versions. Workaround is copy installer (*.pkg) to local file system (home, desktop folder).

Previously:

• macOS 27.0.1
• macOS 26.7.1 and macOS 15.8.1

EagleFiler 1.9.22 is a maintenance release of my Mac file/note organizer and e-mail archiving app. This version works around various bugs in macOS 27, adds capture support for the Thorium Web browser, and improves importing from Mariner Paperless.

• macOS 27 broke several things with drag and drop out of Apple Mail. Simply trying to read a URL from the pasteboard will cause a hang while it waits forever for the pasteboard server (FB24803817). The same thing happens when using PasteboardSetPasteLocation() and reading kPasteboardTypeFileURLPromise directly, which I was doing (instead of using newer API) to work around bugs in older versions of macOS. EagleFiler now uses NSFilePromiseReceiver for drags from Mail on macOS 27, which works better, but I also had to work around a bug where Mail would promise superfluous files for which the reader callback was never invoked at all.

• macOS 27 also seems to include various regressions when reading PDF and Word files, producing invalid strings containing NUL characters. Also, displaying certain PDF files worked fine on macOS 26 but now crashes.

• I also ran into (and worked around) a bug where macOS 27’s NSTextView would get into an infinite layout loop when displaying an attributed string that included images.

• Drag and drop from Airmail is still an issue. When using the newer drag APIs, it will often hang Airmail or not produce a file, and this also happens with other apps like Finder as the destination. EagleFiler works around this using older APIs with Airmail and tries to report a helpful error when there’s trouble. Single-message drags work best.

• I’ve also been investigating a problem where saving a file with a colored tag in iCloud Drive will, a few seconds later, change the color to gray, but I don’t have a solution for this.

Previously:

• EagleFiler 1.9.21