Apple’s warning about AI agents misusing Full Disk Access sparks a debate over Mac security, privacy, and the potential consequences for developers and users. The MacVoices Live! panel examines Apple’s permission system, the need for more granular controls, and concerns about restricting legitimate applications and developer options. The discussion also questions Mark Zuckerberg’s involvement in drafting the White House’s voluntary AI regulatory accord and whether self-regulation is the best solution to potentially dangerous advances in AI. 

💾

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

Rosyna Keller:

FruitMenu Redux revives a utility (FruitMenu) that brings lost Mac OS Classic features to Mac OS X. Specifically, it restores the fully customizable Apple menu.

It’s no longer a haxie that works by patching the operating system. Now, it’s a regular app that hooks into other apps (e.g. to switch to a particular window) using the accessibility APIs.

The first step was to implement every FruitMenu feature that’s still possible in the current macOS security environment. That immediately ruled out features requiring patching menus (sigh, I really miss patching menus) and features that require privileges now gated behind restricted entitlements. I also added support for viewing and executing Shortcuts.

[…]

Additionally, you can set a hotkey to any item you add to FruitMenu Redux!

[…]

Because SwiftUI doesn’t support dynamic menus, I had to rewrite all the menu code to use AppKit’s NSStatusItem and NSMenu as NSMenu is now a first-class citizen on macOS and fully supports dynamic submenu building. This means that FMR doesn’t even try to build the contents of a folder under you actually attempt to show the contents of the folder. Not only is this significantly faster, but it also uses significantly less memory.

FruitMenu is now available (Mastodon):

A built-in visual editor displays your menu on the left and a library of over 30 item types on the right. You drag items from one to the other (almost like Font/DA Mover, the best UX ever created). The library includes files and folders, submenus, Running Applications (and you can enable an option to show open windows and tabs), Mounted Volumes, Recent Items, Force Quit, Sleep, Restart, Shut Down, Shortcuts, Software Update, separators, System Settings panes, and more!

Anything you put in the FruitMenu Redux Items folder in your Library also appears in Files, folders, and aliases.

$10 (with $7 intro price), not in the Mac App Store because of accessibility.

Rosyna Keller:

OMG, Core Transferable, why do I have to declare a public UTI in my info.plist for internally dragging from one list in my app to another list in my app?! It’ll never be decoded by another app!

This was the fix to a bug I reported. With the new SwiftUI drag API, you apparently have to declare private internal drag types in your plist (on Tahoe, but not on Golden Gate).

Xounds, which plays sounds in response to user interface actions, is also back. Unlike FruitMenu, this one never appealed to me—I actually prefer to have the audio muted most of the time. I do find it interesting that it supports the old sound set files from Mac OS 8. Apple dropped the APIs for playing these way back during the 64-bit transition, but Xounds knows how to extract and play the audio.

Previously:

• SwiftUI in appleOS 27
• Where Did SwiftUI Leave You Hanging?
• Dragging From a List With SwiftUI
• Add Security Access Groups for Accessibility APIs
• Menu Master 1.0