Hello, I am currently working on a project that involves periodically querying OSLog to forward system log entries to a backend. While the functionality generally operates as expected, I have encountered a memory leak in my application. Through testing, I have isolated the issue to the following simplified code example: #import <Foundation/Foundation.h> #import <OSLog/OSLog.h> int main(int argc, const char * argv[]) { @autoreleasepool { while(1) { NSError *error = nil; OSLogStore *logStore = [OSLogStore storeWithScope:OSLogStoreSystem error:&error]; if (!logStore) NSLog(@"Failed to create log store: %@", error); sleep(1); } } return 0; } When running this example, the application exhibits increasing memory usage, consuming an additional 100 to 200 KB per iteration, depending on whether the build is Debug or Release. Given that Automatic Reference Counting is enabled, I anticipated that the resources utilized by logStore would be automatically released at the end of each iteration. However, this does not appear to be the case. Am I using the API wrong? I would appreciate any insights or suggestions on how to resolve this issue. Thank you.

Hi, It seems that on M4 devices any virtual machine with macOS version older than 13.4 fail to boot, they stuck with a black screen. This is regardless of the virtualization software used (UTM, VirtualBuddy, Viable, etc...). After talking to many people everyone experiences the same. At least for me, this is a massive limitation of the platform, I really hope this is a bug which can be fixed. Thanks, Csaba

Hi I have some problems with my macOS after updating to Sonoma. I am running a intel based MacBookPro 2018. After update to Sonoma I had some Kernel panic. Log attached. Also I had some problems running my LaunchDaemon for starting macFUSE and connecting to SSHFS. This used to work before. Now, my plan forward is to restore a backup from the MacBook before update. I will restore the backup and remove any redundant/not in use .plist jobs ( especially ) LaunchDaemon jobs. When this is done I will try to update macOS again. I have many .plist jobs also Daemon. Please supply information on how I can remove any redundant / not in use .plist jobs. I belive the reason for the kernel panic was the io.macfuse.filesystems.macfuse.23 4.7.2. ( attached log ) I want to keep the io.macfuse.filesystems.macfuse.23 4.7.2 , but I want to remove other kexts not in use and other .plist not in use. Please supply info in how to identify redundant kexts not in use and redundant .plist not in use. How do I know if the induvidual kexts is needed or not ? Best regards Tormod Willassen Kernel_Panic.rtf log-file log-file

Dear Apple engineers, Is it possible to make a fileprovider cloud volume mount path independent of the user's home folder in order to have constant path across desktop clients when files are referenced / placed by applications like Adobe Creative Cloud ? Ideally mount or link the fileprovider cloud volume under /Volumes Thanks,

I create a DispatchIO object (in Swift) from a socketpair, set the low/high water marks to 1, and then call read on it. Elsewhere (multi-threaded, of course), I get data from somewhere, and write to the other side of it. Then when my data is done, I call dio?.close() The cleanup handler never gets called. What am I missing? (ETA: Ok, I can get it to work by calling dio?.close(flags: .stop) so that may be what I was missing.) (Also, I really wish it would get all the data available at once for the read, rather than 1 at a time.)

Hello, there are popular USB GPS receivers from GlobalSat called BU-353N5. It's shipped with driver application and works well. Once connected GPS receiver is visible as a /dev/tty.PL2303G-USBtoUART120 and produces NMEA codes there. I'm a developer of an offline maps application which is available for iOS and macOS using Mac Catalyst. Is it possible to connect to the /dev/tty* from mac catalyst app? Is there an entitlement for that? There are also driver sources available to work directly with USB device based on Prolific 2303, but before I'll try to integrate driver into the app I wan't to be sure there is no way to use an existing one.

Hello Apple Developer Community, I'm developing a call-blocking app for iOS and have encountered an issue with iOS 18. Despite calls being successfully blocked by our app's Call Directory extension, they are still appearing as unanswered calls in the native Phone app. Details: iOS version: 18 App uses CallKit and Call Directory extension Calls are blocked successfully (not ringing on device) Blocked calls show up as "Unanswered" in Phone app's recent calls list Expected behavior: Blocked calls should not appear in the Phone app's recent calls list. Actual behavior: Blocked calls appear as "Unanswered" in the recent calls list.

