After installing macOS Tahoe26.0 beta5 (25A5338b) or beta4, a memory and disk leak appears, likely caused by Spotlight indexing. The mds_stores process consumes up to 60 GB of RAM, while disk writes continue until an additional 50 GB is filled. Once the maximum is reached, the system frees the space and the cycle repeats, leading to severe memory leakage. In the available space, system data occupies as much as 150 GB. System Versions Affected: macOS Tahoe26.0 beta5 (25A5338b) and beta4. Reproduction Steps: Occurs immediately after booting up, with no additional user actions. Workaround: Booting into Safe Mode prevents the issue from occurring. Possible Cause: A bug in Spotlight indexing. In Safe Mode, Launchpad cannot search for applications, and no other issues have been observed so far. This strongly suggests that Spotlight indexing is the root cause. Potentially Affected Software: Developer-related tools such as Node.js, Maven, Vue.js, etc. It is possible that Spotlight is indexing developer project dependency directories (e.g., node_modules), which contain a large number of small files that do not require indexing, leading to this problem.

问题描述： 在这两个版本后出现了可能是聚焦索引导致的内存、硬盘泄漏，使得mds_stores内存占用高达60G，硬盘内存持续写入50G，上述情况持续到最大后，系统释放空间后继续重新写入，导致内存严重泄漏，在可用空间中，系统数据占用高达150G， 系统版本： macOS Tahoe26.0beta5（25A5338b）、以及beta4 复现步骤： 开机即启动，没有任何操作步骤 解决方法： 进入安全模式后这个问题未复现 可能原因： 聚焦索引出现bug，在安全模式下“启动台”无法搜索应用程序，暂时没有发现其他问题，极有可能是聚焦索引出现问题 可能影响到的软件： node.js、meven、vue等与开发者相关的软件，既有可能使聚焦索引了开发者的项目依赖文件节点模块，它包含有极其大量的小文件，这些文件不需要索引，可能是这个问题导致。 ###问题截图

