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?

Hello, I am developing a native macOS utility using SwiftUI and AppKit, and I am investigating whether its power scheduling features can be implemented in a sandboxed app distributed through the Mac App Store. The intended functionality is: Schedule power-on from a fully shut-down state, not just wake from sleep. Schedule wake from sleep and shutdown. Let the user select weekdays and times, and modify or cancel the schedule. Keep the schedule effective after the user quits the app. For example, the user could explicitly configure power-on at 08:00 and shutdown at 22:00, Monday through Friday. My local prototype uses pmset with administrator authorization. For a possible Mac App Store version, I am looking for a supported implementation that does not execute privileged shell commands or run an application helper as root. What I have checked The documentation for IOPMSchedulePowerEvent states that it must be called as root. Calling that API directly therefore does not appear to remove the privilege requirement. App Review Guideline 2.4.5 requires sandboxing and prohibits requesting escalation to root privileges. I also reviewed launchd scheduling and user-supplied scripts through NSUserAppleScriptTask, but neither appears to provide a self-contained solution for scheduling power-on from shutdown without privileged operations. Questions Is there a public API or system-mediated authorization mechanism that supports this functionality from a sandboxed third-party app? Is there a requestable entitlement specifically applicable to power-event scheduling? If the complete feature set is unsupported, which operations are available within App Sandbox: power-on from shutdown, wake from sleep, and scheduled shutdown? The current deployment target is macOS 13 or later, on Apple silicon and Intel. If a supported solution requires a newer macOS version or specific hardware, that information would also be helpful. I am asking about supported API capabilities and architecture, rather than advance App Review approval. A documentation reference—or confirmation that scheduled power-on from shutdown is unavailable under these constraints—would help me choose the appropriate distribution model. Thank you.

I’m looking for a supported way to investigate startup latency before main() in a short-lived native macOS child process, while preserving its original parent-child relationship. Environment macOS 26.6.2, build 25G83. Native arm64 executables. The on-disk /usr/lib/dyld contains the identifier dyld-1387; this is a static observation, not independent verification of all runtime shared-cache components. The diagnostic runs were started manually from normal macOS Terminal. All inputs and target processes are synthetic test fixtures. Execution structure Test supervisor → Watchdog → Observer → Query Observer launches Query using posix_spawn(). Query checks a synthetic target process’s identity using Security.framework and produces a fixed 28-byte result. Observer passes an explicit environment containing only LANG=C and LC_ALL=C. Consequently, exporting DYLD variables in the outer Terminal would not pass them to Query. Our existing test has a 1000 ms Query deadline and requires empty Query stderr. This is an application-defined acceptance requirement, not a claimed macOS timing guarantee. Observed results A historical full regression run timed out at approximately 1001 ms, with no Query result bytes received. That run did not have main-entry instrumentation, so we cannot determine where its time was spent. A later isolated, instrumented run measured: posix_spawn return to Query main entry: 832.687 ms main entry to return: 24.179 ms Observer-measured Query elapsed time: 864 ms Another isolated, instrumented run measured: posix_spawn call duration: 0.179 ms spawn return to main entry: 634.334 ms main entry to return: 6.757 ms Observer-measured Query elapsed time: 647 ms In the third run, getrusage(RUSAGE_SELF) at main entry reported cumulative CPU time of 3.014 ms user and 2.583 ms system. Before main returned, the cumulative total was 8.088 ms. Timeline measurements used CLOCK_MONOTONIC. Interpretation limits These successful diagnostic runs do not explain or resolve the historical timeout. Instrumentation changes the executable, and cache state and scheduling may differ. The CPU and wall-clock measurements cover different intervals. Subtracting them would not give an exact waiting-time measurement. We cannot currently attribute the delay to dyld, scheduling, security checks, IPC, or I/O. Diagnostic constraints We want to preserve the original parent-child relationship and avoid system-wide collection, disabling security protections, or silently changing permissions. We have not established that the Instruments App Launch configuration available to us can capture this child’s earliest startup phases while restricting collection to Query. The historical DYLD_PRINT_STATISTICS options are not documented in the installed dyld manual. Attaching a sampling tool after obtaining the PID may miss the relevant startup interval and may perturb this short-lived process. Questions What supported tool or API on this macOS version can distinguish startup phases before main() for this posix_spawn-created child? Can collection itself be restricted to Query, rather than collecting system-wide data and filtering the report afterward? What permissions are required, which early phases remain unobservable, and how much observer perturbation should we expect? If these constraints cannot all be met, what is the smallest necessary change to the diagnostic setup? What minimal sample project and evidence would be most useful for further investigation? I have preserved the original failure and subsequent diagnostic evidence, but do not yet have a standalone Xcode sample that reliably reproduces the historical timeout. I’m requesting guidance on an appropriate measurement method, not asserting that this is a confirmed macOS defect.

