I am developing a large iOS application with an extensive UI test suite (hundreds of UI test scenarios). After upgrading our CI runners to macOS Tahoe 26, we started observing an intermittent issue where an iOS Simulator may operate normally for many successful application launches before unexpectedly entering a persistent degraded state. Once this occurs, every subsequent application launch crashes inside dyld before reaching our application’s main(). The degraded state persists until the simulator device is reset This causes UI tests to hang and eventually timeout. Business impact CI/CD jobs frequently timeout (90+ minutes per failed run) Significant loss of CI capacity Difficult to maintain reliable quality gates At our scale, this has become a serious issue affecting release confidence and overall engineering productivity. Technical details Crash report MyProject-2026-07-13-125307.ips — a crash report from a CI Demo project dyld_crash_demo — a minimal reproducible project demonstrating the relevant dyld execution path. The project intentionally returns errors from system functions along the shared cache initialization path to demonstrate that dyld continues execution until DyldSharedCache::getUUID(), where it subsequently crashes. Simply open the project and run it in iOS Simulator 26.2. Environment Component Version macOS Tahoe 26.x Xcode 26.2, 26.5 iOS Simulator 26.2, 26.5, 26.6 Architecture Apple Silicon dyld 1378 dyld_sim 1335 What we have ruled out multiple Xcode versions multiple macOS 26.x releases multiple iOS Simulator runtimes multiple simulator devices UI tests with parallel execution disabled deleting the simulator dyld shared cache recreating simulator devices application-specific issues (the crash happens before main()) The issue is still reproducible. Investigation The earliest observable failure sequence is consistently: shared_region_check_np() → "Cannot allocate memory" (ENOMEM) Shared cache mmap(0x180000000, ...) → EACCES The shared cache region remains unmapped DyldSharedCache::getUUID() reads 0x180000058 EXC_BAD_ACCESS (Translation fault) The crash occurs before any application code executes. The first faulting instruction belongs to DyldSharedCache::getUUID(), while the shared-cache region is still unmapped. Published dyld source analysis Relevant execution path: loadDyldCache() ↓ mapSplitCachePrivate() ↓ preflightCacheFile() Based on the published sources of dyld-1378, this appears to be the execution path leading to the observed failure. After the loadDyldCache() function failed to load the cache, dyld continued execution anyway and moved on to calling the DyldSharedCache::getUUID() function, where it subsequently failed. Additional observations Once the simulator enters the degraded state: simctl spawn succeeds. simctl launch crashes inside dyld before reaching main(). During our experiments, both processes were created by the same launchd_sim instance Before dyld::_dyld_start, both processes expose the same virtual address layout, including an unmapped shared-cache region (0x180000000–0x300000000). Current workaround As a temporary mitigation, we launch the application with DYLD_SHARED_REGION=avoid In our environment, this completely avoids the launch failures. However, this mode appears to be undocumented and intended primarily for debugging. We are concerned that it may change or stop working in future macOS or Xcode releases, so we are reluctant to depend on it in our production CI infrastructure. Questions 1. dyld Is it expected for dyld to continue dereferencing the shared-cache header after both the shared-region initialization and the shared-cache mapping have already failed? Execution appears to continue into: loadInfo.loadAddress->getUUID(cacheUuid) which results in an access to an unmapped address. The attached demo project reproduces this behavior by simulating failures from the shared-cache initialization path. Is there an expected fallback behavior for this situation or is continuing into DyldSharedCache::getUUID() the intended behavior ? 2. Simulator state Why does a simulator that initially launches applications successfully eventually enter a state where every subsequent launch fails while the shared cache can no longer be mapper? The earliest related system log we have found is: vm_shared_region_start_address() returned 0x1 Is this a known CoreSimulator or macOS Tahoe issue? If so, is there a supported workaround or recommended long-term solution besides DYLD_SHARED_REGION=avoid? Any guidance would be greatly appreciated.

