Password prompt are not working with PSSO enabled in MAC OS 27 while the same working in MAC OS 26. Issue is observed after updating to OS 27. Is there a known issue reported with OS version 27 and any fix expected in upcoming versions.

I’m using Virtualization.framework on Apple silicon with a Linux guest (VZGenericPlatformConfiguration + VZLinuxBootLoader). The VM is intentionally minimal: 2 vCPUs, 2 GiB RAM 1 virtio entropy device 2 virtio block devices (base read-only, scratch read-write) 1 virtio console with 2 ports, both isConsole = false no serial, network, sharing, socket, USB, audio, graphics, keyboard, pointing, balloon, or custom virtio devices no EFI variable store nested virtualization disabled On the normal success path the host does not call requestStop(). A destructive host stop is tracked separately and treated as failure. I need a supported way for the host to distinguish: a clean Linux guest shutdown intentionally issued by the guest after its application protocol and cleanup have completed, from an abnormal or independent shutdown path such as kernel panic, watchdog, thermal / hardware-protection shutdown, emergency shutdown, or another kernel/platform-triggered stop. guestDidStopVirtualMachine tells me that the guest stopped, but I cannot find a public contract that says which Linux/kernel/platform histories can produce that callback, nor a public shutdown reason/initiator value. My specific questions are: For VZGenericPlatformConfiguration + VZLinuxBootLoader, what is the documented complete guest-visible shutdown/reset event surface, including implicit platform events not represented by explicitly configured device arrays? What Linux-facing mechanism does VZVirtualMachine.requestStop() use in this configuration? Can guestDidStopVirtualMachine also be emitted after panic, watchdog, thermal/hardware-protection shutdown, emergency shutdown, or another guest-kernel/platform shutdown source? Are those abnormal cases guaranteed to arrive through virtualMachine(_:didStopWithError:) instead? If guestDidStopVirtualMachine can represent multiple terminal histories, is there any supported public API or documented guarantee that lets the host distinguish a clean guest system-off from the abnormal/platform-triggered cases? If not, is it correct to treat this distinction as unspecified by the public Virtualization.framework contract? I do not need private implementation details. A public/supported contract describing which terminal histories can produce each delegate callback would be enough. This matters because the host is fail-closed: it must accept PASS only after an application-level success condition and a clean guest shutdown. A successful runtime observation alone is not enough for the qualification. Environment: Apple silicon / arm64 macOS 26.6.2 (25G83) public Virtualization.framework APIs

In macOS Tahoe 26.7 or Sequoia 15.7.5 (and probably other prior versions), when you install a .pkg, symlinks are followed: i.e. if your payload install a file to /Users/Shared/my-folder and, on the target volume, the /Users/Shared/my-folder item is a symbolic link to /Users/Shared/actual-folder, the file will be installed inside /Users/Shared/actual-folder. It used to be possible to tell the installation framework/mechanism not to follow symbolic links by using the followSymLinks attribute in the raw package PackageInfo file. And in this case, the symbolic link would be replaced by a real directory and the file would be installed where it was supposed to be installed. This attribute is apparently not taken into account anymore by the framework/mechanism. [Q] Is this on purpose or is it a bug (in shove for instance)? If it is on purpose, why was it considered a good idea to always follow symbolic links considering the security issues this can create?