Hello, I'm evaluating a local macOS helper service with a minimum deployment target of macOS 13. The service would communicate over an AF_UNIX SOCK_STREAM socket and must authenticate the signed code identity of the connecting process before accepting an operation. I'm investigating whether LOCAL_PEERTOKEN can provide a reliable audit token associated with the peer of an accepted socket. The public macOS SDK declares LOCAL_PEERTOKEN in sys/un.h, but I haven't found documentation establishing its precise security guarantees or availability across supported macOS versions. My questions are: Is LOCAL_PEERTOKEN a public, supported API on macOS 13 and later? Can it be used with getsockopt() on a file descriptor returned by accept() to retrieve an audit_token_t for the connected peer? At what point is the peer identity captured? Is the returned audit token securely bound to the original connecting process, even if that process exits and its PID is reused? Is the audit token obtained through LOCAL_PEERTOKEN officially supported as input to Security.framework APIs such as SecCodeCopyGuestWithAttributes (using kSecGuestAttributeAudit) or SecTaskCreateWithAuditToken? Does the identity remain trustworthy if the connected socket descriptor is inherited or passed to another process? Are there documented limitations concerning descriptor passing or time-of-check/time-of-use races? What is Apple's recommended public API sequence for verifying the signed code identity of an AF_UNIX peer on macOS 13+, including in an App Sandbox environment? I'm looking for documented security and availability guarantees rather than relying solely on observed behavior. Thank you!

Circling back on the LocalLM Lab arc. With v0.7, we've moved from prompt experimentation into real app development on Apple's Foundation Models local AI. The LocalLM Lab SDK lets you build that same on-device model and MCP client this thread has covered directly into your own app, with real tool and data access (Slack, Todoist, GitHub, Notion, Linear, plus Calendar, Reminders, Contacts and Location). And you can ship your app including through the Mac App Store. This is a big improvement over version 0.6, where the localai-cli toolkit needed LocalLM Lab installed and running. On the other hand, the SDK (LocalLMLabSDKCore) doesn't relay through anything; it links FoundationModels and a real MCP client directly into your own binary and is totally self-contained. The example included in the SDK, Plate Today, has actually been built into a sandboxed test app and verified working, with a signed path to a Mac App Store .pkg (Apple Distribution signing + provisioning profile pipeline). That's "verified signable and sandbox-compatible," to be precise. Entitlements (from personal experience: always a complicated topic): com.apple.security.app-sandbox + com.apple.security.network.client for the app itself, plus the standard personal-information entitlements per connector used (com.apple.security.personal-information.calendars, .addressbook, .location) and matching NS*UsageDescription strings in Info.plist. The one worth flagging specifically: the network entitlement is easy to miss and fails silently rather than throwing. Without it, MCP connections and Weather calls just hang with no error surfaced. OAuth handling requires the app delegate callback (application(_:open:)), not SwiftUI's .onOpenURL. Worth knowing before wiring it up if you're SwiftUI-only. Full entitlements list + SDK guide: https://github.com/ancientcomputing/locallm/blob/main/docs/sdk-guide.md Feature page: thisbrain.ai/locallm/sdk.html I hope the availability of the SDK (free, Apache 2.0 license) will give folks further incentive to explore local AI-enabled applications on the Mac. What else would you want to do that the SDK doesn't currently support? File picker? Calendar/Reminders/Contacts edits & writes?

