It's quite common for app bundles to be distributed in .zip files, and to be stored on-disk as filesystem-compressed files. However, having them both appears to be an edge case that's broken for at least two major releases! (FB19048357, FB19329524) I'd expect a simple ditto -x -k appbundle.zip ~/Applications (-x: extract, -k: work on a zip file) to work. Instead it spits out countless errors and leaves 0 Byte files in the aftermath 😭 Please fix.

Hi,Does anyone else encountered a delayed or unresponsive change when trying to change input languageon macos Sierra?Beta1 and 2 same problem.Working great on El Capitan.Thanks in advanced

I am developing a remote support tool for macOS. While we have successfully implemented a Privileged Helper Tool and LaunchDaemon architecture that works within an active Aqua session, we have observed a total failure to capture the screen buffer or receive input at the macOS Login Window. Our observation of competitor software (AnyDesk, TeamViewer) shows they maintain graphical continuity through logout/restart. We are seeking the official architectural path to replicate this system-level access. Current Technical Implementation Architecture: A root-level LaunchDaemon manages the persistent network connection. A PrivilegedHelperTool (installed in /Library/PrivilegedHelperTools/) is used for elevated tasks. Environment: Tested on macOS 14.x (Sonoma) and macOS 15.x (Sequoia) on Apple Silicon. Capture Methods: We have implemented ScreenCaptureKit (SCK) as the primary engine and CGDisplayCreateImage as a fallback. Binary Status: All components are signed with a Developer ID and have been successfully Notarized. Observed Behavior & Blockers The "Aqua" Success: Within a logged-in user session, our CGI correctly identifies Display IDs and initializes the capture stream. Remote control is fully functional. The "Pre-Login" Failure: When the Mac is at the Login Window (no user logged in), the following occurs: The Daemon remains active, but the screen capture buffer returns NULL or an empty frame. ScreenCaptureKit fails to initialize, citing a lack of graphical context. No TCC (Transparency, Consent, and Control) prompt can appear because no user session exists. The "Bootstrap" Observation: We have identified that the loginwindow process exists in a restricted Mach bootstrap namespace that our Daemon (running in the System domain) cannot natively bridge. Comparative Analysis (Competitor Benchmarking) We have analyzed established remote desktop solutions like AnyDesk and Jump Desktop to understand their success at the login screen. Our findings suggest: Dual-Context Execution: They appear to use a Global LaunchAgent with LimitLoadToSessionType = ["LoginWindow"]. This allows a child process to run as root inside the login window’s graphical domain. Specialized Entitlements: These apps have migrated to the com.apple.developer.persistent-content-capture entitlement. This restricted capability allows them to bypass the weekly/monthly TCC re-authorization prompts and function in unattended scenarios where a user cannot click "Allow." Questions Entitlement Requirement: Is the persistent-content-capture entitlement the only supported way for a third-party app to capture the LoginWindow buffer without manual user intervention? LaunchAgent Strategy: To gain a graphical context at the login screen, is it recommended to load a specialized agent into the loginwindow domain via launchctl bootstrap loginwindow ...? ScreenCaptureKit vs. Legacy: Does ScreenCaptureKit officially support the LoginWindow session, or does it require an active Aqua session to initialize? MDM Bypass: For Enterprise environments, can a Privacy Preferences Policy Control (PPPC) payload grant "Screen Recording" to a non-entitled Daemon specifically for the login window context?

I’m a newly enrolled Apple Developer Program member and am trying to notarize my first macOS app using notarytool. My enrollment is fully completed: Payment completed Free Apps and Paid Apps Agreements are Active Banking and tax (W-8BEN) are Active DSA compliance (EU) is Active However, every notarization submission is immediately rejected with: statusCode: 7000 “Team is not yet configured for notarization.” The rejection happens before any analysis (ticketContents is null), which suggests an account-level provisioning issue rather than a signing or app problem. I’ve already opened a Developer Programs Support case under: Development & Technical → Other Development or Technical Questions, and provided recent Job IDs for escalation. For developers who have encountered this recently: Is this typically resolved by Apple enabling Developer ID notarization on the backend? Is there anything else required from the developer side once agreements are active? Any confirmation or shared experience would be appreciated.