I’ve retested Sidecar after updating both my MacBook Pro to the current macOS 27 release and my iPad to the current iPadOS 27 release. When the iPad is connected through Sidecar and set to Use As → Extended Display, macOS does not offer a Rotation control for that display. Compatible conventional external displays do expose rotation options in System Settings → Displays. Physically rotating the iPad by 90° also leaves the Sidecar display in landscape orientation. This is consistently reproducible for me: Connect the iPad to the Mac using Sidecar. Select Use As → Extended Display. Open System Settings → Displays and select the iPad. Observe that no Rotation control is available. Physically rotate the iPad 90° into portrait orientation. Actual result: Sidecar remains connected and otherwise functions normally, but the iPad display remains landscape. No 90°/270° Rotation option is available, and physically rotating the iPad does not change the extended-display orientation. Expected result: An iPad used as an extended Sidecar display should be able to operate in portrait orientation, either automatically using the iPad’s orientation sensor or through 90°/270° Rotation controls in macOS Displays. I’ve filed the current issue through Feedback Assistant as FB24897273. I also previously filed the related portrait/full-screen limitation as FB22051066. Given that iPad natively supports portrait orientation, macOS already supports 90°/270° rotation for external displays, and Sidecar presents the iPad as an extended Mac display, the absence of any portrait option seems like a significant and increasingly conspicuous limitation rather than an inherent hardware constraint. This is particularly difficult to understand now that macOS/iPadOS 27 have substantially expanded Sidecar interaction. Is there any technical or platform constraint that prevents Sidecar from supporting the iPad’s native portrait orientation? If not, I hope FB24897273 can be considered for the appropriate Sidecar/display engineering team. I’m happy to provide additional reproduction details or diagnostics if useful.

Hello, I am working on a Launch Daemon (part of a DLP). One of its requirements is to modify PDF files on the fly—specifically, to reduce the page count and truncate the document to meet specific size criteria. I am planning to use the CoreGraphics framework, specifically CGPDFDocumentRef, CGPDFPageRef, and CGDataConsumerRef to rebuild the document in memory and write the modified version. However, since CoreGraphics is historically tied to the graphic subsystem, could you please confirm if the specific PDF-handling subset of CoreGraphics (CGPDFDocument, CGPDFContext) is completely session-independent, memory-safe, and daemon-safe to use from a launch daemon context without any Aqua session? If using CoreGraphics in this context is discouraged, what are the recommended best practices or native alternatives for performing headless PDF modifications within a system daemon on modern macOS? Thank you in advance!

I am testing NEURLFilter on macOS using the SimpleURLFilter sample, and I am seeing a failure from neagent while it is saving the local URL prefilter Bloom filter to its mmap file. The relevant log is: neagent +[NEBloomFilter mmapToFile:data:dataLength:numberOfBits:numberOfHashes:murmurSeed:tag:]: NEBloomFilter - failed to open mmap file /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.com.example.apple-samplecode.SimpleURLFilterTC3Q7MAJXF <errno 13 - Permission denied> neagent <NEAgentURLFilterExtension: 0xc8ce64280>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to save first fetch of pre-filter data Environment: macOS: 26.5.1 (25F80) Xcode: 26.5 (17F42) Platform: macOS Signing type: Apple Development (automatically manage signing) What I am doing: Build and run the containing app. Save and enable the NEURLFilterManager configuration. The URL filter provider starts. The provider's prefilter code is reached. neagent logs the mmap failure above while trying to open a temporary file under /private/var/db/urlPrefilter. Expected result: neagent should be able to create or open its system-managed URL prefilter cache / mmap file under /private/var/db/urlPrefilter, and the local Bloom filter should be loaded successfully. Actual result: neagent fails to open the temporary mmap file with errno 13 Permission denied: /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.<bundle/team-specific suffix> I am not manually creating, modifying, or chmod/chown-ing /private/var/db/urlPrefilter or anything inside it. The directory and its contents are entirely system-managed. The failure appears to happen inside neagent while it is handling the system-managed URL prefilter cache. The failure occurs at the mmapToFile: step while neagent saves the Bloom filter prefilter data. Directory state: drwxr-xr-x 2 root wheel 64 /private/var/db/urlPrefilter Has anyone else encountered this? Any suggestions on what could cause neagent to fail with errno 13 on its own mmap file under /private/var/db/urlPrefilter?