Hello, I'm designing a local macOS helper service (minimum deployment target: macOS 13) that performs one fixed syntax-validation operation. The submitted source is never executed. The security contract requires: A maximum incoming transport request size of 327,680 bytes. Immediate rejection when the 327,681st byte is encountered, without an allocation proportional to an unbounded sender-controlled payload. No application-level response for an oversized transport request, followed by termination of the affected connection. Complete application responses limited to 65,536 bytes, without treating truncated output as successful. I've reviewed the public XPC APIs, including xpc_data_get_length, xpc_connection_cancel, and xpc_connection_set_peer_code_signing_requirement. The remaining uncertainty is whether XPC can enforce a receiver-side message-size limit before materializing the incoming payload. My questions are: Does any public XPC API on macOS 13+ provide a documented maximum incoming message size that is enforced before payload materialization or proportional allocation? If not, is the entire incoming XPC message necessarily materialized before the application event handler receives it? Is there a supported XPC design for guaranteeing bounded receiver memory with untrusted input, or should this requirement use a different local transport, such as an AF_UNIX SOCK_STREAM socket? What guarantees does xpc_connection_cancel provide regarding connection termination, pending messages, and prevention of connection reuse after detecting malformed or oversized input? I'm specifically looking for documented platform guarantees rather than behavior that happens to work in testing. Thank you!

Every macOS update fails during preflight personalization on my MacBook Pro (Mac15,6, Apple Silicon), currently on 27.0 build 26A5378j. It's failed on every build from beta 5 (26A5406e) through beta 7. Identical failure via Software Update and via startosinstall. It fails LOCALLY, before contacting Apple (gs.apple.com and gdmf.apple.com are both reachable with valid certs). Error (install.log + unified log): reaches PREFLIGHT_PERSONALIZE (~0.15), then aborts MobileSoftwareUpdateErrorDomain Code=1259 "failed to copy firmware identity" "could not obtain device identity information through SFR installer" SUMacControllerErrorPreflightPersonalizeFailed=7723 Root cause I've traced: an orphaned volume-group boot-policy directory in /System/Volumes/iSCPreboot/. ls shows two volume-group UUID dirs — the live one (matches diskutil info /) and an orphan (3D3287DE-...) with no corresponding APFS volume group (diskutil apfs list shows only one live group). Both date to Feb 2024. The preflight can't reconcile the System Recovery boot policy in the orphaned dir. Note: NOT caused by Erase All Content and Settings (unlike the commonly reported case). The orphan predates the beta, so any pre-existing second volume-group boot-policy directory reproduces it. It was harmless for ~2 years; macOS 27's stricter preflight rejects it. Ruled out (no effect): disk space, VPN, DNS, clock, Apple Account, refreshing the beta seed entitlement, reboot, Time Machine, re-downloading the installer, and Recovery reinstall (same 1259). Filed as FB24342236 — no response across beta 5, 6, 7. Questions: Is this a known issue with a planned fix, and in which build? Any supported recovery path that does NOT require a second Mac? (Recovery reinstall fails the same way.) Or is DFU Revive/Restore the only option? Will the public 27.0 release install on this machine, or hit the same preflight?

Hello Apple Developer Community, We are developing a macOS application with a minimum deployment target of macOS 14.0. We are investigating a process-supervision safety problem involving the following topology: Root → Worker → Child The Worker creates the Child using native process APIs and is responsible for supervising its lifecycle. The critical failure scenario Worker successfully creates Child. Child exists, but its verified process identity has not yet been communicated to Root. Worker unexpectedly terminates before completing the identity handoff. Root must avoid signaling an unrelated process while ensuring that an untracked Child cannot continue executing without authorization. Our safety requirements Independently establish Child's exact process-lifetime identity. Prevent unsafe process signaling caused by PID reuse. Handle Worker failure before identity handoff. Verify process termination and disposition. Avoid relying on private APIs or restricted entitlements. Maintain compatibility with macOS 14 and later. What we have investigated We have reviewed posix_spawn, waitpid, process observation APIs, audit-token-based process identification and signaling, Endpoint Security, and launchd-based supervision. We understand that Endpoint Security FORK events are notifications rather than authorization events, and that dropped notifications may prevent complete birth tracking. We also found es_new_descendants_client in the macOS 27 SDK, but it requires an Endpoint Security entitlement and does not meet our current macOS 14 deployment requirements. We understand that a process cannot automatically use waitpid to reap a grandchild merely because the intermediate parent has terminated. Our questions Is there a publicly supported macOS 14+ API or process-supervision mechanism that can reliably establish the identity of a Worker-created Child even if Worker terminates before communicating that identity? Is there a supported approach for safely containing such a Child when its identity is not yet known to Root? Can audit-token-based signaling provide sufficient process-lifetime identity guarantees for this scenario, and what minimum macOS version supports the relevant APIs? Is there a supported mechanism for independently verifying Child termination when Root is not its direct parent? If this cannot be guaranteed using public APIs, would Apple recommend changing the architecture so that Root directly creates and supervises Child? We are not requesting private API access or Endpoint Security entitlements. We would appreciate guidance on the supported macOS process-lifecycle contracts before proceeding with implementation. Thank you for your assistance.