I just looked at the "release notes" for macOS 26.3 beta, and it said there were no notes. Imagine if you were getting your car checked, and the bill had an extra $1000 tacked on, with a line item that said "---". As a developer, this is bizarre. As a shareholder, this is dismaying.

I have noticed race conditions on macOS when tearing down and re-configuring an NEPacketTunnelProvider. My goal is to handle switching out one VPN profile for another identical/near identical one (I'll add some context for this below). The flow that I have tested was to wait for the NEVPNStatusDidChange notification to report a NEVPNStatus.disconnected state, and then start the process of re-configuring the VPN with a new profile. In practice however, I have noticed that I must wait a couple of seconds between NEVPNStatus.disconnected state being reported and setting up a new tunnel. Otherwise, the system routing table gets messed up but the VPN reports being in NEVPNStatus.connected state, resulting in a tunnel that appears healthy but can't be accessed. With this, I wanted to ask if you have any suggestions on any OS items I can observer, in order to deterministically know that the system has fully cleaned up my packet tunnel, and that I am safe to configure another? This would be much more optimal than a hard-coded delay. Additional context: Jamf is a common solution for deploying MDM configuration profiles. However, in my tests, it doesn't support Apple's recommended approach of using the PayloadIdentifier to mark profiles for replacement, as PayloadIdentifiers are automatically updated to match the PayloadUUID of that same profile on upload. Although given what I've observed, I'm not sure the Apple recommended approach would work here in any case. Additionally, it would be nice to transition from non-MDM to MDM cleanly, however, this also requires an indeterminate wait time between the non-MDM configuration being disconnected and subsequently removed, and the MDM one being configured. With these scenarios, we need to be able to add a second configuration, with possibly identical VPN settings, then remove the old one, allowing the system to transition to the new configuration. For the MDM case, the pattern I've noticed on the system is that when the current profile is suddenly deleted, the connection will go into disconnected state, then NEVPNConfigurationChange will fire. The new profile can be configured from NEVPNConfigurationChange, however some time is needed to avoid races. For non-MDM, I had experimented with an approach of polling for MDM configurations appearing. When they do, I'd remove my previous notification observers, and set up a new NEVPNStatusDidChange notification observer, to remove the non-MDM VPN configuration after. it enters a disconnected state. Following the removal, I would call a function to reconfigure the VPN with new configuration. When this logic is in place, the call to stopVPNTunnel() is made. Again, a hardcoded delay is required between stopping and removing the old configuration and setting up a new one. Thanks!

We have an application which keeps throwing the error "application is damaged and cannot be opened. You should move it to Trash" I have already referred to the documentation: https://developer.apple.com/forums/thread/706379 and https://developer.apple.com/forums/thread/706442 I have checked the following possible root causes: Codesign of the application using the codesign command Notarization of the application using the spctl command Executable permissions Checked for the presence of "com.apple.quarantine" flag for the application using xattr -l <path to executables" Checked the bundle structure None of the above listed items seemed to be a problem and are as expected. Can you please help us understand what could cause this issue and how to resolve this without recommending an uninstall/reinstall of the application?

As the title states, I’ve been trying to emulate some older Direct9 games, and rosetta can’t handle it because of that https://github.com/WineAndAqua/rosettax87 I’ve had to use this, but it really seems like something that I shouldn’t have to do I’ve tried Wineskin, wine, D9VK, MoltenVK, GPTk, and the only thing that’s close to working is using devel wine + d9vk with the xrosetta87 running like its a VPN, and then you play Without xrosetta87 it’s 0-0.5 FPS? with it, it’s like a buttery smooth 60+

Summary On Mac Studio systems (no built-in camera), macOS does not initialize camera services after a normal reboot if no physical camera is present. As a result, Continuity Camera does not appear anywhere in the system. Observed behavior System Information → Camera reports “No video capture devices were found.” Continuity Camera (iPhone) is completely absent from camera lists. Plugging in any USB UVC webcam immediately initializes camera services and causes both the USB camera and the iPhone (Continuity Camera) to appear. The USB camera can then be unplugged and Continuity Camera continues working until the next reboot. Reproduction steps Use a Mac Studio (no built-in camera) on recent macOS. Ensure no USB webcam or external camera is connected. Reboot the Mac normally. After login, open System Information → Camera. Expected Camera services should initialize even when no physical camera is present, allowing Continuity Camera to be available as the primary camera. Actual No camera devices are present unless a physical USB camera is connected at least once after boot. This reproduces 100% of the time on Mac Studio and appears to be a camera service bootstrap issue where Continuity Camera cannot be the first camera device. Issue has been filed via Feedback Assistant.

In these threads, it was clarified that Credential Provider Extensions must set both Backup Eligible (BE) and Backup State (BS) flags to 1 in authenticator data: https://developer.apple.com/forums/thread/745605 https://developer.apple.com/forums/thread/787629 However, I'm developing a passkey manager that intentionally stores credentials only on the local device. My implementation uses: kSecAttrAccessibleWhenUnlockedThisDeviceOnly for keychain items kSecAttrTokenIDSecureEnclave for private keys No iCloud sync or backup These credentials are, by definition, single-device credentials. According to the WebAuthn specification, they should be represented with BE=0, BS=0. Currently, I'm forced to set BE=1, BS=1 to make the extension work, which misrepresents the actual backup status to relying parties. This is problematic because: Servers using BE/BS flags for security policies will incorrectly classify these as synced passkeys Users who specifically want device-bound credentials for higher security cannot get accurate flag representation Request: Please allow Credential Provider Extensions to return credentials with BE=0, BS=0 for legitimate device-bound passkey implementations. Environment: macOS 26.2 (25C56), Xcode 26.2 (17C52)

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.

When I appendAttributedString to [textView textStorage] it does not appear on the scrollable TextView. However when I NSLog the [textView textStorage] the Attributed string is outputted, and is therefore stored in the textView, see below. Occurs every time I ask to see the AttributedString I send to the textView. [textView textStorage] attributedString I need to see the attributedString displayed on the ScrollableTextView, but I don't know why I cannot see it.

I'm trying to embed a self-built copy of the WebKit frameworks to a macOS app. Most importantly I hope to get some features to work which Safari offers, but WKWebView in macOS doesn't (getDisplayMedia, Service Workers, WebInspector). Many years ago I was successful in using a self-built WebKit copy in this Mac app, but it seems the WebKit framework got more complex since them, I guess because of WKWebView's architecture. That time I had to open the projects for the main frameworks in Xcode, select the framework bundle in the target and change the "Installation Directory" setting to the path @executable_path/../Frameworks. After building WebKit using the build script, I could use otool -L to confirm the changed installation path, which then was displayed for example as @executable_path/../Frameworks/WebCore.framework/Versions/A/WebCore I tried the same with a current WebKit build: I copied the products for WebKit.framework, WebCore.framework, JavaScriptCore.framework, WebKitLegacy.framework, WebGPU.framework and WebInspectorUI.framework to my app and added it to the "Frameworks, Libraries and Embedded Content" section in the Project's Target/General tab and selected "Embed & Sign" for each framework. In "Build Phases" I made sure that WebCore.framework and WebGPU.framework are only in the "Copy Files" phase (Destination Frameworks) and not in "Link Binary with Libraries", as WebCore is linked through the WebKit umbrella framework and WebGPU gave another error (not sure about how to deal with that framework, as in the system it's in a PrivateFrameworks subfolder). In "Build Settings" I made sure that @executable_path/../Frameworks is entered for "Runpath Search Paths" (it was already probably because of Cocoapods, together with @loader_path/../Frameworks. When I build my app, the system's WebKit version is used. Only when I add the environment variable DYLD_FRAMEWORK_PATH with value @executable_path/../Frameworks in the run scheme, the embedded self-build WebKit frameworks are used. Because of currently necessary backward compatibility my app can use the legacy WebView or WKWebView. The legacy WebView works perfectly with the embedded WebKitLegacy.framework. But if I try to open any URL in WKWebView, no content is rendered and in the console output I can see: Safe Exam Browser[21391:145678] [Process] 0x10c67d760 - [PID=0] WebProcessProxy::didFinishLaunching: Invalid connection identifier (web process failed to launch) Safe Exam Browser[21391:145678] [Process] 0x10c67d760 - [PID=0] WebProcessProxy::processDidTerminateOrFailedToLaunch: reason=4 Safe Exam Browser[21391:145678] [ProcessSuspension] 0x10c005040 - [PID=0, throttler=0x10c67d8d8] ProcessThrottler::Activity::invalidate: Ending background activity / 'WebProcess initialization' Safe Exam Browser[21391:145678] [Process] 0x10c67d760 - [PID=0] WebProcessProxy::shutDown: Safe Exam Browser[21391:145678] [Process] 0x7fbe89064020 - [pageProxyID=40, webPageID=41, PID=0] WebPageProxy::processDidTerminate: (pid 0), reason 4 2022-02-14 12:53:01.764074+0100 Safe Exam Browser[21391:145678] [Process] 0x10c67d760 - [PID=0] WebProcessProxy::processTerminated: Safe Exam Browser[21391:145678] [Loading] 0x7fbe89064020 - [pageProxyID=40, webPageID=41, PID=0] WebPageProxy::dispatchProcessDidTerminate: reason=Crash Safe Exam Browser[21391:146842] [SEBOSXWKWebViewController webViewWebContentProcessDidTerminate:<Safe_Exam_Browser.SEBOSXWKWebView: 0x7fbe88f8b1c0>] I have the impression that the web process might fail to launch because I didn't embed all necessary parts of the self-built WebKit (the product folder contains a large number of XPC, dylib and .a files). Or some additional paths have to be adjusted before building WebKit, so that the embedded frameworks/libraries are used and not the system provided ones. I also looked at the bundle of the Safari Technology Preview and can see some similarities but also differences. I would be grateful if anybody could provide me with information how to embed a self-built copy of WebKit into a macOS app. Unfortunately I didn't find any Mac open source browser using an embedded copy of WebKit to get some inspiration from.

I remember this integration being demoed at WWDC25. Ability to trigger app intent for iOS application from Spotlight search on MacOS. How Do I extend my iOS Application to be able to do this? Where is the documentation for implementing this mechanism? Thank you in advance for your help. I believe this integration is a powerful productivity unlock!

[Submitted as FB20950954] Xcode Simulator causes crackling and distortion in audio playback across all apps (Apple Podcasts, Music, third-party). REPRO STEPS Open any audio app and start playback Note the audio quality Launch Xcode Simulator After a few seconds, note audio quality again Quit Xcode Simulator Audio returns to normal CURRENT Audio has crackling and distortion while Simulator is running. EXPECTED Clean audio playback regardless of whether Simulator is running. SYSTEM INFO macOS 26.1 (25B78) Xcode 26.1 (17B55) Simulator 26.0 (1058)

Background / Objective We are currently developing a solution to centrally manage Apple OS updates (major and minor) across managed macOS devices. Before implementing at scale, we need Apple’s guidance on supported and future-proof update mechanisms under MDM. Questions / Ask (Apple Guidance Requested) Apple recommended method What is Apple’s recommended approach to perform: Minor updates (e.g., macOS X.Y → X.Z) Major upgrades (e.g., Ventura → Sonoma) in an enterprise fleet? Support boundary Is macOS update management only supported via MDM (including any newer declarative workflows), or are local mechanisms (installer + command-line tooling) also considered supported for enterprise automation? Use of startosinstall Can we leverage the existing utility: /Applications/Install macOS .app/Contents/Resources/startosinstall for automated upgrades in enterprise environments? If yes, are there recommended flags/workflows Apple endorses for unattended or minimally interactive upgrades? Long-term support / stability Does startosinstall have any form of long-term support / stability guarantees across future macOS releases? Are there any known deprecations planned (or guidance that customers should transition to MDM/DDM workflows)? MDM interaction / interference When using startosinstall, can MDM policies (software update deferrals/restrictions, update enforcement, etc.) interfere with or block the upgrade? If interference is expected, what is the correct supported way to coordinate: MDM software update settings local startosinstall execution to avoid failures and ensure compliance? What We Need From Apple (Desired Outcome) A clear statement of recommended and supported update workflow(s) for enterprise managed macOS: for minor updates for major upgrades Guidance on whether startosinstall is acceptable for long-term automation, or whether we should only use MDM/DDM-driven workflows. Any best practices or reference documentation Apple recommends for implementing this safely and reliably.

We are upgrading macOS (minor versions and potentially major versions) using a scripted approach: Install the InstallAssistant package via installer Trigger OS install via startosinstall On MDM-managed assets, OS update policies appear to prohibit or interfere with the update flow. The update often fails with startosinstall reporting “Helper tool crashed…” during the “Preparing” phase. Steps to Reproduce On an MDM-enrolled Mac with OS update restriction/deferral policies applied, run: sudo /usr/sbin/installer -pkg /Path/To/InstallAssistant.pkg -target / && echo 'MACOS_PASSWORD' | /Applications/Install\ macOS\ Sonoma.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --stdinpass --user MACOS_USER Actual Result Package installation reports success, but startosinstall fails during preparation with: Standard Output installer: Package name is macOS15.7_SoftwareUpdate installer: Upgrading at base path / installer: The upgrade was successful. By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms. If you do not agree, press CTRL-C and cancel this process immediately. Preparing to run macOS Installer... Preparing: 0.0% Preparing: 0.1% ... Preparing: 24.9% Standard Error Helper tool crashed... notes.log Install.log is also attached. Questions for Apple / Ask: We suspect this crash is caused by MDM OS update restrictions/policies. We need Apple’s recommended method to perform macOS updates (minor + major) when MDM is present, especially in environments where update deferrals/restrictions may be configured.

Environment macOS Tahoe 26.2 (Build 25C56) Also tested with macOS 26.3 Developer Beta - same issue Windows Server 2022 DFS namespace Connection via Tailscale VPN (but also tested with direct network connection) Problem Description When connecting to a Windows Server 2022 DFS namespace from macOS Tahoe, the root namespace connects successfully, but all subfolders appear empty and return either: "No route to host" "Authentication error" (alternates inconsistently) Steps to Reproduce Set up a Windows Server 2022 DFS namespace (e.g., \\domain.com\fs) Add DFS folder targets pointing to file servers (e.g., \\fs02\share, \\fs03\share) From macOS Tahoe, connect via Finder: smb://domain.com/fs Root namespace mounts successfully Issue: Subfolders show as empty or return "No route to host" when accessed What Works Direct SMB connections to individual file servers work perfectly: smb://10.118.0.26/sharename ✓ smb://fs02.domain.com/sharename ✓ Same DFS namespace works from Windows clients Same DFS namespace worked from macOS Sonoma 14.4+ What Doesn't Work DFS referrals from macOS Tahoe 26.x to any DFS folder target The issue persists regardless of: Kerberos vs NTLM authentication SMB signing enabled/disabled on servers Various /etc/nsmb.conf configurations DNS resolution (tested with IPs and FQDNs) Historical Context A similar DFS referral bug existed in macOS Sonoma 14.0 and was fixed in 14.1. This appears to be a regression in macOS Tahoe 26. Request Please investigate the DFS referral handling in macOS Tahoe. The fact that direct SMB connections work while DFS referrals fail suggests an issue specifically in the DFS referral processing code. Feedback Assistant report will be filed separately.

I’m having an issue installing my TestFlight build on a Mac. The build (v1.0 build 1) uploads successfully and shows as “Complete” in App Store Connect. I can also open the build details page, and my Apple ID / tester access / group setup looks correct. However, on TestFlight (macOS), when I tap Install/Load, I get this error: Unable to install. The requested app isn’t available or can’t be found. Notes: The app is an iOS app (iPhone + iPad), and I enabled availability for Mac (Designed for iPad) in App Store Connect. The Mac is Apple Silicon, running macOS Tahoe 26.1. Could you help me understand why TestFlight shows this message on Mac, and what I should change in Xcode/App Store Connect to make the build compatible?

I'm working on a command line tool, and trying to make it as fast as possible. I ran it under instruments' processor trace (really cool tool by the way, thanks for that) and found that the majority of the time it is taking to run, is actually spent in dyld, specifically dyld4::prepare(dyld4::APIs&, mach_o::Header const*). Out of a total run time of 1.27ms my code only takes 34.17μs or about 2.7%, that's a LOT of overhead! I re-ran my binary with the dyld activity instrument added to the mix, and it showed that the biggest known chunk of time that dyld spends during process startup is in "Run static initializer" from libSystem, though the majority of the time spent by dyld is unaccounted for and left labelled generically as "Launch Executable". Obviously I can't modify libSystem on my users' systems so is there anything I can do to reduce this overhead? Maybe some way to promise that I won't use the Obj-C runtime so that doesn't need setting-up or something?