I would like to replace the deprecated method FSMountServerVolumeSync with the newer one NetFSMountURLSync. I can properly mount my FTP volume using "Connect to Server" in the Finder and with FSMountServerVolumeSync (the volume comes as read only, but it's ok). When I try to mount the FTP volume with NetFSMountURLSync I get this error message: "The share does not exist on the server. Please check the share name and then try again". But as I know I can't define the share on a FTP server. How can I fix this issue?

Hello. I found that my iPhone has encountered same error continuously when I tried to commission my Eve Door & Window device. Nov 12 11:33:48 iPhone homed(Matter)[181] <Error>: Can't extract public key from certificate: src/crypto/CHIPCryptoPALOpenSSL.cpp:1911: CHIP Error 0x0000002F: Invalid argument Nov 12 11:33:48 iPhone homed(Matter)[181] <Error>: convertX509Certificate: src/credentials/CHIPCertFromX509.cpp:559: CHIP Error 0x0000002F: Invalid argument Nov 12 11:33:55 iPhone homed(HomeKitMatter)[181] <Error>: [4264877660/1(3180582119)] Couldn't get device being commissioned for network scanning: (null) Nov 12 11:33:55 iPhone homed(HomeKitDaemon)[181] <Error>: No unpaired accessory for server HMMTRAccessoryServer fa:e6:88:97:2a:ee Nov 12 11:33:55 iPhone homed(HomeKitMetrics)[181] <Error>: [4264877660/1(3180582119)] tag="hmmtrAccessoryServerStateChange" desc="Error in progress state" errorDomain="MTRErrorDomain" errorCode="1" state="19" Nov 12 11:33:55 iPhone homed(HomeKitMatter)[181] <Error>: [4264877660/1(3180582119)] CHIP Accessory pairing failed: Error Domain=MTRErrorDomain Code=1, <HMMTRAccessoryPairingEndContext, Step: HMMTRAccessoryPairingStep_GettingNetworkRequirement, Error: Error Domain=MTRErrorDomain Code=1 "The operation couldn\M-b\M^@\M^Yt be completed. (MTRErrorDomain error 1.)", Sourceerrordomain: MTRErrorDomain> Is there anyone who has experienced or solved the same error as me? Thanks.

Before updating to macOS 15 Sequoia, I used to be able to create file bookmarks with this code: let openPanel = NSOpenPanel() openPanel.runModal() let url = openPanel.urls[0] do { let _ = try url.bookmarkData(options: [.withSecurityScope]) } catch { print(error) } Now I get an error Error Domain=NSCocoaErrorDomain Code=256 "Failed to retrieve app-scope key" These are the entitlements: com.apple.security.app-sandbox com.apple.security.files.user-selected.read-write com.apple.security.files.bookmarks.app-scope Strangely, my own apps continued working, after updating to macOS 15 some days ago, until a few moments ago. Then it seems that all of a sudden my existing bookmarks couldn't be resolved anymore, and no new bookmarks could be created. What could be the problem?

We are building an iOS app that connects to a device using Bluetooth. To test unhappy flow scenarios for this app, we'd like to power cycle the device we are connecting to by using an IoT power switch that connects to the local network using WiFi (a Shelly Plug-S). In my test code on iOS13, I was able to do a local HTTP call to the IP address of the power switch and trigger a power cycle using its REST interface. In iOS 14 this is no longer possible, probably due to new restrictions regarding local network usage without permissions (see: https://developer.apple.com/videos/play/wwdc2020/10110 ). When running the test and trying a local network call to the power switch in iOS14, I get the following error: Task <D206B326-1820-43CA-A54C-5B470B4F1A79>.<2> finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "The internet connection appears to be offline." UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x2833f34b0 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <D206B326-1820-43CA-A54C-5B470B4F1A79>.<2>, _NSURLErrorRelatedURLSessionTaskErrorKey=("LocalDataTask <D206B326-1820-43CA-A54C-5B470B4F1A79>.<2>"), NSLocalizedDescription=The internet connection appears to be offline., NSErrorFailingURLStringKey=http://192.168.22.57/relay/0?turn=on, NSErrorFailingURLKey=http://192.168.22.57/relay/0?turn=on, _kCFStreamErrorDomainKey=1} An external network call (to google.com) works just fine in the test. I have tried fixing this by adding the following entries to the Info.plist of my UI test target: <key>NSLocalNetworkUsageDescription</key> <string>Local network access is needed for tests</string> <key>NSBonjourServices</key> <array> <string>_http._tcp</string> </array> <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> </dict> However, this has no effect. I have also tried adding these entries to the Info.plist of my app target to see if that makes a difference, but it doesn't. I'd also rather not add these entries to my app's Info.plist, because the app does not need local network access. Only the test does. Does anyone know how to enable local network access during an iOS UI test in iOS14?

Hello, Since 2017 I provide a free and open source Remote Desktop for macOS, Windows and Linux that supports macOS 10.7 to macOS 15. Screen capture is done with CGDisplayCreateImage and works fine. But there is a problem on macOS 15 Sequoia I can not capture the screen in the pre-login context (I am referring to the login screen before the user access into his account). The screen capture in pre-login context works fine for all macOS versions except macOS 15 Sequoia. In last weeks I tried to fix the issue without success: tried CGDisplayStream tried AVCaptureScreenInput tried ScreenCaptureKit tried to sign the App (and executable) None of these work before the user login, but them works only when the user is logged in. Additional info: I run the App with "launch agent" when user is connected. I run the App with "launch daemon" when user is not connected. Any help would be greatly appreciated!

Modern versions of macOS use a file system permission model that’s far more complex than the traditional BSD rwx model, and this post is my attempt at explaining that model. If you have a question about this, post it here on DevForums. Put your thread in the App & System Services > Core OS topic area and tag it with Files and Storage. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" On File System Permissions Modern versions of macOS have four different file system permission mechanisms: Traditional BSD permissions Access control lists (ACLs) App Sandbox Mandatory access control (MAC) The first two were introduced a long time ago and rarely trip folks up. The second two are newer, more complex, and specific to macOS, and thus are the source of some confusion. This post is my attempt to clear that up. Error Codes App Sandbox and the mandatory access control system are both implemented using macOS’s sandboxing infrastructure. When a file system operation fails, check the error to see whether it was blocked by this sandboxing infrastructure. If an operation was blocked by BSD permissions or ACLs, it fails with EACCES (Permission denied, 13). If it was blocked by something else, it’ll fail with EPERM (Operation not permitted, 1). If you’re using Foundation’s FileManager, these error are both reported as Foundation errors, for example, the NSFileReadNoPermissionError error. To recover the underlying error, get the NSUnderlyingErrorKey property from the info dictionary. App Sandbox File system access within the App Sandbox is controlled by two factors. The first is the entitlements on the main executable. There are three relevant groups of entitlements: The com.apple.security.app-sandbox entitlement enables the App Sandbox. This denies access to all file system locations except those on a built-in allowlist (things like /System) or within the app’s containers. The various “standard location” entitlements extend the sandbox to include their corresponding locations. The various “file access temporary exceptions” entitlements extend the sandbox to include the items listed in the entitlement. Collectively this is known as your static sandbox. The second factor is dynamic sandbox extensions. The system issues these extensions to your sandbox based on user behaviour. For example, if the user selects a file in the open panel, the system issues a sandbox extension to your process so that it can access that file. The type of extension is determined by the main executable’s entitlements: com.apple.security.files.user-selected.read-only results in an extension that grants read-only access. com.apple.security.files.user-selected.read-write results in an extension that grants read/write access. Note There’s currently no way to get a dynamic sandbox extension that grants executable access. For all the gory details, see this post. These dynamic sandbox extensions are tied to your process; they go away when your process terminates. To maintain persistent access to an item, use a security-scoped bookmark. See Accessing files from the macOS App Sandbox. To pass access between processes, use an implicit security scoped bookmark, that is, a bookmark that was created without an explicit security scope (no .withSecurityScope flag) and without disabling the implicit security scope (no .withoutImplicitSecurityScope flag)). If you have access to a directory — regardless of whether that’s via an entitlement or a dynamic sandbox extension — then, in general, you have access to all items in the hierarchy rooted at that directory. This does not overrule the MAC protection discussed below. For example, if the user grants you access to ~/Library, that does not give you access to ~/Library/Mail because the latter is protected by MAC. Finally, the discussion above is focused on a new sandbox, the thing you get when you launch a sandboxed app from the Finder. If a sandboxed process starts a child process, that child process inherits its sandbox from its parent. For information on what happens in that case, see the Note box in Enabling App Sandbox Inheritance. IMPORTANT The child process inherits its parent process’s sandbox regardless of whether it has the com.apple.security.inherit entitlement. That entitlement exists primarily to act as a marker for App Review. App Review requires that all main executables have the com.apple.security.app-sandbox entitlement, and that entitlements starts a new sandbox by default. Thus, any helper tool inside your app needs the com.apple.security.inherit entitlement to trigger inheritance. However, if you’re not shipping on the Mac App Store you can leave off both of these entitlement and the helper process will inherit its parent’s sandbox just fine. The same applies if you run a built-in executable, like /bin/sh, as a child process. When the App Sandbox blocks something, it typically generates a sandbox violation report. For information on how to view these reports, see Discovering and diagnosing App Sandbox violations. To learn more about the App Sandbox, see the various links in App Sandbox Resources. For information about how to embed a helper tool in a sandboxed app, see Embedding a Command-Line Tool in a Sandboxed App. Mandatory Access Control Mandatory access control (MAC) has been a feature of macOS for many releases, but it’s become a lot more prominent since macOS 10.14. There are many flavours of MAC but the ones you’re most likely to encounter are: Full Disk Access (macOS 10.14 and later) Files and Folders (macOS 10.15 and later) App container protection (macOS 14 and later) App group container protection (macOS 15 and later) Data Vaults (see below) and other internal techniques used by various macOS subsystems Mandatory access control, as the name suggests, is mandatory; it’s not an opt-in like the App Sandbox. Rather, all processes on the system, including those running as root, as subject to MAC. Data Vaults are not a third-party developer opportunity. See this post if you’re curious. In the Full Disk Access and Files and Folders cases, users grant a program a MAC privilege using System Settings > Privacy & Security. Some MAC privileges are per user (Files and Folders) and some are system wide (Full Disk Access). If you’re not sure, run this simple test: On a Mac with two users, log in as user A and enable the MAC privilege for a program. Now log in as user B. Does the program have the privilege? If a process tries to access an item restricted by MAC, the system may prompt the user to grant it access there and then. For example, if an app tries to access the desktop, you’ll see an alert like this: “AAA” would like to access files in your Desktop folder. [Don’t Allow] [OK] To customise this message, set Files and Folders properties in your Info.plist. This system only displays this alert once. It remembers the user’s initial choice and returns the same result thereafter. This relies on your code having a stable code signing identity. If your code is unsigned, or signed ad hoc (“Signed to Run Locally” in Xcode parlance), the system can’t tell that version N+1 of your code is the same as version N, and thus you’ll encounter excessive prompts. Note For information about how that works, see TN3127 Inside Code Signing: Requirements. The Files and Folders prompts only show up if the process is running in a GUI login session. If not, the operation is allowed or denied based on existing information. If there’s no existing information, the operation is denied by default. For more information about app and app group container protection, see the links in Trusted Execution Resources. For more information about app groups in general, see App Groups: macOS vs iOS: Fight! On managed systems the site admin can use the com.apple.TCC.configuration-profile-policy payload to assign MAC privileges. For testing purposes you can reset parts of TCC using the tccutil command-line tool. For general information about that tool, see its man page. For a list of TCC service names, see the posts on this thread. Note TCC stands for transparency, consent, and control. It’s the subsystem within macOS that manages most of the privileges visible in System Settings > Privacy & Security. TCC has no API surface, but you see its name in various places, including the above-mentioned configuration profile payload and command-line tool, and the name of its accompanying daemon, tccd. While tccutil is an easy way to do basic TCC testing, the most reliable way to test TCC is in a VM, restoring to a fresh snapshot between each test. If you want to try this out, crib ideas from Testing a Notarised Product. The MAC privilege mechanism is heavily dependent on the concept of responsible code. For example, if an app contains a helper tool and the helper tool triggers a MAC prompt, we want: The app’s name and usage description to appear in the alert. The user’s decision to be recorded for the whole app, not that specific helper tool. That decision to show up in System Settings under the app’s name. For this to work the system must be able to tell that the app is the responsible code for the helper tool. The system has various heuristics to determine this and it works reasonably well in most cases. However, it’s possible to break this link. I haven’t fully research this but my experience is that this most often breaks when the child process does something ‘odd’ to break the link, such as trying to daemonise itself. If you’re building a launchd daemon or agent and you find that it’s not correctly attributed to your app, add the AssociatedBundleIdentifiers property to your launchd property list. See the launchd.plist man page for the details. Scripting MAC presents some serious challenges for scripting because scripts are run by interpreters and the system can’t distinguish file system operations done by the interpreter from those done by the script. For example, if you have a script that needs to manipulate files on your desktop, you wouldn’t want to give the interpreter that privilege because then any script could do that. The easiest solution to this problem is to package your script as a standalone program that MAC can use for its tracking. This may be easy or hard depending on the specific scripting environment. For example, AppleScript makes it easy to export a script as a signed app, but that’s not true for shell scripts. TCC and Main Executables TCC expects its bundled clients — apps, app extensions, and so on — to use a native main executable. That is, it expects the CFBundleExecutable property to be the name of a Mach-O executable. If your product uses a script as its main executable, you’re likely to encounter TCC problems. To resolve these, switch to using a Mach-O executable. For an example of how you might do that, see this post. Revision History 2024-11-08 Added info about app group container protection. Clarified that Data Vaults are just one example of the techniques used internally by macOS. Made other editorial changes. 2023-06-13 Replaced two obsolete links with links to shiny new official documentation: Accessing files from the macOS App Sandbox and Discovering and diagnosing App Sandbox violations. Added a short discussion of app container protection and a link to WWDC 2023 Session 10053 What’s new in privacy. 2023-04-07 Added a link to my post about executable permissions. Fixed a broken link. 2023-02-10 In TCC and Main Executables, added a link to my native trampoline code. Introduced the concept of an implicit security scoped bookmark. Introduced AssociatedBundleIdentifiers. Made other minor editorial changes. 2022-04-26 Added an explanation of the TCC initialism. Added a link to Viewing Sandbox Violation Reports.  Added the TCC and Main Executables section. Made significant editorial changes. 2022-01-10 Added a discussion of the file system hierarchy. 2021-04-26 First posted.

Under iPhone iOS18.1 and Xcode 16.1, use Matter and MatterSupport to pair Matter devices. It was found that Matter over WIFI devices could not trigger the PASE process try deviceController?.setupCommissioningSession(with: payload, newNodeID: commissioningDeviceID) After some time: func controller(_: MTRDeviceController, statusUpdate status: MTRCommissioningStatus) Return failure

Hello, I'm using an HMSoft Bluetooth module that connects reliably to Android devices, maintaining a stable connection. However, when I try to connect it to my iPhone 12, the connection randomly disconnects after a few minutes (usually around 3 minutes). This issue occurs even when using apps like LightBlue and other BLE-based medical equipment apps, so it doesn't seem related to my app code. Any suggestions on what I can do to prevent these unexpected disconnects? Should I change any specific settings on my iPhone or the module itself?

The VM gets a NAT IP just fine, but it doesn't have access through the proxy so I'm guessing 15.x macOS setup has a bug where it can't break out of a loop trying to phone home back to macOS. FBID: FB15689777 This is not an issue for 14.x VMs. It's also seen across different Virtualization tools.

Under iOS18.1 and Xcode 16.1, use Matter and MatterSupport to pair Matter devices. It was found that Matter over WIFI devices could not trigger the PASE process let device = try deviceController? .deviceBeingCommissioned(withNodeID: commissioningDeviceID) After some time: func controller(_: MTRDeviceController, statusUpdate status: MTRCommissioningStatus) Return failure Device logs: E (47956) chip[ZCL]: Commissioning window is currently not open I (48789) chip[EM]: <<< [E:17954r S:13425 M:26847390 (Ack:206367876)] (S) Msg TX to 1:00000000EE53575F [AE90] [UDP:[FE80::148F:AC68:D736:CA5C%st1]:58332] --- Type 0001:09 (IM:InvokeCommandResponse) E (48798) chip[DL]: Long dispatch time: 867 ms, for event type 3 I (48804) chip[EM]: >>> [E:17954r S:13425 M:206367876 (Ack:26847387)] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0001:08 (IM:InvokeCommandRequest) I (48819) chip[EM]: <<< [E:17954r S:13425 M:26847391 (Ack:206367876)] (S) Msg TX to 1:00000000EE53575F [AE90] [UDP:[FE80::148F:AC68:D736:CA5C%st1]:58332] --- Type 0000:10 (SecureChannel:StandaloneAck) I (48838) chip[EM]: >>> [E:17954r S:13425 M:206367876 (Ack:26847387)] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0001:08 (IM:InvokeCommandRequest) I (48851) chip[EM]: <<< [E:17954r S:13425 M:26847392 (Ack:206367876)] (S) Msg TX to 1:00000000EE53575F [AE90] [UDP:[FE80::148F:AC68:D736:CA5C%st1]:58332] --- Type 0000:10 (SecureChannel:StandaloneAck) I (48935) chip[EM]: >>> [E:17954r S:13425 M:206367877 (Ack:26847390)] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0000:10 (SecureChannel:StandaloneAck) I (48952) chip[EM]: >>> [E:17955r S:13425 M:206367878] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0001:0a (IM:TimedRequest) I (48957) chip[EM]: <<< [E:17955r S:13425 M:26847393 (Ack:206367878)] (S) Msg TX to 1:00000000EE53575F [AE90] [UDP:[FE80::148F:AC68:D736:CA5C%st1]:58332] --- Type 0001:01 (IM:StatusResponse) I (48998) chip[EM]: >>> [E:17955r S:13425 M:206367879 (Ack:26847393)] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0001:08 (IM:InvokeCommandRequest) I (49019) esp_matter_command: Received command 0x00000000 for endpoint 0x0000's cluster 0x0000003C I (49019) chip[ZCL]: Received command to open commissioning window I (49025) chip[DIS]: Updating services using commissioning mode 2 I (49087) chip[DIS]: CHIP minimal mDNS started advertising. I (49093) chip[DIS]: Advertise operational node 752B90252951AE90-000000005B4AA994 I (49094) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 752B90252951AE90-000000005B4AA994. I (49105) chip[DIS]: mDNS service published: _matter._tcp I (49109) chip[DIS]: Advertise commission parameter vendorID=5493 productID=8228 discriminator=0741/02 cm=2 I (49120) chip[DIS]: CHIP minimal mDNS configured as 'Commissionable node device'; instance name: 1D59D05DF5376A3B. I (49137) chip[DIS]: mDNS service published: _matterc._udp I (49137) chip[ZCL]: Commissioning window is now open I (49143) chip[EM]: <<< [E:17955r S:13425 M:26847394 (Ack:206367879)] (S) Msg TX to 1:00000000EE53575F [AE90] [UDP:[FE80::148F:AC68:D736:CA5C%st1]:58332] --- Type 0001:09 (IM:InvokeCommandResponse) I (49161) app_main: Commissioning window opened I (49200) chip[EM]: >>> [E:17955r S:13425 M:206367880 (Ack:26847394)] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0000:10 (SecureChannel:StandaloneAck) I (69380) SENSOR: Temp: 236 I (69383) ACInterface: AC event ntc :236

Our app experience the strange crash,causing the app to not launch.This crash suddenly began to happen on October 25. At present, all the Hardware Model of mobile phones that occurred were on iPhone17,1 and the iOS system version was iOS18.0.1. This crash was all from users on the appstore, and was collected via Xcode - Organizer - &gt; Crashes. I've attached the crash report.Thanks Distributor ID: com.apple.AppStore Hardware Model: iPhone17,1 Process: XxxxxxXXX [31230] Path: /private/var/containers/Bundle/Application/6E9E07EA-B7A4-4D57-B419-743DDCF7C3A6/XxxxxxXXX.app/XxxxxxXXX Identifier: com.XxxxxxXXX.XxxxxxXXX Version: 8.1.10 (811001) AppStoreTools: 16A242d AppVariant: 1:iPhone17,1:18 Code Type: ARM-64 (Native) Role: unknown Parent Process: launchd [1] Coalition: com.XxxxxxXXX.XxxxxxXXX [8069] Date/Time: 2024-10-31 03:30:38.7437 +0800 Launch Time: 2024-10-31 03:30:38.7415 +0800 OS Version: iPhone OS 18.0.1 (22A3370) Release Type: User Baseband Version: 1.00.00 Report Version: 104 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: GUARD 5 Triggered by Thread: 0 Thread 0 Crashed: 0 dyld 0x00000001b2da32b0 lsl::PreallocatedAllocatorLayout&lt;278528ull&gt;::init(char const**, char const**, void*) + 436 (Allocator.h:537) 1 dyld 0x00000001b2d9ca38 start + 1960 (dyldMain.cpp:1289) Thread 0 crashed with ARM Thread State (64-bit): x0: 0x2010003030100000 x1: 0x0000000fffffc0d0 x2: 0x0000000000000002 x3: 0x00000001b2d717ab x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x2010003030100000 x9: 0x2010003030100000 x10: 0x000000016d1dbdfb x11: 0x00000001b2dddf30 x12: 0x0000000000000050 x13: 0x0000000000000044 x14: 0x0000000000052010 x15: 0x0000000000000000 x16: 0x0000000000000000 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000018a7e0000 x20: 0x000000016d1dbb30 x21: 0x000000016d1dbad0 x22: 0x00000001f0794050 x23: 0x000000016d1db7b8 x24: 0x0000000fffffc10c x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000000000000 fp: 0x000000016d1db850 lr: 0x00380001b2da3130 sp: 0x000000016d1db7b0 pc: 0x00000001b2da32b0 cpsr: 0x60000000 esr: 0x92000047 (Data Abort) byte write Translation fault Binary Images: 0x102c24000 - 0x1056d3fff main_executable_path_missing arm64 &lt;086a82c13b863f4485895baddc3144ba&gt; /main_executable_path_missing 0x1b2d69000 - 0x1b2dec693 dyld arm64e &lt;5db839882ee63756bd07b8d67b1133a5&gt; /usr/lib/dyld EOF 2024-10-26_17-41-58.4222_+0800-841f6bdf4b2d436606ce55595ffc94d64e9af744.crash 2024-10-26_19-44-40.1115_+0800-7d4d654c76a10108b431acc612d6063b1edb1c3e.crash 2024-10-27_17-12-02.4926_+0800-6a4b6ec4cff928cf746162b9371a3176c3667c21.crash 2024-10-28_21-42-02.6780_+0800-c66c71c13414e7ff14ba783c883730c1361523b5.crash 2024-10-29_05-47-00.3943_+0800-ac7c1f5b6caf9aa97d71744a8f980c32d47eab80.crash 2024-10-31_03-30-38.7437_+0800-e1c54dc8879f97932cbb1520a04210bea6d7aaf4.crash 2024-11-03_07-57-18.8892_+0800-c7704569afc79ce50ac10b66e185de87425b1969.crash 2024-11-03_08-27-19.0514_+0800-c069e2f8dfa6767b8e301513aff3c3a7ea331e2c.crash

https://feedbackassistant.apple.com/feedback/15645457 Metal passthrough on intel VMs causes com.apple.screensharing.menuextra to crash and screensharing to exit Create a 15.1 VM with metal passthrough on 15.0.1 or 15.1 host, enable Screen Sharing, then try connecting to with VNC after restarting the machine. I'm using Anka to create the VM. You'll see VNC work (open vnc://192.168.64.3:5900), then a few seconds in show "Reconnecting...", then work, then go to "Reconnecting..." for ~5m until it eventually works consistently. You'll see launchd showing exits/failures (see screenshots) You'll see diagnostic reports showing things like: Thread 0 Crashed:: Dispatch queue: com.apple.RenderBox.Encoder 0 libsystem_kernel.dylib 0x7ff801da5b52 __pthread_kill + 10 1 libsystem_pthread.dylib 0x7ff801ddff85 pthread_kill + 262 2 libsystem_c.dylib 0x7ff801d00b19 abort + 126 3 libsystem_c.dylib 0x7ff801cffddc __assert_rtn + 314 4 Metal 0x7ff80d045d72 MTLReportFailure.cold.1 + 41 5 Metal 0x7ff80d01fa2a MTLReportFailure + 513 6 Metal 0x7ff80cfb74e0 +[MTLLoader sliceIDForDevice:legacyDriverVersion:airntDriverVersion:] + 200 7 Metal 0x7ff80cf265c9 +[_MTLBinaryArchive(MTLBinaryArchiveInternal) deserializeBinaryArchiveHeader:fileData:device:] + 89 8 Metal 0x7ff80cf10f0c -[_MTLBinaryArchive loadFromURL:error:] + 537 9 Metal 0x7ff80cf10288 -[_MTLBinaryArchive initWithOptions:device:url:error:] + 844 10 RenderBox 0x7ff9041a15fd RB::(anonymous namespace)::load_library_archive(NSBundle*,

We're creating macOS VMs on both 15.x and 14.x hosts and only the 14.x created VMs can run on both 15 and 14 hosts. If we create the VMs on 15.x, something is done by Virtualization that prevents it from running on 14.x. We've tried digging in and don't see anything that our code is doing that's special. What is Apple doing to the VMs created on 15.x hosts that's special here?