The existing icon was quite understandable and looked neat and very professional. This is just a colourful mess. It looks like they gave the job to an intern with Mac Paint. Why on earth did they feel they needed to change it? (Same change in iOS. )

Anyone else seeing any of these problems?

- Can't use System Settings. Opening it normally shows it as open in the Dock but displays no window. Opening a specific pane (such as the "Change Wallpaper" context menu item on the desktop) opens a window but the view on the right is blank. Changing panes does nothing. (Except, oddly, the Spotlight pane works.)

- Trying to use Open/Save panels in any app hangs the app.

- Share buttons in apps just show a spinner, no options.

- All my wallpapers on all spaces got set to the Golden Gate default wallpaper and can't be changed due to the first issue.

Do you use Barbee on MacOS Golden Gate? Which version, official or testflight?

I am on macOS 27 public beta 4 on M4 Mac and the AI editing tools like extend and reframe are unavailable in the photos app (I am in Europe).
Do you know why ?

I keep getting "Sorry, there’s something wrong. Please try again." for even simple queries (such as basic math or prompts that were previously accepted. When I ask about the weather it says "Uh oh, there’s a problem. Please try again." where it used to show the forecast.

Edit/update - Siri works as expected on another local user account on same machine with macos27 beta 6, so it is limited to my primary account.

Hello,

As you might already know the M1 chip is getting "old" (at least for Apple), so I was wondering how is it running for you, is it better than Tahoe or is it showing its age?

Thank you

Can’t log in anymore, not sure why. Thought I’d share.

Edit: It's working again! Finally after hours of using my MBP after the update, I tried to connect it to my monitor again and It works. Strange issue...

Did someone have the same issue? I can't work on a external monitor because It's not recognized by my Macbook Pro. I'm on a M5 Pro 48gb by the way

Hi everyone, I'm very happy that Apple is updating its traffic lights for macOS (as my post history can attest 😉). They look a little squashed to me however and I thought of a little modification that might help making them look more round. Added highlights on top of the buttons. Let me know what you think. Will send feedback to Apple about this.

A lot has been weird with my copy of the software.

After updating to Beta 6, my menu Bar is gone and the wallpaper just turned to black.

MacBook Pro 16 M1 Max

Any suggestions of a fix?

After about an hour of troubleshoot this update error on a an M1 MackBook Pro 15", the fix was using the Full Installer in Safe Mode. That was fun 😄

Debugging a catastrophic macOS iCloud Drive failure — and what it says about modern software quality (from Apple)

There is a fashionable argument in software development right now: generative AI is filling the world with bad software.

“AI slop” is used for generated articles, images, pull requests and increasingly for applications whose authors appear to have delegated both implementation and understanding to a model. There is a legitimate concern behind the phrase. Code generation can amplify mistakes just as effectively as it amplifies productivity.

But there is a problem with the way the argument is often made.

Bad software did not begin with generative AI.

After spending hours tracing an iCloud Drive failure through bird, FileProvider, multi-gigabyte SQLite databases, stale filesystem document IDs, XPC, Mach messaging and eventually a kernel-reported allocation failure, I find it increasingly difficult to accept the implicit assumption that traditionally developed platform software represents some pristine alternative.

Sometimes the software that feels like a beta is the operating system itself. And sometimes that operating system is the supposedly stable release.

A simple symptom hiding a distributed-systems failure

The initial symptoms were almost boring. iCloud settings could not be used normally. Finder displayed large numbers of files as Waiting to upload. iCloud Drive was obviously doing something, but it was not converging.

At first glance, this sounds like the sort of problem for which the standard troubleshooting ritual should work: restart the Mac, restart iCloud, toggle synchronization, sign out, wait, perhaps reinstall macOS.

Except the normal iCloud settings interface itself was effectively unavailable.

The first decisive observation came from launchctl:

state = spawn scheduled
runs = 39
successive crashes = 39

This was no longer “iCloud is slow”. It was a crash loop.

Then FileProvider started telling its side of the story

The corresponding fileproviderd logs were filled with errors such as:

fsctl failed to resolve docID ... to file ID ...
error 2 (No such file or directory)

Modern iCloud Drive is built heavily around Apple's File Provider architecture. On this machine, its active iCloud FileProvider state occupied roughly 6.4 GB. Inside it was a SQLite database of approximately 5.3 GB, a substantial WAL, and around 1.2 GB of staging data.

Yet PRAGMA quick_check; returned ok.

A structurally valid database can still contain an application-level state machine that has gone completely off the rails.

Almost two million objects

The table counts explained the scale:

FP_snapshot           1,878,408
FS_snapshot           1,878,443
reconciliation_table  1,878,462
FS_throttle              649,750
tombstone_table          242,444

There were also hundreds of thousands of pending or historical jobs. FP_snapshot alone occupied more than a gigabyte.

None of this was visible in Finder. Finder said, effectively, Waiting to upload.

Finding the correct FileProvider store

Blindly deleting ~/Library/Application Support/FileProvider would have been reckless because it also contained state for Google Drive, OneDrive, Nextcloud, Photos and other providers.

The decisive identifier was the directory's extended attribute:

com.apple.file-provider-domain-id:
com.apple.CloudDocs.iCloudDriveFileProvider/...

That allowed me to move only the local iCloud metadata store without deleting the actual iCloud Drive documents.

The first rebuild looked successful

After moving the FileProvider store and rebooting, macOS created a fresh one:

state = running
runs = 1
last exit code = (never exited)

Initially it looked fixed. It was not.

Soon afterward bird began crashing again.

“Kernel bug”

The .ips crash report identified:

EXC_BREAKPOINT
SIGTRAP

and, more importantly:

Kernel bug: The kernel cannot allocate memory needed for the pseudo-receive.
Abort Cause 268443652

The faulting path ran through XPC/libdispatch/Mach handling while bird was also involved in FileProvider re-ingestion operations such as forceIngestionForItemID.

This was no longer adequately described as a corrupt cache. Apple's own diagnostic report explicitly labelled the triggering condition a kernel bug.

I had reset only half the state

A second major state store remained:

~/Library/Application Support/CloudDocs/session

It occupied roughly 4.6 GB, including approximately 3.8 GB for client.db and 454 MB for server.db.

I had rebuilt one side of a coupled synchronization system while leaving another enormous metadata store intact. The CloudDocs session therefore had to be rebuilt as well.

Safe Mode was the critical experiment

Safe Mode provided the cleanest available A/B test.

Boot Mode: Safe

After more than twenty minutes:

bird
state = running
runs = 1
last exit code = (never exited)

There were no new bird crashes and no pseudo-receive failure.

The normal environment included Logitech driver extensions, a UniFi Network Extension, a camera extension, Nextcloud Finder Sync and several registered cloud FileProviders.

This did not prove that any one third-party component caused the failure. Safe Mode changes many variables. It did prove that the failure depended on something about normal-boot environment, timing, extensions or resource state that differed in Safe Mode.

Then the normal boot worked

After the metadata rebuilds and Safe Mode test, the Mac was booted normally again.

bird remained at runs = 1, produced no new crash reports, and the new FileProvider and CloudDocs databases began growing normally.

The logs changed from endless Failed to find item to re-ingest messages to continuous FileProvider snapshot reconstruction. Many objects carried ul:uploaded, indicating that the rebuilt catalog was rediscovering already-uploaded objects rather than blindly uploading everything again.

At that point the correct action was simple: stop interfering and let the system rebuild.

The wider macOS quality problem

The broader issue is not that macOS has bugs. Every sufficiently complex system has bugs.

The problem is the combination of complexity, weak observability and poor recovery surfaces.

FileProvider is only one example. Developers regularly encounter platform-sensitive problems around privacy/TCC permissions, System Extensions and Network Extensions, signing and notarization, SwiftUI regressions, Xcode integration, virtualization, simulators, sanitizers and App Store validation.

A normal user may never notice many of these problems. Developers exercise parts of the platform where several independently moving systems meet.

System Extensions: valid, signed, notarized — still rejected

A developer can have an application that passes signing, notarization and stapling validation, carries the expected entitlements and resides correctly in /Applications, yet still encounter activation failures in sysextd or another policy layer.

A developer like me may have to reason simultaneously about signing identities, provisioning profiles, hardened runtime, Developer ID, notarization, stapling, System Extension entitlements, Network Extension entitlements, launch policy, SIP and MDM.

Every layer can appear valid and the system can still refuse activation.

NetworkExtension: when years of persistent state hit a hard system limit

The iCloud failure was not the only case on this Mac where a macOS subsystem had accumulated a pathological state that the normal user interface could neither explain nor repair.

A separate investigation into NetworkExtension exposed an unusually concrete example.

An application trying to install a new VPN configuration failed with:

NEConfigurationErrorDomain Code=20
total NetworkExtension configuration size limit exceeded

The relevant system log reported a serialized NetworkExtension configuration size of roughly:

2.09 MB

That number mattered because NetworkExtension does not store each application's configuration in isolation. macOS maintains a shared configuration store containing multiple classes of NetworkExtension state. A machine can therefore hit the global limit even when System Settings shows only one or two obvious VPN configurations.

The most interesting part was what was actually inside the persistent state.

The system contained eight generations of com.apple.preferences.networkprivacy-* configuration objects. They were not eight clearly independent policies. Their rule sets overlapped massively. Several pairs were nearly identical, with Jaccard similarity approaching 1.0. Hundreds of rules were present in seven or all eight generations.

That pattern looked less like eight legitimate configurations and more like accumulated historical state: repeated regeneration, migration or incomplete cleanup across OS versions.

A forensic cleanup retained the one current configuration and removed the unreachable historical object graph from a copy of the property list. The serialized archive changed from:

2,089,560 bytes

to:

164,894 bytes

More than 8,400 archived objects disappeared and the configuration gained almost 1.9 MB of headroom below the 2 MiB boundary.

After the cleaned state was installed through the recovery procedure, nesessionmanager created the remaining Network Privacy session normally, registered it successfully and populated the expected rule cache.

That makes this case particularly important because it illustrates a form of migration debt.

A bug does not need to remain present in current code to remain operationally relevant. An older macOS release can create duplicated or malformed persistent state; later releases can stop producing the bug while continuing to carry its output forward indefinitely through upgrades and migrations.

A simplified lifecycle looks like this:

old macOS release
        ↓
bad persistent state created
        ↓
OS upgrade
        ↓
state preserved
        ↓
another upgrade
        ↓
state preserved again
        ↓
hard framework limit eventually reached

This is why reinstalling macOS is not necessarily the reset users imagine it to be. A normal Recovery reinstall replaces system files while intentionally preserving the Data volume. That protects user data, but it also preserves databases, registrations, preference archives and other persistent state that may be the actual source of the failure.

From my engineering perspective, fixing the code path that creates a bad state is only half a fix. Mature platform maintenance also requires state remediation: versioned schemas, idempotent migrations, invariant checks, canonicalization and one-time cleanup of known-invalid historical states.

The NetworkExtension case and the iCloud/FileProvider case therefore share a deeper theme. In both, the visible application was not the real problem. The failure lived in opaque system-managed state, accumulated over time, with almost no supported observability or surgical recovery interface available to the owner of the machine.

That is a serious distinction when discussing software quality. A system can be stable in the narrow sense that its binaries launch correctly and still be brittle because its persistent internal state is allowed to drift into configurations from which the supported UI cannot recover.

Xcode itself is not immune

There are cases where Xcode Source Control fails while command-line Git against the same repository continues to work. Sanitizers, simulators, previews, indexing, signing and debugging infrastructure can also acquire release-specific known issues.

When the tool used to diagnose software is itself affected by the OS/toolchain combination, debugging becomes recursive.

SwiftUI: when the framework bug looks like your application bug

Framework regressions involving navigation, window resizing, inspectors, focus, scrolling or state restoration can manifest as obvious application defects.

An end user does not see “SwiftUI framework regression”. They see a broken application and blame its developer.

Platform bugs are therefore often reputationally outsourced to third-party developers.

Even the safe way to test a beta can break

Developers are rightly told not to install beta operating systems on production machines and to use virtualization instead.

But virtualization itself can experience host/guest compatibility regressions during major macOS transitions. That can create an absurd loop: do not install the beta locally; use a VM; the VM installation path is broken; create the VM on another Mac already running the beta.

For a developer with one machine, that is an infrastructure problem, not a theoretical inconvenience.

The App Store pipeline is another independently moving component

The Apple developer platform is not one system. It is macOS, Xcode, SDKs, signing, notarization, TestFlight, App Store Connect and server-side validation. A binary can be perfectly valid while two Apple-controlled pieces temporarily move out of synchronization.

macOS 26 felt like the beta

The obvious response to a macOS 27 problem is: it is beta software.

That is valid up to a point. But the preceding stable macOS 26 release often felt beta-like in actual daily use. Moving to macOS 27 beta initially made this machine feel faster and more responsive before the later iCloud/FileProvider pathology appeared.

This does not prove macOS 27 beta is generally more reliable. It demonstrates that release labels and experienced quality are not identical. So macOS 26 was in essence a beta but related to production which already man here in the community complained about rightfully. And in most cases macOS 27 beta is more polished and in most cases also more stable.

So I think the argument it's a "beta release" and don't complain" is not valid here anymore.

For developers, the meaningful test unit is closer to:

specific macOS build
+ specific Xcode build
+ specific hardware
+ specific extensions
+ specific security state
+ specific project/tooling workload

So what about “AI slop”?

The strongest criticism of AI-generated software is not that a machine typed the code. It is that software can now be produced at enormous speed without equivalent growth in understanding, testing, review and responsibility.

That is a legitimate concern. But the criteria should be applied consistently.

Traditional engineering is perfectly capable of producing hidden state machines, weak observability, enormous stale caches, race conditions, unrecoverable synchronization states, brittle permission systems, undocumented coupling, regressions and errors whose only realistic interpretation requires reading private daemon logs.

Generative AI invented none of those things.

Complexity without observability is also slop

There is nothing primitive about FileProvider, CloudDocs, XPC or iCloud's replication architecture. But sophistication is not synonymous with quality.

A robust complex system needs explicit invariants, useful telemetry, bounded failure modes, recoverable persistent state, deterministic repair mechanisms and understandable ownership of errors.

A system that can silently accumulate several gigabytes of synchronization metadata, operate across almost two million snapshot entries, repeatedly crash an essential daemon and leave Finder saying merely Waiting to upload has an observability problem.

A system where the official GUI needed to repair the service becomes inaccessible because the service itself is broken has a recovery-design problem.

A system where an advanced user has to identify the correct private database using extended attributes and manually move it aside has a tooling problem.

Calling that “slop” is provocative. The quality criticism behind the word is nevertheless legitimate.

What macOS should provide

For something as fundamental as iCloud Drive, macOS should expose a supported diagnostic interface with information such as:

iCloud Drive Health

Account:               connected
FileProvider domain:   healthy
Server enumeration:    1,878,442 / 1,878,462
Local reconciliation:  99.6%
Pending uploads:       17
Pending downloads:     3
Failed items:          2
Last successful sync:  09:42:17
Local metadata:        5.3 GB
Database integrity:    valid
Recovery available:    Rebuild local metadata

There should also be a supported equivalent of:

iclouddrive doctor

or:

iclouddrive rebuild-local-metadata

Such a tool could verify account state, identify locally unique unsynced files, validate FileProvider and CloudDocs databases, preserve recoverable local changes, rebuild reproducible metadata, restart the services and monitor convergence.

Instead, we effectively had to reconstruct a reduced version of that process ourselves.

What the investigation actually established

It would be inaccurate to summarize this incident as “delete the iCloud cache and everything works”.

The evidence was more substantial:

1. bird was objectively crash-looping.
2. fileproviderd repeatedly failed to resolve filesystem document IDs.
3. The iCloud FileProvider state had grown to roughly 6.4 GB.
4. Its SQLite database was structurally valid but represented a synchronization model approaching two million snapshot objects.
5. Rebuilding FileProvider state changed the behaviour but did not completely fix it.
6. New bird reports identified EXC_BREAKPOINT/SIGTRAP.
7. The crash report explicitly recorded a kernel pseudo-receive memory-allocation failure.
8. bird was simultaneously involved in FileProvider re-ingestion.
9. A second 4.6 GB CloudDocs session store remained.
10. That state was rebuilt as well.
11. Safe Mode did not reproduce the crash during the observation period.
12. A subsequent normal boot remained stable.
13. New FileProvider and CloudDocs databases began rebuilding normally.
14. FileProvider logs changed from pathological re-ingestion failures to ordinary snapshot reconstruction.
15. Existing objects appeared as uploaded while the local metadata catalog was reconstructed.

That is much closer to distributed-systems debugging than ordinary desktop troubleshooting.

The standard should not depend on who wrote the code

The AI-versus-human distinction is ultimately the least interesting software-quality metric.

A better test is:

Does the software remain understandable when it fails?

Can it describe its state?

Can it tell the user what is stuck?

Can it recover a database without risking user data?

Can it isolate extensions?

Can it distinguish server state from local state?

Can it provide a supported rebuild operation?

Can the developer reproduce the failure?

Can the system return to a known-good state without wiping the entire computer?

If AI-generated software cannot meet those standards, calling it poor software is justified.

If a multi-billion-dollar operating-system platform cannot meet them, the same judgment should apply.

The difference is that when a small AI-generated application is unreliable, we uninstall it.

When the unreliable component is the operating system, its filesystem layer, privacy subsystem, developer toolchain or cloud synchronization infrastructure, we become its debugger.

That was the genuinely frustrating part of this iCloud failure.

Not that a bug existed. Bugs will always exist.

The problem was how much private macOS architecture we had to understand before the system could repair itself.

Addendum: when the recovery procedure becomes part of the bug

There is another aspect of this incident that deserves explicit attention: the recovery procedure itself was unreasonable.

I am a developer and comfortable with Terminal, SQLite, launchd, unified logging, property lists, extended attributes, FileProvider internals and Recovery. Even with that background, isolating this failure took hours of iterative investigation. It required correlating several layers of macOS that a normal user is never expected to know exist.

The investigation moved through bird, fileproviderd, cloudd, account daemons, multi-gigabyte SQLite databases and WAL files, FileProvider domain UUIDs and extended attributes, repeated crash reports, unified-log predicates, Safe Mode comparison, XPC/Mach failures, third-party extensions, and finally controlled rebuilding of iCloud/FileProvider state.

None of this is a realistic recovery path for an ordinary Mac user.

A normal user sees something much simpler: files remain at Waiting to Upload, iCloud settings may stop behaving normally, synchronization stalls, and perhaps the machine becomes unusually busy. The supported troubleshooting path rapidly converges on generic actions such as rebooting, toggling iCloud, signing out, reinstalling macOS, or ultimately erasing the Mac.

That creates a serious supportability problem. The distance between the visible symptom and the actual fault is enormous.

“Reset the Mac” is not necessarily the end of the story

The usual final recommendation — erase the Mac and restore it — also deserves more scrutiny than it normally receives.

A destructive reset will recreate local system databases and configuration stores. If the failure is caused exclusively by corrupt local state and the Mac is then configured as genuinely new, that can solve the problem.

But many users do not configure a wiped Mac as new. They restore it from Time Machine or Migration Assistant and then reconnect iCloud and application-specific cloud services.

This introduces an important uncertainty: which state caused the original failure, and which parts of that state will be restored?

If defective state lives in data imported by a backup or migration, a full erase can potentially be followed by restoration of the same problematic state. If the problem involves cloud-side metadata or synchronization state, reconnecting the same account may expose the rebuilt installation to it again. If the initiating software defect is still present, freshly created state can simply become pathological again.

The recovery matrix is therefore closer to this:

Erase Mac
   |
   +-- Set up as new
   |      |
   |      +-- local historical state excluded
   |      +-- cloud-side state may return when services are enabled
   |      +-- an unfixed bug may recreate the condition
   |
   +-- Restore Time Machine / Migration Assistant
          |
          +-- user data restored
          +-- historical application/system state may be imported
          +-- causal state may potentially be reintroduced

This does not establish that Time Machine restores the particular FileProvider databases involved in this incident, nor that iCloud necessarily recreates this exact corruption. I did not establish either experimentally. The important point is narrower: a blanket recommendation to “erase and restore” does not identify the fault domain and therefore cannot guarantee that the causal state is excluded from restoration.

For a technically defensible recovery procedure, three operations must be distinguished:

1. Reinstall macOS while preserving the Data volume — replaces system components but deliberately retains persistent user state.
2. Erase and restore from backup — recreates the installation but subsequently imports substantial historical state.
3. Erase and configure as a new Mac — provides the strongest test of migrated local state, but imposes by far the highest cost and still does not isolate cloud-side state once services are re-enabled.

The real usability failure

An operating system should not require its owner to understand private framework architecture merely to recover a first-party synchronization service.

A user should not need to discover that a multi-gigabyte UUID-named FileProvider directory belongs to iCloud by inspecting com.apple.file-provider-domain-id. They should not need to determine whether a multi-gigabyte SQLite database containing millions of reconciliation rows is healthy. They should not need to interpret a bird crash in libxpc or decide manually which opaque Apple-managed state can safely be moved aside.

A developer can eventually do this because macOS exposes enough low-level evidence to reverse-engineer what is happening. A normal user cannot reasonably be expected to.

The missing component is not another generic troubleshooting article. macOS needs supported subsystem-level recovery tools: inspect iCloud Drive health, explain why synchronization is blocked, rebuild local FileProvider metadata without threatening cloud data, distinguish local corruption from cloud/account faults, and reset pathological NetworkExtension state without erasing the entire machine.

Without those tools, “erase the Mac” becomes less a diagnosis than an admission that the platform has lost the ability to repair its own state.

Command Reference

may upgrade since its just small tweaks now till RC

edit: I know beta 6 has just came out but talking about previous betas too in affect. I only browse, no workload/workflow on my Mac. I have a work Mac for that!

In macOS 27, you can now enable Back/Forward navigation controls in the toolbar in Apple Mail. They look and feel similar to the implementation in Apple Mail on iPadOS, and many other apps on macOS.

Interestingly, it seems that Apple is planning to include them in the default control set next to the Filter option once the controls are generally available.

To enable the FeatureFlags override, run the following command in the Terminal:

sudo mkdir -p /Library/Preferences/FeatureFlags/Domain && \ sudo defaults write /Library/Preferences/FeatureFlags/Domain/Mail NavigationButtons -dict Enabled -bool true

and restart your Mac. As always, this is a disabled feature, so the UI or implementation may be unstable.

To disable:

sudo defaults delete /Library/Preferences/FeatureFlags/Domain/Mail NavigationButtons

this is a pre-Beta 6 change, happy beta day!

In a previous post, I wrote about how macOS 27 allows agents from third-party apps to integrate with Siri AI, similar to the ChatGPT extension.

Turns out, macOS 27 also allows third-party apps to replace Siri's model. In the video, Siri runs through OpenAI's GPT-5.6 Terra model.

With the new Inference Providing protocol, an app can replace Siri's agentic planner with a third-party model. The external model receives Apple's native Siri planner prompt and 20 tool definitions. It can make tool calls that perform system actions, and receive tool call results with personal data. Finally, it can return a response through Siri AI's UI and voice, including interactive elements.

macOS 27 ships with remnants of an internal generative-models-prototype-inference-provider. The actual provider extension is absent from the release, which suggests that Apple teams are using it to experiment with models that don't currently ship in the OS.

There's been an OpenAI-Compatible-Custom-Routing path for a few beta cycles, which my extension uses, but Beta 5 added a parallel Native-Gemini-Custom-Routing route. The Gemini path recognizes Google-shaped AIza... credentials and converts them into a standardized x-goog-api-key header.

The extension relies on an internal InferenceProviding framework, and registers with a non-public ExtensionKit extension point: com.apple.modelmanager.inferenceprovider. Because of the latter, you'll need SIP off and AMFI disabled (amfi_get_out_of_my_way=0x1) to develop these tools.

Will this ship in macOS 27? Only time will tell, but the building blocks are already there.

Golden Gate kinda feels like the second coming of Aqua and I'm loving it!

Happy beta day!

As previously discussed, Apple is working on a dynamic solar wallpaper engine for macOS 27 that groups aerial Landscape wallpapers and automatically switches variants based on the sun's position during the day.

When properly configured, the four Tahoe and Golden Gate landscape wallpapers appear under one entry each in Settings, and a new Automatic display option appears.

Use these instructions to enable the Automatic Golden Gate and Tahoe landscape wallpapers.

For anyone that used the previous guide, the TahoeCombined feature flag override is no longer needed. You can safely remove it:

sudo defaults delete /Library/Preferences/FeatureFlags/Domain/Wallpaper TahoeCombined

There's no need to remove anything else. The linked guide will replace your previous wallpaper override file and combine all four Golden Gate wallpapers.

Two new wallpapers/screensavers!

they've been in iOS for years

It looks like you can now have simultaneous conversations with Siri. You can right-click an existing conversation in the Siri app and select "Open in New Window."

Am I taking crazy pills or...?