Hello, We are seeing what appears to be a regression in the Core ML multifunction ML Program loading path on macOS 27.0. A compiled multifunction ML Program is correctly recognized by MLModelAsset and MLModelStructure, but loading either named function through MLModel fails with an error claiming that the model is not an ML Program. Environment macOS 27.0 Build: 26A428 Apple silicon Mac BABANE 1.0.4, build 16 Application built with the macOS 26.5 SDK Reproduces both inside and outside App Sandbox Approximately 98 GiB of disk space is available Public reproduction BABANE is available from the Mac App Store: BABANE on the App Store Apple engineers can reproduce the issue without receiving a separate model archive: Install BABANE from the App Store on macOS 27.0. Download either available translation model in the app. The model is delivered using Apple-Hosted Background Assets. Trigger model loading by starting a translation. Core ML fails while loading the first named function. The downloadable models are approximately 1.9 GB, so the App Store build is the most practical complete reproduction environment. Model structure The model is a specification-version-9 ML Program containing two functions: infer prefill Core ML correctly recognizes both functions: let asset = try MLModelAsset(url: compiledModelURL) let functionNames = try await asset.functionNames print(functionNames) Output: ["infer", "prefill"] MLModelStructure also returns a .program structure containing both functions. Loading code import CoreML func loadModel( at url: URL, functionName: String? ) throws -> MLModel { let configuration = MLModelConfiguration() configuration.computeUnits = .cpuAndNeuralEngine configuration.functionName = functionName return try MLModel( contentsOf: url, configuration: configuration ) } Loading either function: try loadModel(at: compiledModelURL, functionName: "infer") or: try loadModel(at: compiledModelURL, functionName: "prefill") fails with: `MLModelConfiguration`'s `.functionName` property must be `nil` unless the model type is ML Program. This contradicts the results returned by MLModelAsset and MLModelStructure. Setting functionName to nil is not a workaround. It fails with: This MLModel doesn't support the multi-function description syntax. Unified logging Immediately before the public Core ML error, unified logging reports: E5RT encountered an STL exception. E5RT: <private> (11) Core ML then returns the misleading functionName error. Tests performed We tested: functionName = "infer" functionName = "prefill" functionName = nil .cpuOnly .cpuAndGPU .cpuAndNeuralEngine .all App Sandbox application Non-sandboxed command-line executable Existing .mlmodelc A newly compiled .mlmodelc produced on macOS 27 All named-function combinations fail in the same way. The failure is independent of compute-unit selection and App Sandbox. The source package recompiles successfully on macOS 27, but the newly compiled model still fails to load. As an additional control: A system-provided multifunction ML Program exhibits the same loading failure on this installation. A single-function Core ML model loads successfully. This appears specific to the multifunction model loading path. Documentation The current Core ML documentation still describes MLModelAsset.functionNames as the way to discover functions and MLModelConfiguration.functionName as the way to select one: MLModelConfiguration.functionName MLModelAsset.functionNames We could not find any macOS 27 documentation or release-note entry stating that this behavior changed, that named functions now require a different loading API, or that a new entitlement is required. We found some potentially related reports: Core ML loading crash on macOS 27.0 build 26A428 Historical multifunction model loading crash Core ML/E5RT AOT loading regression with an Apple DTS response None of these reports documents the exact functionName failure described here. Expected behavior A model recognized as a multifunction ML Program should load when MLModelConfiguration.functionName is set to one of the names returned by MLModelAsset.functionNames. Actual behavior MLModel rejects the named function and incorrectly reports that the model is not an ML Program. Questions Is this a known macOS 27.0 regression in the Core ML multifunction loading path? Does MLModelConfiguration.functionName still accept names returned by MLModelAsset.functionNames on macOS 27? Is there a new required loading API, deployment target, SDK, entitlement, or model-packaging rule? Is there a supported workaround other than exporting each function as a separate model? Which diagnostics should we attach to a Feedback Assistant report besides the reproducer, unified logs, sysdiagnose, and exact OS/Xcode builds? Thank you.