When using NSTableView or NSOutlineView, if you use an NSTableCellView and wire up the .imageView and .textField properties then you get some "free" behaviour with respect to styling and sizing of those fields. (ex: They reflect the user's preferred "Sidebar Icon Size" as selected in Settings. ) If I'm using a SwiftUI View inside an NSTableCellView, is there any way to connect a Text or Image to those properties? Consider the following pseudo code: struct MyCellView: View { let text: String let url: URL? var body: some View { HStack { Image(...) // How to indicate this is .imageView? Text(...) // How to indicate this is .textField? } } } final class MyTableCellView: NSTableCellView { private var hostingView: NSHostingView<MyCellView>! init() { self.hostingView = NSHostingView(rootView: MyCellView(text: "", url: nil)) self.addSubview(self.hostingView) } func configureWith(text: String, url: URL) { let rootView = MyCellView(text: text, url: url) hostingView.rootView = rootView // How can I make this connection? self.textField = rootView.??? self.imageView = rootView.??? } } I'm ideally looking for a solution that works on macOS 15+.

We use as content filter in our app to monitor flows, we gather data about the flow and block flows deemed suspicious. Our content filter is activated/deactivated by a UI app but the flows are reported via XPC to a separate daemon process for analysis. As of macOS 15, we are seeing cases where flows are missing or flows are not received at all by the content filter. The behaviour is not consistent, some devices seem to receive flows normally but others don't. It appears Intel devices are much less prone to showing the problem, whereas Arm devices routinely exhibit missing flows. On macOS 14 or earlier, there is no sign of missing flows. Testing on earlier beta versions of macOS 15 did not appear to show the problem, however I can't rule out if issue was present but it wasn't spotted. Experimenting with simple examples of using a content filter (e.g. QNE2FilterMac) does not appear to reproduce the issue. Questions, What has changed between macOS 14 and 15 that could be the cause of the lack of flows? Is our approach to using an app activated content filter reporting to a daemon connected via XPC unsupported?

Whenever I try to initialize a LanguageModelSession (let session = LanguageModelSession()), my app crashes with EXC_BAD_ACCESS. SystemLanguageModel.default.availability returns available. I tried running the two sample projects I found that use Foundation Models, FoundationModelsTripPlanner and SwiftTranscriptionSampleApp, and they both also crash—immediately on launch. I commented out the Foundation Models logic from the SwiftTranscriptionSampleApp and ran it again, and it no longer crashed. I'm on macOS 26 Beta 4 on an M1 Pro device. I'm based in Austria (EU), if that matters.

In the latest beta of Ventura (and perhaps earlier versions) there is a section of the System Settings > General > Login Items pane called "Allow in Background". It appears that helpers (LaunchAgents/LaunchDaemons) that are installed by apps are listed here. As you can see in the screenshot below, I have 3 such items installed on my test system. The per User LaunchAgent for the Google Updater, the WireShark LaunchDaemon for the ChmodBPF script, and the LaunchDaemon for my userspace CoreAudio Driver (labelled "Metric Halo Distribution, Inc."). The WireShark and Google Updater have nice user identifiable names associated with them, whereas my Launch Daemon only has my company name associated with it. I don't see anything in the plists for Wireshark or GoogleUpdater that seem to specify this user-visible string, nor in the bundles the plists point to. How do I go about annotating my LaunchDaemon plist or the helper tool's plist so that the string in this pane helps the user properly identify what this Background item is for so that they don't accidentally turn it off and disable the driver they need to use our audio hardware? Obviously, we will document this, but just as obviously users don't always read the docs, and it would be better if the user just could make the immediate association that this Background item is needed for our CoreAudio driver.

Hello, I am currently investigating if we can disable usage of QUIC on application level. I know we can set enable_quic from /Library/Preferences/com.apple.networkd.plist to false but it will have a global impact since this is a system file, all the applications on machine will stop using QUIC. I don't want that. What i am looking for is to disable QUIC only for my application. Is there any way i can modify URLSession object in my application and disable QUIC? or modify URLSessionConfiguration so system will not use QUIC?

Hello, I have a macOS app built with Flutter’s macOS target (native Xcode project). The app is unsigned (no Developer ID code signing / notarization). The .app bundle looks valid: CFBundlePackageType = APPL Unique CFBundleIdentifier No LSUIElement or LSBackgroundOnly Executable exists and is runnable Placed at /Applications/MyApp.app (top-level), runs fine from Finder However, it does not show up in Launchpad. What I tried: Remove quarantine: xattr -dr com.apple.quarantine "/Applications/MyApp.app" Force Launch Services registration: /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f "/Applications/MyApp.app" Rebuild LS caches: /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user Reset Launchpad DB and restart Dock: defaults write com.apple.dock ResetLaunchPad -bool true && killall Dock Verified bundle structure/type: mdls -name kMDItemContentType -name kMDItemKind "/Applications/MyApp.app" → shows com.apple.application-bundle / Application Questions Is code signing/notarization required for an app to appear in Launchpad (even if it runs from Finder)? What additional conditions cause Launchpad to skip an otherwise valid, unsigned .app in /Applications? Are there deeper Launch Services or Dock database checks I can run to diagnose why this specific app is excluded?

It appears that starting with macOS Sequoia, Quick Look Preview extension no longer loads MapKit maps correctly anymore. Map tiles do not appear, leaving users with a beige background. Users report that polylines do render correctly, but annotations appears black. This was previously working fine in prior macOS versions including Sonoma. STEPS TO REPRODUCE Create a macOS app project, with an associated document. Ensure project has a Quick Look preview extension, with necessary basic setups. Ensure that the extension mentioned in (2) must have a MKMapView. Any other cosmetic changes, etc, does not need to be implemented to observe the base issue. Do note that it has been reported that in addition to the map tiles not loading, annotations don't render correctly as well.

This example application crashes when entering any text to the token field with FAULT: NSGenericException: The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. The app uses controlTextDidChange to update a live preview where it accesses the objectValue of the token field. If one character is entered, it also looks like the NSTokenFieldDelegate methods tokenField(_:styleForRepresentedObject:) tokenField(_:editingStringForRepresentedObject:) tokenField(_:representedObjectForEditing:) are called more than 10000 times until the example app crashes on macOS Tahoe 26 beta 6. I've reported this issue with beta 1 as FB18088608, but haven't heard back so far. I have multiple occurrences of this issue in my app, which is working fine on previous versions of macOS. I haven't found a workaround yet, and I’m getting anxious of this issue persisting into the official release.

In Swift I'm using unzip by launching a Process to unzip a file. I added a launchRequirement to the process in order to make sure the executable is code signed by Apple and the identifier is com.apple.unzip. After testing out my code on another machines (both physical and virtual), I found out that in some the identifier is actually com.apple.zipinfo, which broke the SigningIdentifier requirement. It's safe to assume that /usr/bin/unzip can be trusted since it's in a System Integrity Protection (SIP) location, but I'm wondering why this executable has different identifiers?

There are inconsistent behaviors in sleep/wake notification callbacks across different MacBook devices and macOS versions when the device is not connected to power, with or without external displays, entering sleep mode by closing the lid, and waking up from sleep by opening the lid. When monitoring the following Objective-C notifications: NSWorkspaceScreensDidSleepNotification NSWorkspaceScreensDidWakeNotification NSWorkspaceWillSleepNotification NSWorkspaceDidWakeNotification Different devices exhibit varying notification trigger patterns: Some devices trigger all four notifications properly Some devices fail to trigger NSWorkspaceScreensDidWakeNotification Some devices fail to trigger NSWorkspaceDidWakeNotification Some devices fail to trigger NSWorkspaceWillSleepNotification These inconsistencies make it challenging to implement reliable sleep/wake detection logic across different MacBook models and macOS versions.

working on app like dropbox and making a feature like dropbox offline download, so when a file is added from a system it will download in other system but as a placeholder file once user double click or open that file or after copy pasting to another location on demand need to download the file and after that do the action open or paste so here I need file open event and paste event to be block untill it downloads. how to achieve this uing obj c, c , c++ or swift

A few minutes back I filed a feedback assistant issue for this (FB18173706), but I am not sure I filed it in the correct category and I can't find a way to edit it either. So posting this message here just to have to assigned in the right category if appropriate. The issue is as follows. On macOS 26 Tahoe Beta, "man sw_vers" has this among other details: Previous versions of sw_vers respected the SYSTEM_VERSION_COMPAT environment variable to provide compatibility fallback versions for scripts which did not support the macOS 11.0+ version transition. This is no longer supported, versions returned by sw_vers will always reflect the real system version. It says that SYSTEM_VERSION_COMPAT is no longer supported. That doesn't look right, because running sw_vers as follows on macOS 26 Beta results in: SYSTEM_VERSION_COMPAT=1 sw_vers ProductName: macOS ProductVersion: 16.0 BuildVersion: 25A5279m i.e. setting the environment variable SYSTEM_VERSION_COMPAT=1 results in sw_vers reporting the version as 16.0. Now try with SYSTEM_VERSION_COMPAT=0, and the result is: SYSTEM_VERSION_COMPAT=0 sw_vers ProductName: macOS ProductVersion: 26.0 BuildVersion: 25A5279m notice the output says 26.0. So it appears that SYSTEM_VERSION_COMPAT is supported even on macOS 26. I think the man page requires an update to match this behaviour.

I was testing audio playback from YouTube in Safari, and the sound was clipping heavily. At first, I thought it might be due to the poor quality of my small sound system. However, when I took a screenshot and the screenshot sound effect itself produced a loud clipping noise, it became clear that this is not a mechanical problem with my speakers, nor an issue specific to YouTube or Safari. This appears to be a system-wide audio issue in macOS Tahoe 26 - Beta 5.

The new drag & drop APIs for macOS 26 are terrific, but there's an important missing piece. If I use draggable(containerItemID:), there's no way to provide a custom view for the drag image. Meanwhile the older API lets you provide a preview, but you miss out on things like multi-item drag and custom drag sessions. Is there some mechanism for supplying a preview that I'm not seeing? Without it, the drag interface in my apps is going to look terrible.

I successfully installed macOS Tahoe 26 in June on a separate external partition. Now I want to update to beta 5, but when the Mac restarts to install the update, it shows the progress indicator for a minute or two, then boots again into the main partition which has macOS 15.6. Am I required to install it from scratch?

In the LightweightCodeRequirements framework, there is a LaunchCodeRequirement object which can be used as a requirement object for a Process for example. What I don't understand (I admit my macOS low-level knowledge is limited) is that how can this be used in a secure way that doesn't fall victim of a Time-of-Check/Time-of-Use issue. e.g. I specify a LaunchCodeRequirement via Process.launchRequirement for my process, let's say /usr/local/bin/mycommandlinetool. The LaunchCodeRequirement specifies my development team and a developer ID certificate. The process must be started in some form, before a SecCode/SecTask object can be created, rather than a SecStaticCode object (which only guarantees its validity checks to be intact as long as the file is not modified). But if the process was started, then I have no tools in my set to prevent it from executing its initialization code or similar. Then, by the time I'm able to check via SecCode/SecTask functions the LaunchCodeRequirement, I might have already ran malicious code - if mycommandlinetool was maliciously replaced. Or does the operating system use a daemon to copy the executable specified for Process to a secure location, then creates the SecStaticCode object, assesses the LaunchCodeRequirement and if passed, launches the executable from that trusted location (which would make sure it is immutable for replacement by malicious actors)? I have a hard time understanding how this works under the hood - if I remember correctly these are private APIs.

Hi everyone, I have a macOS application that uses Screen Recording permission. I build my app with an adhoc signature (not with a Developer ID certificate). For example, in version 1.0.0, I grant Screen Recording permission to the app. Later, I build a new version (1.1.0) and update by dragging the new app into the Applications folder to overwrite the previous one. However, when I launch the updated app, it asks for Screen Recording permission again, even though I have already granted it for the previous version. I don’t fully understand how TCC (Transparency, Consent, and Control) determines when permissions need to be re-granted. Can anyone explain how TCC manages permissions for updated builds, especially with adhoc signatures? Is there any way to retain permissions between updates, or any best practices to avoid having users re-authorize permissions after every update?

I'm working on an enterprise product that's mainly a daemon (with Endpoint Security) without any GUI component. I'm looking into the update process for daemons/agents that was introduced with Ventura (Link), but I have to say that the entire process is just deeply unfun. Really can't stress this enough how unfun. Anyway... The product bundle now contains a dedicated Swift executable that calls SMAppService.register for both the daemon and agent. It registers the app in the system preferences login items menu, but I also get an error. Error registering daemon: Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} What could be the reason? I wouldn't need to activate the items, I just need them to be added to the list, so that I can control them via launchctl. Which leads me to my next question, how can I control bundled daemons/agents via launchctl? I tried to use launchctl enable and bootstrap, just like I do with daemons under /Library/LaunchDaemons, but all I get is sudo launchctl enable system/com.identifier.daemon sudo launchctl bootstrap /Path/to/daemon/launchdplist/inside/bundle/Library/LaunchDaemons/com.blub.plist Bootstrap failed: 5: Input/output error (not super helpful error message) I'm really frustrated by the complexity of this process and all of its pitfalls.