We're seeing a recurring kernel panic across six Mac17-family Macs (Mac17,2 / Mac17,4 / Mac17,8; T8142 and T6050) in a managed fleet. 34 panic logs collected 30 Sept – 9 Oct, all with the same signature: panic(cpu N caller ...): Kernel tag check fault (expected tagged address: 0x...028), esr 0x96000011 Faulting address is always at offset 0x28 of the object Same crash PC per build: kernel text exec base + 0x48da38 on 27.0/27.0.1, + 0x46a784 on 26.7, + 0x466ee0 on 26.5 Panicked task is "Google Chrome Helper" in all 34 cases, thread Chrome_ChildIOThread (Chrome's IPC/network I/O thread) Always 3–60 s after wake from sleep, usually a dark wake with the lid closed (overnight or after a 3–18 min sleep) No third-party kexts loaded; "Post-boot loaded kexts" lists only Apple drivers Affected builds: 26.5 (25F71), 26.7 (25G229), 27.0 (26A428), 27.0.1 (26A434). Not a regression from one update: a machine still on 26.5 panics identically. Only Mac17-family hardware is affected. Older Apple silicon Macs with the same software stack are fine. Present on every affected machine: Chrome PWAs (Gmail/Chat/Meet) running in the background, keeping Chrome's network service alive across sleep. On one machine Microsoft Edge is the primary browser and never panics; only Chrome Helper does. Microsoft Defender for Endpoint with its network filter (content filter) extension, MDM-managed. This looks related to thread 821372, where DTS described a kernel networking panic on M5-family hardware with a Network Extension present (r.172793638 / FB22401652), fixed in 26.5b2. We appear to be seeing a tag-check-fault variant on 26.5 release and later. Questions: Is this a known issue, and is it the same root cause as r.172793638? Is there a build where it's fixed? Any recommended mitigation beyond preventing sleep and quitting Chrome? Feedback Assistant: FB25128015 with panic logs and sysdiagnose. Happy to collect more data or test a build. Backtrace from a 27.0.1 panic (kernel text exec base 0xfffffe003aa54000), panic PC first: lr: 0xfffffe003aee1a38 lr: 0xfffffe003aeec580 lr: 0xfffffe003b12cf34 lr: 0xfffffe003b12dc50 lr: 0xfffffe003b07b1f8 lr: 0xfffffe003b07c758 lr: 0xfffffe003b237ff4 lr: 0xfffffe003ac787f0 lr: 0xfffffe003aa576ac lr: 0x000000018747a57c (userspace)

Under macOS 27 using Mac Catalyst for a UIKit-based app, If you present a view controller with a table view as a form sheet or page sheet, row reordering fails to function. You can drag a row as expected but the blue movement bar never appears and if you drop the row it simply returns to its original location. The exact same view controller presented as a popover works just fine. The exact same view controller not presented as a modal (such as the app's root controller) works just fine. This is a serious bug affecting existing applications and being reported by paying customers. This has been reported as FB25038883 which includes a simple sample app demonstrating the issue.

Hi, I would like to update that we have a kext that has IOStorageFamily in OSBundleLibraries. I would like to know whether we can create DriverKit that support this family and embed in SystemExtension for deployment? and we have another kext that has combination of IOStorageFamily and IOUSBFamily in OSBundleLibraries. Please let me know whether such type of Kext can be converted into DriverKit. I am new to DriverKit development. Please let us know if there is any sample that has these bundles in DriverKit so that I can check. Please let us know if such are supported with DriverKit then what are the capabilities that we need to add in entitlement request so that it can get approved. Thanks & Regards, Mohmad Vasim

Can anyone help to understand what is causing this warning message on this SampleCode. it happens when data in table gets updated it happens when I have lot of items in table and search for lets say # 6543 and then clear the search. "WARNING: Application performed a reentrant operation in its NSTableView delegate. This warning will become an assert in the future." If there are just few items in table, the warning is not there. And it started when updated to Xcode Version 14 and upward import SwiftUI import Foundation @main struct TestProjectSWIFTApp: App {     @StateObject var mydata: MyData = MyData()     var body: some Scene {         WindowGroup {             ContentView()                 .environmentObject(mydata)         }              } } struct ContentView: View {     @EnvironmentObject var mydata: MyData     var body: some View {         NavigationView{             NavigationLink("TABLE",  destination: MyTable())                      }     } } struct User: Identifiable {     let id: UUID = UUID()     var name: String     var score: Int } struct MyTable: View {     @EnvironmentObject var mydata: MyData     @State private var sortOrder = [KeyPathComparator(\User.name)]     @State var searchText: String = ""     var searchResults : [User] {         if searchText.isEmpty {             return mydata.alldata         } else {             return mydata.alldata.filter{$0.name.localizedCaseInsensitiveContains(searchText)}         }     }          var body: some View {                  Button("Generate new data", action: {             mydata.updateTable()         })                  Table(searchResults, sortOrder: $sortOrder) {             TableColumn("Score"){                 Text("\(Double($0.score))")             }             TableColumn("user", value: \.name)         }         .onChange(of: sortOrder) {             mydata.alldata.sort(using: $0)         }         .searchable(text: $searchText)     } } @MainActor class MyData : ObservableObject{     @Published var alldata: [User] = []               init(){         self.setData()     }          func setData(){         alldata = [             User(name: "User 1", score: 95),             User(name: "User 2", score: 80),             User(name: "User 3", score: 85)         ]     }          func updateTable(){         var newallData: [User] = []         var x = 0         while x < 10000{             newallData.append(User(name: "User #\(x)", score:  Int.random(in: 10..<999999)))                          x = x + 1         }         alldata = newallData     }      }

After upgrading my M1 MacBook Pro from macOS 26 to macOS 27, my NuPhy Kick75 Bluetooth keyboard started randomly disconnecting during normal use. This issue did not occur on macOS 26 with exactly the same Mac, keyboard, physical location, and usage environment. The problem started immediately after upgrading to macOS 27. The keyboard disconnects approximately 2–3 times per hour. When the interruption occurs, the Bluetooth connection indicator on the keyboard also shows that the Bluetooth link has been lost. This is therefore an actual Bluetooth disconnection rather than only input lag or delayed keyboard events. The keyboard automatically reconnects shortly afterward. macOS bluetoothd logs captured at the exact time of an occurrence confirm that the Bluetooth LE HID link is being disconnected. Hardware Mac: MacBook Pro with Apple M1 Keyboard: NuPhy Kick75 Bluetooth device name: Kick75 IO-2 Connection type: Bluetooth LE HID Regression macOS 26: No Bluetooth disconnections observed during long-term normal use. macOS 27: Random Bluetooth disconnect/reconnect events occur approximately 2–3 times per hour. No keyboard, firmware, physical location, or other hardware/environmental changes were made when the issue started. The behavioral change occurred immediately after upgrading the Mac from macOS 26 to macOS 27. Steps to Reproduce Connect a NuPhy Kick75 keyboard to an M1 MacBook Pro using Bluetooth. Use the keyboard normally for typing. Continue normal use for approximately one hour. At seemingly random intervals, keyboard input suddenly stops. At the same time, the keyboard's Bluetooth connection indicator shows that the Bluetooth link has been lost. macOS automatically reconnects to the keyboard shortly afterward. The same event can be observed in bluetoothd logs as an LE HID link disconnection. Frequency Intermittent but frequent. Approximately 2–3 occurrences per hour after upgrading to macOS 27. Expected Result The Bluetooth LE HID connection should remain stable during normal use, as it did on macOS 26. Actual Result The Bluetooth LE HID connection is unexpectedly terminated. macOS subsequently reconnects to the keyboard automatically. Relevant bluetoothd Log The following was captured during an actual disconnection at: 2026-09-15 17:47:44 Disconnect OI_HCI_LM_HANDLE: 0x55 (85) wakeUp: No RSSI: -37 -37 -37 -37 ... _GATT_LE_DisconnectedCB ... reason STATUS 708 LE Link disconnected ... reason 708 LE ConnManager disconnection complete reason 708 localRole=Central encrypted:1 linkReady:1 disconnectDevice:0 localRole:0 reason:708 result:307 Device disconnected - { devicename: Kick75 IO-2, result: 307 } App disconnected - { bundle: com.apple.BTLEServer, reconnecting: Y } macLeDeviceDisconnected: LE Connection disconnected. Device is a LE HID. BLE Disconnected Unspecified reason 708 Setting LeDevice to Compatible HID from Compatible HID The RSSI values immediately before the disconnection remained consistently around -37 dBm, indicating a very strong Bluetooth signal at the time the link was lost. The following fields appear consistently relevant to this event: reason:708 result:307 disconnectDevice:0 reconnecting:Y macOS also classified the keyboard as a Compatible HID. Related Community Reports This may not be isolated to the Kick75. There is an independent community report involving a NuPhy Air75 V3 on macOS 27 that describes very similar Bluetooth LE HID disconnections. That report has several notable similarities: The Air75 V3 disconnects repeatedly on macOS 27. The same keyboard reportedly operates normally on Windows and iOS 27. Other Bluetooth devices connected to the affected Mac reportedly remain stable. The reporter's macOS Bluetooth logs contain: Incompatible LE HID HID latency issue detected LE Link disconnected (reason 708) Another user reported the same problem with a NuPhy Air65 V3. NuPhy Support responded that they had adjusted Bluetooth parameters and optimized the Bluetooth connection interval, and offered a test firmware for further investigation. The original reporter later tested the same Air75 V3 over Bluetooth on a Mac running macOS 26 at an Apple Store and reported that it did not disconnect. The reporter also observed that having certain Apple Bluetooth HID devices connected at the same time could affect the frequency of the NuPhy disconnections. The community report is titled: “Air75 V3 randomly disconnects on macOS 27 Developer Beta (works perfectly on Windows & iOS 27)” I am including the link to that report with this feedback as supporting information. Importantly, that report involves different NuPhy hardware and a different Mac, but its LE Link disconnected (reason 708) log message closely matches the reason 708 observed independently on my Kick75. This suggests the issue may affect more than one NuPhy Bluetooth LE HID keyboard model under macOS 27. Summary My own reproducible observations are: Same M1 MacBook Pro Same NuPhy Kick75 Same physical environment Stable Bluetooth operation on macOS 26 Frequent disconnections immediately after upgrading to macOS 27 Approximately 2–3 disconnections per hour Keyboard Bluetooth indicator confirms actual link loss bluetoothd confirms an LE HID disconnection RSSI was approximately -37 dBm immediately before the disconnection macOS records reason 708, result 307, and subsequently attempts to reconnect An independent NuPhy Air75 V3 report on macOS 27 also contains LE Link disconnected (reason 708) Taken together, these observations suggest a possible Bluetooth LE HID compatibility regression introduced in macOS 27. I can provide additional Bluetooth diagnostics, a sysdiagnose, and reproduce the issue with Apple's Bluetooth debug logging profile enabled if required.

I am seeing a reproducible Developer ID code-signing issue on an Apple Silicon Mac running macOS 26.6.2. A Universal macOS app and its Quick Look extension (arm64 + x86_64) are signed with a newly issued Developer ID Application certificate using Hardened Runtime and a secure timestamp. Immediately after signing, all verification succeeds, including: codesign --verify --strict --verbose=4 and architecture-specific verification for both arm64 and x86_64. At this point, codesign reports: valid on disk satisfies its Designated Requirement The expected Developer ID authority chain and TeamIdentifier are present. However, after some time, without modifying the bundle or executable, the exact same Quick Look extension starts failing verification for both architectures: invalid signature (code or signature have been modified) codesign -d then reports: Authority=(unavailable) Info.plist=not bound The executable SHA-256, size, and mtime remain unchanged. I also copied the now-invalid extension to a different directory, creating completely new inodes. The copy remains invalid. I verified that: all regular files in the original and copy are byte-for-byte identical executable SHA-256 is identical _CodeSignature/CodeResources is identical there are no hard links (link count is 1) there are no extended attributes anywhere in the extension com.apple.provenance, com.apple.quarantine, and com.apple.FinderInfo are absent copying the bundle to a new inode does not restore signature validity The affected extension executable currently has: SHA-256: 3b36d1aca258a371311a9c94e93d10606edc184ea120dd252cf230a251c67243 CDHash arm64: 178ff5b7b2cedbed00ec6bc07536d168e22d9ba5 CDHash x86_64: ada914101f5b107704b78958520c904c4f022894 Signing environment Developer ID Team ID: XY2B8MLPV8 The Developer ID Application certificate is newly issued with a new RSA 2048-bit private key. I have also observed the following message in the Security log during signing: CSSMERR_CSP_INVALID_KEYATTR_MASK No new occurrence of that error is logged when subsequently verifying the already-invalid extension. Troubleshooting already performed I have: issued a completely new Developer ID Application certificate with a new RSA 2048-bit private key verified the certificate chain and code-signing policy successfully reproduced related Keychain/identity problems in a fresh macOS user account tested with a newly created independent Keychain tested in Safe Mode reinstalled macOS without erasing user data Before reinstalling macOS, even security find-identity -v -p codesigning eventually failed to recognize otherwise valid Developer ID identities. After reinstalling macOS, security find-identity -v -p codesigning correctly reports all identities again. I then performed a durability test using the new Developer ID identity on a minimal Universal Mach-O binary. Verification succeeded: immediately after signing after approximately 2 minutes after approximately 5 minutes after copying the binary to a different directory The minimal binary remained valid throughout. However, the problem subsequently reproduced with the actual Quick Look extension. Notarization The application was packaged in a Developer ID Installer-signed PKG and submitted to Apple Notary Service. The submission was Accepted, stapling and validation succeeded, and Gatekeeper accepted the notarized PKG. Notarization submission ID: 54dc0de7-5089-4b8c-9c10-b5a74df8df97 I initially suspected the packaging process, but I subsequently found that the original pre-PKG Quick Look extension itself had become invalid. Therefore, this does not appear to be caused by PKG creation or extraction. Questions What could cause a Developer ID signature that initially verifies successfully to become invalid later when the signed files themselves have not changed? Is there a Security.framework / codesign diagnostic that can show exactly which part of the CMS signature or CodeDirectory validation is failing? Are there any known macOS 26.x issues involving code-signing validation or CSSMERR_CSP_INVALID_KEYATTR_MASK that could explain this behavior? I would be happy to collect additional Security logs, codesign diagnostics, or a sysdiagnose if that would help identify the cause.

Hello, I recently submitted an enhancement request through Feedback Assistant requesting official native macOS support for Genshin Impact. Feedback ID: FB25106712 I am an Apple Developer Beta tester, a Mac user, and a passionate gamer. I regularly test macOS developer beta releases and provide feedback on performance, stability, compatibility, and the overall system experience. I also genuinely enjoy testing games on Mac and seeing what Apple Silicon is capable of. I have personally tested games such as Wuthering Waves, Cyberpunk 2077, and Minecraft on Mac, and my experience with them has been extremely positive. Wuthering Waves in particular runs very smoothly and seamlessly on my Mac. These experiences have made me feel that the capability for excellent gaming on Apple Silicon is already there. The larger limitation, in my experience, is the availability of native support. As a major HoYoverse fan, Genshin Impact is one of the games I would most like to experience and test natively on macOS. At present, Mac users have to rely on third-party workarounds such as PlayCover, compatibility solutions, or cloud gaming rather than having an officially supported native client. I would really like to see Apple work with HoYoverse to bring Genshin Impact natively to macOS, properly optimized for Apple Silicon and Metal. I would also be very happy to test such a release across macOS versions and provide detailed feedback on performance, graphics, stability, thermals, controller support, and the overall gaming experience. Could this enhancement request be brought to the attention of the appropriate Apple team, or is there an appropriate channel through which I can provide further feedback regarding this request? Thank you for your time.

So my timeline is this: Got MBP 16' in March with graphics options: AMD Radeon Pro 5500M 4 GB Intel UHD Graphics 630 1536 MB Up until 10.15.5 came out, I had zero problems/crashes and I always have the laptop closed and an external display connected with an official Apple A/V adapter using HDMI. As soon as I installed 10.15.5 the panics started happening. Reason:&#9;&#9;&#9;&#9;&#9; (1 monitored services unresponsive): checkin with service: WindowServer returned not alive with context: unresponsive work processor(s): WindowServer main thread&#9;40 seconds since last successful checkin Literally after the update ended, I didn't touch the laptop for some time, the external monitor went to sleep and the laptop panic'ed and rebooted. I installed apps like Caffeine to prevent the external monitor from going to sleep and managed to continue working. Some days after this the crashes started happening even when the monitor was not going to sleep. Usually when using apps that put some strain on the video such as video conferencing apps. These crashes started to become more frequent. The display froze, for about 2 minutes, the laptop started getting very warm and the fans would not go faster, then after 2 minutes the fans go into turbo mode for about 1 second and the laptop reboots. After this I reverted to 10.15.4 and reset SMC, etc, and the panics when the display goes to sleep are gone, but the crashes when I'm using the computer continue. I tried ditching the adapter and using a usb-c displayport cable but the problem remained. As a final test, I unplugged everything from the laptop and disabled "automatic graphics switching" to force the AMD to be used even with no external display. Sure enough, I was able to reproduce the issue. So it seems not related to an external display, but the AMD card itself (which is always used when an external display is connected). Sad times.

We have started seeing some unexplained behavioural differences in the BSD socket APIs on macos 26.6.x and macos 27. On a different front, there also seems to be some changes in the ptrace area for PT_DETACH. Historically, the release notes of macos don't include any mention of such changes. And unfortunately, prior experience of filing feedback assistant issues too hasn't been very motivating due to lack of any response on those tickets. These forums have been very helpful in trying to understand some of these changes, and I plan to raise separate topics for the issues shortly. In the past, the other useful option I have used is reading up the kernel sources published at https://opensource.apple.com/releases/. But there hasn't been any updates for macos 26.6 or macos 27. It will be very useful if macos 26.6 and 27 releases are published there. That will help expedite investigating some of these failures. BSD socket APIs in the recent releases of macos have seen several issues (feedback assistant issues have been filed). The implications of these failures is that we (in OpenJDK) have had to disable several tests on recent versions of macos which has reduced the test coverage and reliability of these very primitive networking APIs on this platform.

Hi. After the recent update of Ventura to 13.4 and Big Sur to 11.7.7 all of a sudden "launchctl setenv" returns the following errors. Could not set environment: 150: Operation not permitted while System Integrity Protection is engaged Is there any workaround to fix this?

Environment: macOS 26.6.2 (25G83), Apple silicon Xcode 26.6 (17F113) DriverKit SDK 25.5 I am implementing a DriverKit IOService with an IOUserClient. This is a lifecycle and object-ownership question independent of the device protocol. The intended design admits at most one user client during a provider lifetime. Lifecycle methods run on the provider’s default queue, while IOUserClient ExternalMethod requests run on a separate serial IODispatchQueue. At most one device request may be in flight. The shutdown invariant we need is: Stop accepting new requests. Allow every accepted request to complete exactly once, or cancel it. Observe completion of the operation queue’s cancellation handler. Call the inherited Stop implementation last. Perform no provider access afterward. The relevant public documentation is: IOService::Stop: https://developer.apple.com/documentation/driverkit/ioservice/stop IODispatchQueue::Cancel: https://developer.apple.com/documentation/driverkit/iodispatchqueue/cancel IOService::SetDispatchQueue: https://developer.apple.com/documentation/driverkit/ioservice/setdispatchqueue For the normal path, the proposed sequence is conceptually: Stop(provider): close request admission operationQueue->Cancel(cancellationHandler) wait for the cancellation handler from the separate queue super::Stop(provider) I need clarification of the complete supported public API contract: If IODispatchQueue::Cancel returns a non-success result, is its cancellation handler still guaranteed to execute? If it is not, what supported action lets Stop keep the provider and user client valid until previously accepted work is no longer capable of accessing them? Is it supported for the provider and its one user client to share the provider-owned serial operation queue? If the IOUserClient stops independently, must it own and cancel a separate queue, or is there a supported per-client drain mechanism that does not cancel provider-owned work? Is the driver’s public IOService::Stop override guaranteed to run on every termination path where accepted user-client work must be drained, including when the provider is already inactive or the DriverKit server has slept? If not, which public lifecycle callback supplies that drain point? Is blocking the provider’s default queue inside Stop while awaiting the cancellation handler from a separate operation queue the supported interpretation of “wait for your cancellation handlers”? If not, what public continuation mechanism should be used before calling inherited Stop? We also observed one power-management panic after sleep/wake: HiMDScsiDriver::setPowerState(..., 0 -> 4) timed out after 20342 ms The DEXT does not currently override SetPowerState. This panic motivates the lifecycle review, but I am not treating it as proof that the Stop/drain design caused the timeout. I am looking specifically for a supported public DriverKit sequence. I do not want to rely on private framework entry points or infer object-lifetime guarantees from a successful build or experiment.