The following SwiftUI app snippet causes a 100% reproducible crash on macOS. import SwiftUI struct Rule: Identifiable { let id = UUID() var text = "" } @MainActor @Observable final class Policy { var rules: [Rule] = [ .init(text: "Row 1"), .init(text: "Row 2") ] } @main struct MyApp: App { @State private var policy = Policy() var body: some Scene { WindowGroup { List { ForEach($policy.rules) { $rule in HStack { TextField("Value", text: $rule.text) Spacer() Button("Remove") { policy.rules.removeAll { $0.id == rule.id } } } } } .padding() } } } I first encountered this on macOS 27, but have also reproduced it on macOS 26.6.2. In both cases, the app was compiled with Xcode 27 from a standard “New Project” template. (Default build settings: Swift 5, Main Actor Isolation, Approachable Concurrency enabled.) Steps to reproduce: Open Xcode and select “New Project… > App”. Copy and paste the snippet above into a Swift file. Build and run. Click one of the two text fields to give it focus. Click the Remove button for that same row. The application crashes with an access violation. My assumption is that the row is removed from the array while the TextField still holds a Binding to it. When the text field subsequently loses focus, it attempts to write through a binding whose underlying element no longer exists. There are ways to work around this, but I’d be interested in guidance from the SwiftUI or AppKit team on the intended way to handle this situation. The same kind of issue can arise with custom bindings, but it is particularly difficult to guard against when framework controls perform reactivate actions, like when it loses focuses.

As part of the OpenJDK testing we run several regression tests, including for Java SE networking APIs. These APIs ultimately end up calling BSD socket functions. On macos, starting macos 26, including on recent 26.2 version, we have started seeing some unexplained but consistent exception from one of these BSD socket APIs. We receive a "ENOBUFS" errno (No buffer space available) when trying to construct a socket(). These exact same tests continue to pass on many other older versions of macos (including 15.7.x). After looking into this more, we have been able to narrow this down to a very trivial C code which is as follows (also attached): #include <stdio.h> #include <sys/socket.h> #include <string.h> #include <unistd.h> #include <sys/errno.h> static int create_socket(const int attempt_number) { const int fd = socket(AF_INET6, SOCK_STREAM, 0); if (fd < 0) { fprintf(stderr, "socket creation failed on attempt %d," " due to: %s\n", attempt_number, strerror(errno)); return fd; } return fd; } int main() { const unsigned int num_times = 250000; for (unsigned int i = 1; i <= num_times; i++) { const int fd = create_socket(i); if (fd < 0) { return -1; } close(fd); } fprintf(stderr, "successfully created and closed %d sockets\n", num_times); } The code very trivially creates a socket() and close()s it. It does this repeatedly in a loop for a certain number of iterations. Compiling this as: clang sockbufspaceerr.c -o sockbufspaceerr.o and running it as: ./sockbufspaceerr.o consistently generates an error as follows on macos 26.x: socket creation failed on attempt 160995, due to: No buffer space available The iteration number on which the socket() creation fails varies, but the issue does reproduce. Running the same on older versions of macos doesn't reproduce the issue and the program terminates normally after those many iterations. Looking at the xnu source that is made available for each macos release here https://opensource.apple.com/releases/, I see that for macos 26.x there have been changes in this kernel code and there appears to be some kind of memory accountability code introduced in this code path. However, looking at the reproducer/application code in question, I believe it uses the right set of functions to both create as well as release the resources, so I can't see why this should cause the above error in macos 26.x. Does this look like some issue that needs attention in the macos kernel and should I report it through feedback assitant tool?

Transcript.CustomSegment and the .custom case on Transcript.Segment were in the Xcode-beta 27 builds. WWDC26 session 339 covers them as the way a model package extends the protocol for new modalities and server side tool output. In the Xcode 27 GM they are gone along with the matching action on the executor generation channel. Is there any additional information as to what happened to custom segments, a replacement, etc? I don't see any mentions of this change in any release notes, though perhaps I'm looking in the wrong place.

I have a narrow follow-up question about file-based Keychain partition lists, this time specifically for Developer ID Installer signing with productbuild. I’ve reviewed the existing guidance around Keychain ACLs and partition lists. For codesign, the security documentation explicitly calls out the apple: partition requirement. I haven’t been able to find an equivalent supported statement for productbuild. My setup uses separate private keys for the two roles: Developer ID Application → /usr/bin/codesign Developer ID Installer → /usr/bin/productbuild The trusted-application ACL is also role-specific. I’m trying to determine the corresponding partition constraint for the Installer key without inferring it from a configuration that merely happens to work. So my question is: When /usr/bin/productbuild uses a Developer ID Installer private key from a file-based Keychain, what partition-list requirement should that key use according to the supported macOS contract? In particular, should the Installer key use apple:, apple-tool:, some combination of partitions, or something else? I’m not looking for a broad CI workaround or an “Allow all applications” configuration. I’m trying to keep the Application and Installer roles separate and use only the partition constraint actually required by the Apple signing tool. If there is no documented/supported partition value for productbuild, knowing that limitation would also answer the question. Thanks.

I’m evaluating whether Apple cloud signing can replace locally managed Developer ID private keys in a macOS distribution pipeline. I’ve read the documentation on cloud-managed certificates and the Xcode cloud-signing workflow. I understand the supported Developer ID Application flow through Xcode’s archive/export distribution process, but I haven’t been able to find an equivalent documented workflow for Developer ID Installer. I’m also checking this against the current Xcode 27 / macOS 27 toolchain, in case the supported cloud-signing scope has recently expanded. My distribution pipeline produces custom flat installer packages using productbuild. It uses separate Developer ID Application and Developer ID Installer identities, as expected. So my main question is: Can a custom macOS .pkg be signed with a cloud-managed Developer ID Installer identity using a currently supported Apple workflow? More specifically, is there a supported cloud-signing equivalent of using a local Developer ID Installer identity with productbuild / productsign, or are Developer ID Installer package signatures still expected to use a locally or externally available signing identity? I’m specifically asking about custom Developer ID packages distributed outside the Mac App Store, rather than an App Store or Xcode-managed installer workflow. If cloud-managed Developer ID Installer signing isn’t currently supported, knowing that limitation would answer my question as well. Thanks.

Hello, I am tracking a severe local networking regression on macOS Golden Gate 27.2 Developer Beta (build 26B5086k) running on MacBook Pro M4 Pro hardware. Despite negotiating a strong physical Wi-Fi connection with high PHY rates (1200+ Mbps) and excellent RSSI, actual throughput collapses dramatically and local gateway latency spikes uncontrollably whenever AWDL and AirDrop discovery are actively processing. Key Diagnostic Metrics Observed AWDL Manually Disabled: Executing sudo ifconfig awdl0 down completely drops packet loss to 0%, stabilizes gateway latency entirely, and restores baseline throughput. AirDrop Turned Off (AWDL Active): Disabling AirDrop via System Settings while keeping AWDL active stops the catastrophic latency spikes. This strongly suggests the trigger is linked directly to AirDrop's continuous background discovery/scanning activity rather than basic AWDL link states. Environment Isolation Performed Safe Mode: The issue persists cleanly while booted into macOS Safe Mode, ruling out third-party launch kexts, background daemons, or custom VPN software. Cross-AP Testing: The behavior follows the Mac across completely different access points, occurring on a dedicated Wi-Fi 7 home environment (tested across 5GHz and 6GHz channels) as well as an iPhone Personal Hotspot over cellular. Control Device: Same-location control testing with an iPhone shows perfect gigabit-class speeds, confirming the RF environment and network backhaul are perfectly healthy. I have already submitted a comprehensive sysdiagnose archive and wireless diagnostic log package directly to Apple. Feedback ID: FB24842970 Curious if anyone else with an M4 Pro on this build is seeing similar behavior. If this is happening on your end too, it might be worth submitting a bug report and referencing FB24842970 so Apple can group our logs together and look into a patch.

I encountered a severe NSColorSampler failure on macOS 27.0 (26A5425a). After invoking: NSColorSampler().show { selectedColor in // Handle selected colour } the system colour sampler became stuck. The pointer disappeared and all mouse clicks were captured across macOS. Pressing Escape did not recover it. Quitting the host application also did not restore clicking. The Apple-owned process remained active after the application exited: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/ColorSampler.xpc/Contents/MacOS/ColorSampler Sending SIGTERM to that process had no effect. Force-terminating it with SIGKILL immediately restored mouse clicking. Environment: macOS 27.0, build 26A5425a MacBook Pro Mac16,8 Apple M4 Pro SwiftUI content hosted inside a borderless AppKit window Expected behaviour: selecting a colour, pressing Escape, or terminating the host application should cancel sampling and release all captured input. Actual behaviour: ColorSampler.xpc survives the host application and continues preventing all mouse clicks system-wide. Feedback Assistant report: FB24722293 Has anyone else reproduced this with NSColorSampler, particularly from a borderless AppKit window?

I'm a font developer. In the development process, I will revise a font and overwrite the OTF file that is currently enabled (registered) with macOS. If I then launch an app, it will immediately use the revised version of the font; while apps that are already loaded will continue to use the old version. This suggests that each app is loading new and separate font data, rather than getting it from some existing cache in memory. Yet macOS does have a "font cache" of some sort. Some apps, like TextEdit, seem to only load the fonts that they need to use. However, other apps, like Pages, load every enabled (registered) font on the OS!! (According to the Open Files list in Activity Monitor.) Given that /System/Library/Fonts/ is 625 Mb, and we can't disable any of it, isn't that a lot of data to be repeating? How many fonts is too many fonts? I can't find much documentation about the process.

FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.

The iOS 26 sample below speaks well on iPhone/iPad devices and the iOS simulator. But it does not speak on "Mac (Designed for iPad)", with a voice downloaded via the macOS settings. Instead it issues this warning : Invalid maui voice identifier com.apple.voice.enhanced.en-US.Samantha How to make an iOS app speak on "Mac (Designed for iPad)", with a downloaded voice ? Note : I use iOS 26.5.2 and macOS 26.5.2. I use voices that can be found in System Settings > Accessibility > Read & Speak > System voice. I have checked that "Samantha (Enhanced)" is the "System voice" in the macOS settings. I have checked that the same issue occurs with other voices and other languages. There is no such issue for a voice that never needs to be downloaded. import AVFAudio import SwiftUI @main struct SampleApp: App { var body: some Scene { WindowGroup { SampleView() } } } struct SampleView: View { private var synthesizer = AVSpeechSynthesizer() var body: some View { Button("Speak", action: speak) } private func speak() { let utterance = AVSpeechUtterance(string: "I speak English.") utterance.voice = AVSpeechSynthesisVoice(language: "en") self.synthesizer.speak(utterance) } }

I have a follow-up question about file-based Keychain ACLs, this time specifically about inspecting the authorization state after it has been configured. I’ve been looking through the public SecAccess / SecACL / SecTrustedApplication APIs. I can enumerate ACL entries and their authorizations, and SecACLCopyContents gives me the trusted applications associated with an ACL. What I haven’t been able to establish is whether the complete stored caller-matching condition can be read back through a supported API. In particular, SecTrustedApplicationCopyData returns opaque application-identifying data. Is that data intended to be a complete representation of the condition that the Keychain will use to recognize that trusted application? Or can the stored trusted-application condition contain additional code-signing requirements or other matching constraints that are not represented by SecTrustedApplicationCopyData? My higher-level requirement is to verify, after configuring a private key, that its effective authorization scope is no broader than an independently reviewed policy. Ideally I would like to compare: the authorized private-key operations; all trusted-application subjects and their complete matching conditions; prompt-related state; and partition-list constraints. Is there a public and supported API, or an Apple-provided tool with a supported machine-readable contract, that can enumerate the complete effective authorization state of a private key in a file-based Keychain? I’m deliberately not trying to infer this from the current executable’s path, designated requirement, hash, security dump-keychain output, or representative negative tests unless Apple considers one of those to be the supported way to establish the stored authorization state. I realise from the existing guidance, including TN3137 and the discussion around file-based Keychains, that this is legacy technology. If complete supported introspection simply isn’t available for this model, knowing that limitation would also answer my question. Thanks.

I’m seeing a reproducible UI bug with Spotlight on macOS 27 RC (26A428). The issue has been present since at least build 26A5416b (Developer Beta 6 / Public Beta 4), persisted through subsequent beta releases, and is still reproducible on RC 26A428. When I open Spotlight using the new Search or Ask interface and begin typing, the entered query text can become completely invisible from approximately the second character onward, even though Spotlight continues searching and displaying results normally. The interesting part is that the issue seems tied to Spotlight updating its search results. For example: Open Spotlight. Type a character that quickly matches something on the Mac. Continue typing. Once the results update, the query text becomes invisible. If I type random characters extremely quickly, before Spotlight has time to return a result for the first few characters, the text may remain visible. Another useful detail: after the query text disappears, pressing Delete/Backspace causes it to become visible again. The search itself is still functioning, the problem appears to be with rendering or state updates in the new Siri-integrated Spotlight query field, rather than with Spotlight search/indexing itself. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by user preferences, caches, login items, or third-party software. I submitted a screen recording through Feedback Assistant that clearly shows the text disappearing as results update. Feedback: FB24462893 Is anyone else seeing this on the RC? The correlation between the text disappearing and the results UI updating makes me suspect a rendering/state-update issue in the new Spotlight interface.

While testing a native SwiftUI app on macOS 27.0 beta (26A5421a), built with Xcode 27.0 beta (27A5209h), we observed toolbar button groups briefly dimming when a custom sidebar animated open or closed. Filed as FB24782376. Our layout uses an HStack with a .bar sidebar background, animated sidebar width/offset, scrollable detail content, and a persistent root toolbar. The toolbar includes sidebar/add and play/edit/delete groups plus a separate terminal button. The change that removed the measured transition in this app was: .toolbar { // Existing toolbar items } .toolbarBackgroundVisibility(.hidden, for: .windowToolbar) This hides the automatic full-width toolbar backdrop. In our configuration, the standard native glass backgrounds around toolbar buttons remain. It changes the toolbar background design, so test it against your own content, appearance settings, and supported macOS versions. What we measured Read-only NSView/CALayer instrumentation showed a toolbar-wide hosting layer receiving a CATransition of type fade, lasting 0.25 seconds. Toolbar items stayed enabled, button instances stayed stable, and individual view/presentation-layer opacity remained 1. A keyboard-triggered comparison also kept the app/window active, key, and main throughout. Forcing the background visible, restricting the sidebar material’s safe-area extent, and isolating sidebar state below the toolbar-owning view did not remove the transition. Hiding the automatic toolbar background did. With standard SwiftUI buttons and the original layout restored, the hidden-background version recorded no toolbar animations on both opening and closing (91 samples per transition). These are app-side samples, not pixel-by-pixel proof or an independent minimal reproduction. This is a tested workaround for our configuration and a suspected system rendering interaction, not an Apple-confirmed diagnosis or a universal fix for toolbar flicker. We have not established behavior on other macOS versions. Related reports, not confirmed duplicates Toolbar jitter when toggling a sidebar (2022): intermittent movement of a share button during sidebar toggles, with another developer reporting similar behavior. Toolbar flashes above a translucent sidebar (2021): brief white flashes during periodic updates in full screen. Both predate this macOS 27 observation and have different triggers or appearances. They do not establish the same root cause. API reference: Apple’s toolbarBackgroundVisibility documentation. If you see a similar brief dimming on this configuration, comparing automatic versus hidden toolbar background visibility may help narrow it down. Please include your OS build, layout, and whether the comparison changes the symptom when filing feedback.