I'm running a PoC to validate remote push notification delivery on macOS (AppKit, no Storyboard, programmatic setup) using UNUserNotificationCenter. Environment: macOS Version 26.5 (25F71) Xcode Version 26.2 (17C52) App: sandboxed, entitlements include aps-environment: development, Push Notifications + Background Modes (Remote notifications) capabilities enabled Auth: token-based (.p8 key, ES256 JWT), sent via curl directly to api.sandbox.push.apple.com Setup: UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in if granted { NSApplication.shared.registerForRemoteNotifications() } } Delegate implements both: func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) and the legacy: func application(_ application: NSApplication, didReceiveRemoteNotification userInfo: [String: Any]) Repro steps: App launches, permission granted (true), device token successfully obtained via didRegisterForRemoteNotificationsWithDeviceToken Local notifications (via UNNotificationRequest + UNTimeIntervalNotificationTrigger) work correctly — banner displays, willPresent fires as expected Send a remote push via curl: curl -v --header "apns-topic: $TOPIC" --header "apns-push-type: alert" \ --header "authorization: bearer $AUTHENTICATION_TOKEN" \ --data '{"aps": {"alert": {"title": "Test Title","body": "Test Body"}}}' \ --http2 https://api.sandbox.push.apple.com/3/device/$DEVICE_TOKEN APNs responds HTTP/2 200 with a valid apns-id — accepted successfully Observed: No banner appears on screen Notification does not appear in Notification Center either Console log shows application(_:didReceiveRemoteNotification:) fired with the correct payload willPresent is never called for this remote push, despite firing correctly for local notifications in the same session Question: Given willPresent is documented to be the method responsible for foreground presentation decisions, and it's working correctly for local notifications, why would a remote alert-type push (with a proper alert dict, no content-available) route only through the legacy didReceiveRemoteNotification path and never reach willPresent/get displayed, despite a 200 response from APNs? One thing I noticed while investigating: the App ID used for this app (auto-created by Xcode's automatic signing) lists its Platform as "iOS, iPadOS, tvOS, watchOS, visionOS" only — macOS is not checked, even though the app itself is macOS-only and Push Notifications capability shows as enabled. Could this platform scoping on the App ID be responsible for APNs/the OS accepting the push at the network layer but not treating it as "alert-UI eligible" for display? Is macOS required to be explicitly checked as a platform on the App ID for willPresent to be invoked correctly, or is that unrelated? Any guidance on what determines whether a remote push is routed to the foreground presentation path vs. the legacy background delegate path on macOS would be appreciated.

Since updating to macOS 27 beta 3 (build 26A5378j), my Mac is unable to establish any new TCP connections. This affects all outbound traffic regardless of destination or protocol, while ICMP (ping) continues to work normally. Steps to reproduce: Update to macOS 27 beta 3 (26A5378j) Connect to a standard home Wi-Fi network (no VPN, no proxy, no enterprise MDM profile) Attempt any outbound TCP connection (curl, git pull, ssh) Expected behavior: Connections to any HTTPS endpoint or SSH server should establish normally. Actual behavior: curl -4 -v https://github.com curl -4 -v https://google.com both hang indefinitely at "Trying [IP]..." — the TCP handshake never completes git pull over both HTTPS and SSH remotes times out with "Failed to connect... Timeout was reached" ping github.com and ping google.com both succeed normally and immediately This confirms the issue is isolated to TCP connection establishment, not DNS resolution or general network connectivity Issue persists identically across multiple reboots System info: macOS 27.0 beta 3, build 26A5378j Connected via personal home Wi-Fi (Bbox router) No VPN, no proxy, no enterprise security software Additional context: Multiple other users have reported identical symptoms on this same build across MacRumors forums and Reddit, describing broken connections in Firefox, Opera, Dropbox, Telegram, and Music/iTunes purchases, while Safari continues to work. Reported workarounds from other affected users include: Disabling "Limit IP Address Tracking" on the network interface Disabling all Network Extensions under System Settings → General → Login Items & Extensions Uninstalling CrowdStrike Falcon or similar EDR/security software (where present) This was working correctly on both beta 1 and beta 2, the regression appears to have been introduced specifically in beta 3.

In /usr/include/libproc.h, there are a few number of APIs listed as private but which are commonly used (e.g. proc_pidpath). I'm trying to figure out how the proc_listallpids API is supposed to be used. From the examples I'm seeing in open source projects, the idea is to: call proc_listallpids(NULL, 0) to get a hint about the number of pids currently existing. call proc_listallpids with an appropriate buffer and retry if needed (I guess if the number of processes grew more than expected between the 2 calls). OK. What I'm not getting is how the resulting array of pids is to be used. What I am observing is that the array of pids you get is a list of the existing of the existing pids in a descendant order. BUT after pid 0, there can be additional pids. Numerous projects are just skipping pid = 0, but are using the pids after 0 as if they were valid. From what I'm seeing these are not valid pids and the correct way to handle the array of pids is to stop at pid 0 (or 1 if you want to skip the "kernel"). [Q] Is the proc_listallpids like the proc_pidpath a Voldemort API? Everyone can see it but you are not allowed to discuss it and to get more info about it you need to contact DTS. Or is it possible to know the right way to use this API and its results?

Hi, I'm experiencing a strange issue with iCloud Drive and Xcode on a Mac mini (Apple Silicon). Environment Mac mini (Apple Silicon) macOS Tahoe 26.5.2 Xcode 26.5 Symptoms Files in iCloud Drive Desktop stay at "Waiting to Update" for several days. Cloud icons never disappear. Moving projects from iCloud Drive Desktop to ~/Developer takes hours or never finishes. Existing Xcode projects stored in iCloud Drive open as a white "Loading..." screen forever. New Xcode projects work normally. Projects already moved to ~/Developer (for example one project) open and build normally. What I have already tried Restart Mac Updated to the latest macOS Cleared Xcode caches (DerivedData, Archives, old simulators) 132 GB free disk space killall fileproviderd killall bird brctl download brctl diagnose fileproviderctl check -P Logs After restarting fileproviderd, I continuously get messages like: Possible slow statement on SELECT ... scheduler not stable: jobs are running fetch-metadata ... is busy fileproviderd constantly uses around 70% CPU. Also, fileproviderctl check -P never completes. It stops at: "About to launch FPCK checks for 1 domains" and stays there for more than 10 minutes. Questions Has anyone experienced this with macOS Tahoe? Is this likely a CloudDocs/FileProvider database issue? Is there any safe way to repair the FileProvider database without risking iCloud data? Is there any way to identify or clear the stuck synchronization queue? Any advice would be greatly appreciated.

When running a native macOS app using SwiftUI and a NavigationStack, clicking any links causes the contents of the stack to change immediately with no animation, and you can't use the usual two-finger swipe gesture to go back. The behavior is correct when running it as a Mac Catalyst app, you get the animated transitions when navigating, and swiping works. Minimal Example: (put this directly inside the WindowGroup) NavigationStack { VStack { NavigationLink { Rectangle().foregroundStyle(.red) } label: { Text("Button") } } }

In AppKit, NSSavePanel can be used to ask the user for a destination URL before the app creates a file. What is the SwiftUI equivalent for this? .fileImporter covers the NSOpenPanel case well enough, but I have not found a SwiftUI API that matches the simple NSSavePanel case where the app only needs the URL. There's a new API in .fileExporter that appears close, but it requires a non nil WritableDocument, and seems designed around SwiftUI performing the file export. My use case is a macOS app that creates new documents backed by SQLite. SQLite needs a file path so it can create the database at that location. With NSSavePanel, I can ask the user where to save the document, receive a URL, and then create the SQLite database myself. Is there a SwiftUI API for this on macOS 26 or later? If not, is NSSavePanel still the recommended approach for this case?

I am currently developing an app for MacOS that needs to control HomeKit devices like lights. However, it seems like MacOS is supported on the official documentation, but not when I try to create an app ID on developer.apple.com. On the link https://developer.apple.com/apple-home/, MacOS is clearly showed as supported for MacOS. But when I try to create an app ID, it shows that it is only compatible for iOS, VisionOS and WatchOS. Could this be clarified? Best regards, orangeidle25

I have run into an interesting topic today. So far, I have been under the impression that when I am using the setCodeSigningRequirement() function on an NSXPCConnection, I am completely removing any chance of receiving AND sending messages to untrusted XPC Peers. However, I created a malicious replacement for my daemon, and I wanted to check if my application can still send and receive messages to it. I checked with codesign --verify that the replacement does NOT fulfil the code signing requirement. I put a system log instruction in the malicious tool's XPC function. When calling the XPC Peer, I expected to see: XPC connection to <redacted> failed! [Error Domain=NSCocoaErrorDomain Code=4102 "The code signature requirement failed." UserInfo={NSDebugDescription=The code signature requirement failed.}] and I did. However, I also saw the system log from the malicious tool's XPC function. Then, I checked all XPC documentation, and I found for the original C implementation - xpc_connection_set_peer_code_signing_requirement() - the following in the discussion section: All messages received on this connection will be checked to ensure they come from a peer who satisfies the code signing requirement. For a listener connection, requests that do not satisfy the requirement are dropped. When a reply is expected on the connection and the peer does not satisfy the requirement XPC_ERROR_PEER_CODE_SIGNING_REQUIREMENT will be delivered instead of the reply. (this is in xpc/connection.h) which seems to align with the observed results. However, this is (embarassingly?) new for me, I would have never expected this, given how in my head pre-checking before any connection is made seems straightforward, even with public Apple SDK APIs: Grab a SecCode (not SecStaticCode) object of the daemon (malicious or not). This is running code, so it cannot be substituted between the check and the outgoing message. Perform validations on the SecCode object in some form - on macOS 15.0+ it's pretty easy with LightweightCodeRequirement's SecCodeCheckValidityWithProcessRequirement(). Immediately drop the connection if the peer is untrusted, before any message is sent. Am I overlooking something or making wrong assumptions here? or Am I right and this is something that I have to accept that's implemented less than ideally and I can perform above steps 1-3 myself and make a difference? Thanks in advance!

Hello, I'm unable to install macOS 27 Beta 1 on relatively clean test system - 15" MacBook Air M4 16GB RAM. Error from installer log: Jun 9 09:55:29 COMPUTERNAME osinstallersetupd[11696]: Operation queue failed with error: Error Domain=com.apple.OSInstallerSetup.error Code=1007 "An error occurred preparing the update." UserInfo={NSLocalizedRecoverySuggestion=Failed to personalize the software update. Please try again., NSLocalizedDescription=An error occurred preparing the update., NSUnderlyingError=0xbdbf93f30 {Error Domain=SUMacControllerError Code=7723 "[SUMacControllerErrorPreflightPersonalizeFailed=7723] Failed to perform PreflightPersonalize operation: [MobileSoftwareUpdateErrorDomain(MSU):MSU_ERR_PERSONALIZATION_FAILURE(2)_1_MobileSoftwareUpdateErrorDomain(MSU):MSU_ERR_GLOBAL_TICKET_INVALID(53)]" UserInfo={NSLocalizedDescription=Failed to personalize the software update. Please try again., SUMacControllerErrorIndicationsMask=0, NSDebugDescription=[SUMacControllerErrorPreflightPersonalizeFailed=7723] Failed to perform PreflightPersonalize operation: [MobileSoftwareUpdateErrorDomain(MSU):MSU_ERR_PERSONALIZATION_FAILURE(2)_1_MobileSoftwareUpdateErrorDomain(MSU):MSU_ERR_GLOBAL_TICKET_INVALID(53)], NSUnderlyingError=0xbdbf93b10 {Error Domain=MobileSoftwareUpdateErrorDomain Code=2 "Could not personalize boot/firmware bundle." UserInfo={NSUnderlyingError=0xbdbf93d80 {Error Domain=MobileSoftwareUpdateErrorDomain Code=53 "Global ticket failed to verify" UserInfo=0xbdbfd2be0 (not displayed)}, NSLocalizedDescription=Could not personalize boot/firmware bundle., target_update=26A5353q}}}}} Not sure if anyone else has experienced this error?

I have an iOS app that I want to publish to the Mac App Store as a Catalyst app, but I noticed a situation where the app can't be closed and has to be force quit. The problem happens if the user has 0 photos in their Photo Library, and hits "Limited Access" on the request authorization prompt (In my case PHPhotoLibrary.requestAuthorization(for: .readWrite). Since the popup is a system prompt, I can't manually add a close button to it. I tried wrapping it in a view with a close button but the popup always shows up over any view I'm presenting within my app. If anyone has a workaround that would be greatly appreciated!

On macOS 27 Beta 2, a simple NavigationSplitView example exhibits bizarre behaviour when the window is resized. The sidebar seemingly expands and collapses at random as the window is resized. The symptoms can be exacerbated with toolbar items. The sidebar appears to behave correctly when an inspector view is not present. Copy paste the code below into a new Xcode 27 project and run on macOS 27 and then resize the window: File -> New -> Project... -> App import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { var body: some View { NavigationSplitView { Text("Sidebar") } detail: { Text("Content") } .inspector(isPresented: .constant(true)) { Text("Inspector") } } } Adding .frame or .inspectorColumnWidth to any of the Text views does not appear to fix the issues. macOS: 27.0 Beta (26A5368g) Xcode: 27.0 beta 2 (27A5209h)

In the System Settings > General > Login Items & Extensions - Extensions pane, when I select the By App tab, I can see multiple instances of extensions for different applications and sub-types. e.g. Books (from Apple) is listed twice with the Sharing subtype. For the specific extension I'm checking, I can see multiple instances listed for the File Provider sub-type. The number of instances does not seem to correspond to anything. There are 5 instances listed and it seems like these are not exact duplicates because when I disable one using the (i) dialog, the others are still enabled. This number (5) corresponds to nothing obvious: at one time, there is only 1 instance of the File Provider (a Finder Extension) installed. if I use the pluginkit command line tool to list the extensions, it only reports 3 known versions of this extension. As a developer I'm puzzled by this list with duplicates. As an end user, I'm totally puzzled by this list with duplicates. macOS Tahoe 26.5 (25F71) [Q] What is this list in the Login Items & Extensions pane supposed to represent? Is it known to be buggy when it comes to its contents?

I have an orphaned asset folder taking up 9.13GB located at: /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/c0d3fd05106683ba0b3680d4d1afec65f098d700.asset It contains SimulatorRuntimeAsset version 18.5 (Build 22F77). Active Version: My current Xcode setup is using version 26.2 (Build 23C54). I checked the plist files in the directory and found what seems to be the cause of the issue: The "Never Collected" Flag: The Info.plist inside the orphaned asset folder explicitly sets the garbage collection behavior to "NeverCollected": <key>__AssetDefaultGarbageCollectionBehavior</key> <string>NeverCollected</string> The Catalog Mismatch: The master catalog file (com_apple_MobileAsset_iOSSimulatorRuntime.xml) in the parent directory only lists the new version (26.2). Because the old version (18.5) is missing from this XML, Xcode and mobileassetd seem to have lost track of it entirely. What I Have Tried (All Failed) Xcode Components: The version 18.5 does not appear in Settings -> Components, so I cannot delete it via the GUI. Simctl: xcrun simctl list runtimes does not list this version. Running xcrun simctl runtime delete 22F77 fails with: "No runtime disk images or bundles found matching '22F77'." Manual Deletion: sudo rm -rf [path] fails with "Operation not permitted", presumably because /System/Library/AssetsV2 is SIP-protected. Third-party Tools: Apps like DevCleaner do not detect this runtime (likely because they only scan ~/Library or /Library, not /System/Library). Has anyone found a way to force the system (perhaps via mobileassetd or a specific xcrun flag) to re-evaluate this folder and respect a deletion request? I am trying to avoid booting into Recovery Mode just to delete a cache file. Any insights on how AssetsV2 handles these "orphaned" files would be appreciated.

Hello, I'm building an app that is designed to largely mimick Apple's own audio auto-switch behavior when switching between different audio output devices like MacBook Pro speakers and AirPods. The purpose is to "lend a hand" to certain apps, like CrossOver (wine) ran x68-64 apps that don't seem to respond well to CoreAudio changing the audio output after the x68-64 program has already init its audio after startup. Thus, I don't actually need much of a GUI except for a few specific features, and perhaps later some ehancements I'd like to add that can make use of a proper GUI. I've decided to implement the MacOS Tahoe Apple Liquid Glass UI to keep the user experience as streamlined and intuitive as possible. I've largely been successful: The GitHub page goes into greater detail showing the greater context of the AppKit API's I'm using to achieve this UI design. There is just one issue I haven't been able to solve, how to get the sidebar tab(s) to blur when scrolled underneath the Window Controls (Traffic Light) buttons. These tabs are part of a NSScrollView underneath the NSToolbar aligned from the top-most left and right window edges, but split from the right-hand content side via NSSplitViewController > NSSplitViewItem (again exact topology is at the page "link" below). On the content side (right side), I used NSSplitViewItemAccessoryViewController to create the blur zone so that when its own NSScrollView content is scrolled upwards, past the toolbar NSToolbar, it would apply a progressive tint+blur effect, just as Apple has implemented in their own apps. This wasn't really automatic since I did have to elect to use it as part of a MacOS 26.1+ specific class (NSScrollEdgeEffectStyle), but it's working on the content side nonetheless: Now I am trying to get the same effect working on the sidebar side and am having issues with this. Please see the page below as it summarizes our test attempts with greater detail. I've only gotten this far by reading "obscure" comments in the SDK's so I'm really hoping this is just a ID10T error in that I've missed something. Note: even though I only have 3 tabs currently in the sidebar NSScrollView, I will eventually populate this further, especially with some user configurable stuff on my roadmap. That said, the sidebar is only "scrollable" right now because I've left the "vertical scroll elasticity" enabled, intentionally. (.verticalScrollElasticity [IS NOT] .none! Therefore, I can still "scroll" the enumerated tabs inside the sidebar's NSScrollView upward behind the Traffic Light buttons, to validate if the blur+tint effect is being rendered. I say all of that to ask if, perhaps, the reason that the blur+tint effect is not rendering in the Window could be because there's not enough content to render in the sidebar to produce a scrollbar, and simply leaving .verticalScrollElasticity "enabled" is not sufficient to produce this effect? I don't know that for sure, but it's the only thing I can think of at this point. Its not obvious to me though. This app is written entirely in Swift (v6.3.3) and will require a minimum of MacOS Tahoe 26.1.X due to the AppKit API's I'm using (namely NSScrollEdgeEffectStyle). GitHub Page documenting issue in greater detail (remove the spaces): HT TP S:// gitdev.brianbutts.me /sidebar-scroll-edge-blur. html

Hi all: We use MDM profile to apply Full Disk Access permission for app on macOS, After profile deployed successfully, The App can get correct Full Disk Access permission, However, on "Privacy & Security" UI, we found that our app shown disabled, see as however, on some macOS, it showed correctly as below The issue happened on different os version. macOS 15 and macOS 26 When the item shown as disable, even reboot computer several times, the issue still persist. Thanks for your help

I'm seeing what appears to be different UISceneAppIntent behavior between iOS and Designed for iPad on macOS, and I'd like to confirm whether this is expected. I'm working on an iOS app that defines an AppIntent conforming to UISceneAppIntent from the AppIntents framework. The intent is handled by a scene delegate conforming to both UIWindowSceneDelegate and AppIntentSceneDelegate. On iOS, everything works as expected: If the app is launched for the first time from Shortcuts, the intent is available via connectionOptions.appIntent in scene(_:willConnectTo:options:). If the app is already running, scene(_:willPerformAppIntent:) is called. However, when running the same iOS app on macOS in Designed for iPad mode, the behavior is different: If the app is launched from Shortcuts, connectionOptions.appIntent is always nil in scene(_:willConnectTo:options:). If the app is already running, scene(_:willPerformAppIntent:) is never called, even though the application is successfully activated. Is this expected behavior? I noticed that the AppIntents framework explicitly marks both AppIntentSceneDelegate and UISceneAppIntent as unavailable on macOS: @available(iOS 26.0, tvOS 26.0, *) @available(macOS, unavailable) @available(watchOS, unavailable) public protocol AppIntentSceneDelegate : UISceneDelegate Since the app is running on macOS in Designed for iPad mode and still uses the iOS binary, I wasn't sure whether these scene-based APIs are expected to work in this environment or whether they are intentionally unsupported. Has anyone from Apple or the community been able to confirm whether this behavior is by design, or whether it should be considered a bug? I'd appreciate any clarification.

Hi, I am trying to build an installer package of an usual(?) format: it contains a binary that I am developing code signing and notarization is straightforward here. it contains a 3rd-party binary that is open source, code signed and notarized by this third party code signing and notarization is also straightforward here as it's already been done. it also contains a 3rd-party binary that is also open source, however, it is not code signed or notarized This last one is the subject of my question. It is a well-established project with thousands of stars on GitHub, however their own "installation method" is a shell script that downloads the binary, checks its checksum and just places it in the right location. When building an installer package (it's an installer package of these three binaries packaged - productbuild with --distribution flag) this binary needs to be code signed and notarized for Developer ID distribution. I trust this binary, however the chance of supply chain attacks is never zero. My questions are: How can I shield myself best against accidentally submitting a malicious version of this third binary via notarytool to Apple? Should I separately submit versions of this binary for notarization from submitting new versions of my app? This binary is bound to change way less frequently than the app I'm actually developing. I really don't want to risk termination of my Apple Developer account because it has many high-value applications available. I am doing some basics - matching the intended checksum before packaging, signing with the hardened runtime entitlement - but I would love to hear if there's other steps I can do to protect this pipeline and my company from accidents like these that may unintentionally damage our reputation. Thanks in advance!

My app is sandboxed and for one feature listens for an incoming connection on a user selected port. When the firewall is enabled and block incoming (all, this app, or signed apps) is enabled, I want to be able to not offer this feature with a brief explanation. I tried using /usr/libexec/ApplicationFirewall/socketfilterfw but that fails when used in a sandboxed app. I have an XPC module, which is also sandboxed, and the call fails there as well. If I remove the sandbox from the XPC then the call succeeds but then is unable to communicate with the main app. Is there an API to determine if the firewall is enabled and all connections blocked? I've submitted a Feedback request (FB23378402) as well.

MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated?