Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Hello developers! Thank you for your dedication to creating apps with great performance. We’re excited to kick off another year of partnering with you on improving power and performance in your apps. At WWDC26, check out the following new things in the latest platform SDKs and Xcode 27 beta for performance. You can also join us online for a Power and Performance Group Lab on Tuesday, June 9 at 11 AM Pacific. Meet State Reporting and the new MetricKit State reporting: The new StateReporting framework lets your application express its state to downstream tools like Instruments and MetricKit. Make your telemetry and traces much more useful by adopting this simple API. MetricKit: In the 27 releases, the Swift-first MetricManager API replaces the MXMetricManager API. Combined with State Reporting, the new MetricKit provides more granular metrics to isolate performance problems faster. It also provides a more expressive API that is great to use in Swift, with improved Swift concurrency and Codable support. With this year’s releases, the MXMetricManager API is considered legacy. ▶️ To learn more, watch Meet the new MetricKit. Discover new features in Xcode organizer Metric goals: Xcode organizer now provides a goal metric for Battery Usage, Disk Writes, Hang Rate, Hitches, Memory, and Storage metrics, allowing you to prioritize performance engineering across more areas. Generate recommendations: Quickly resolve the highest impact performance issues in your app by using Generate Recommendations for Crash, Energy, Disk Write, Hang and Launch diagnostics. Insights overview: The new insights overview in Xcode organizer summarizes high-impact performance regressions for metrics and diagnostic reports, helping you plan and prioritize performance engineering work. Storage metrics: Storage metrics are now available in Xcode organizer, allowing you to monitor your app's Documents & Data and App Size across releases and catch regressions in cache usage and bundle size. Hitches metric: The new Hitches metric replaces the Scrolling metric in the organizer and now displays hitches for all animations in your app, giving you a comprehensive view of animation performance. ▶️ To learn more about other advancements in Xcode, watch What’s new in Xcode 27. Improve app responsiveness with Instruments Foundation Models: The Foundation Models instrument is redesigned with a tree view that lets you drill into individual requests, inspecting tool call arguments and results, inference prompts and responses, and token statistics. Use it to understand caching behavior, measure latency, and optimize throughput. System Trace: System calls, VM faults, and thread states are now unified into a single plot, with a new blending algorithm that stays readable even at high density. Once you spot something worth investigating, left/right key navigation lets you follow a thread's activity step by step, and the inspector provides quick actions like pinning the thread that made another thread runnable. System Trace now also draws thread priority and QoS over time, making it easier to identify priority inversions and unexpected QoS degradations that affect responsiveness. Swift Concurrency: New Main Actor and Global Concurrent Executor tracks let you visualize running tasks and executor queue depth over time, making it easier to spot task scheduling delays and actor contention. Tasks are now grouped into collections for faster navigation. Swift Tasks, Actors, and Executors instruments can now surface Call Trees, Flame Graphs, and Top Functions scoped to each entity — so you can pinpoint exactly where concurrency overhead lives. Top Functions: Helper functions and runtime internals can be expensive but hard to spot in a standard call tree. The new aggregation mode in Top Functions surfaces any function's total execution time across the entire call stack, making it easy to identify and prioritize hidden hotspots. Run Comparison: Compare call tree data across builds to identify regressions and performance wins. Results can be explored as an outline, flame graph, or top functions — choose whichever view best fits your workflow. ▶️ To learn more about profiling your app with Instruments, watch “Profile, fix, and verify: Improve app responsiveness with Instruments” ▶️ To learn about Foundation Models optimization, watch “Debug and profile agentic app experiences with Instruments”. If you have any questions about using State Reporting or the new MetricKit, create a post on the forums. For help creating a post, see Tips on writing a forum posts.

When I use my iPhone to scan the apple pay QR code in chrome, the url is https://applepaydemo.apple.com/apple-pay-js-api, I keep geting the "Service Unavailable" error. Wonder know if you guys meet this error as well? Btw, the QR code feature needs IOS 18.

My share extension accepts a shared location and I want to bring the user into the containing app at the corresponding map screen. I understandNSExtensionContext.open(_:completionHandler:) is restricted to Today widgets per the App Extension Programming Guide, and I observe it reporting success == false. The technique I am asking about is different: walking the extension's responder chain to obtain the UIApplication instance, then calling open(_:options:completionHandler:) on it. In a minimal sample this launches the containing app and the completion handler reports success == true, on both iOS 26 and iOS 27. What makes this worth asking rather than assuming: It never references UIApplication.shared, which is annotated NS_EXTENSION_UNAVAILABLE_IOS. open(_:options:completionHandler:) itself carries no extension-unavailable annotation in the SDK, so the call compiles cleanly even with APPLICATION_EXTENSION_API_ONLY = YES. I am aware of https://developer.apple.com/forums/thread/773342, where an Apple Frameworks Engineer wrote that "There's no supported way for you to launch your app directly from App Extensions, except Today and Widgets." That thread does not cover the responder chain specifically, which is why I am asking. My questions: a) Is this permitted? Is obtaining UIApplication via the responder chain from a Share Extension and calling open(_:options:completionHandler:) considered a violation of App Store Review Guideline 2.5.1 (public APIs used as intended), independent of whether it currently functions? b) If it is not permitted, what is the recommended way for a Share Extension to hand a location to its containing app such that the user arrives at the relevant screen? The code in question, in its entirety: @objc private func openUsingResponderChain() { var responder: UIResponder? = self while let currentResponder = responder { if let application = currentResponder as? UIApplication { application.open(targetURL, options: [:]) { [weak self] success in self?.report("UIApplication via responder chain -> success = \(success)") } return } responder = currentResponder.next } report("No UIApplication found in the responder chain") } Full sample project: https://github.com/valtermak-voya/share-extension-open-url-repro A containing app registering opensample:// plus a share extension target built with APPLICATION_EXTENSION_API_ONLY = YES. The method above is the whole of the extension's logic. Filed with DTS as Case-ID 22452440.

We are designing a bounded local macOS operation with a supervisor, controller and helper. All three must be unable to cause prohibited network effects, including attributable delegated requests, before admission and until quiescence. Unrelated applications must retain their normal network access. We are seeking an API contract clarification, not reporting a reproduced OS bug. No NetworkExtension provider has been activated for this design. Our reviewed SDK is MacOSX27.0.sdk; its presence is not a runtime qualification. Please identify the supported macOS versions for your answer. The design must tolerate provider crash, termination, disconnection and unresponsiveness, and operation lease expiry/revocation. Administrative filter disablement or privileged reconfiguration is a separate unresolved threat-model case, not something we assume ordinary failure handling covers. We reviewed content-filter deployment in TN3134 and the nullable/delegated audit tokens in NEFilterFlow. We understand that NEURLFilterManager.shouldFailClosed concerns URL-filter decisions, not an established guarantee for arbitrary content-filter traffic. EndpointSecurity AUTH deadlines are also a separate mechanism. The VPN routing article documents dropping during specific transitions, but has system exceptions; TN3120 excludes using a packet tunnel as a dropping content filter. We therefore have not adopted that workaround. For macOS NEFilterDataProvider / NEFilterPacketProvider, is there a supported configuration that keeps prohibited operation traffic denied when the provider crashes, is killed, disconnects, hangs or cannot deliver a decision? Please distinguish new flows, existing/previously permitted flows, queued data, restart intervals, and configuration disable/removal. What supported admission and teardown guarantees allow releasing the first protected process only after enforcement is effective, then retaining denial through lease revocation and shutdown? An enabled configuration alone would not demonstrate that barrier. How should this guarantee cover operation-caused DNS and delegated system-service traffic, including absent/ambiguous audit tokens, without denying unrelated host traffic? If content filters cannot meet that scope, can App Sandbox without network entitlements provide the independent denial boundary for these roles, and what documented exclusions or additional constraints apply? A reference to the supported contract, or a precise statement of the requirement that needs to change, would let us select an architecture before implementing and activating a native provider. We are not requesting private APIs or an unsupported packet-tunnel filter.

macOS 26.6, 26.7, 27.0 and 27.2 beta 1/2. Reproduced with Apple's SimpleURLFilter sample ("Filtering traffic by URL", WWDC25 session 234), built and run as a macOS app. The sample never sets localizedDescription, so I added one line to ConfigurationModel.save(configuration:) before saveToPreferences(): sharedFilterManager.localizedDescription = "Sentinel Filter Name" The property holds the value in memory: after loadFromPreferences(), the logged LocalizedStringResource still has key: "Sentinel Filter Name". But the effective configuration the system starts the session with has no localizedDescription — the session is named after the app: name = SimpleURLFilter applicationName = SimpleURLFilter application = com.example.apple-samplecode.SimpleURLFilterTC3Q7MAJXF (the rest of the nesessionmanager dump is the urlFilter dictionary, and it has no localizedDescription key). System Settings > Network > Filters shows the filter as URLFilter, not "Sentinel Filter Name". The stored configuration (/Library/Preferences/com.apple.networkextension.plist) has no localizedDescription key either, and injecting one by hand does not survive a nesessionmanager restart. Re-saving, removing and re-creating the configuration, and rebooting the Mac do not change the displayed name. Expected: the docs describe localizedDescription as "A string containing a description of the URL filter", and WWDC25 session 234's code sample ("Configure and manage URL Filter") sets it this way (manager.localizedDescription = "Alice's URL Filter"). For comparison, a NETransparentProxyManager configuration on the same Mac persists localizedDescription as the configuration's Name in the same plist, while the URL filter configuration has no such field. Filed as FB24987420.

Hi, we have a bug report in Cholesky implementation of Accelerate on the LAPACK GitHub. See: https://github.com/Reference-LAPACK/lapack/issues/1408 This is to let you know. This might be a user error but I thought I'd let you know. I did not try out for myself. Julien.

On macOS 27.2 beta 1/2 our URL filter never starts: the session loops starting -> stopping. The same build works on macOS 27.0 (26A428). Both our TestFlight and notarized standalone builds fail. Prefilter and PIR registration succeed. The PIR status request then fails: NWPath is satisfied, the connection is configured proxy fail closed, proxy strict fail closed, the proxy fails (event: proxy:children_failed), and the error is NSURLErrorDomain -1009 / POSIX 50 "Network is down" with _NSURLErrorPrivacyProxyFailureKey=true. NEMembershipCheckerErrorDomain Code=3 -> NEAgentURLFilterErrorDomain Code=3; the app sees serverSetupIncomplete. The privacy-proxy allow-list entry is identical on macOS 27.0 and 27.2 beta (com.adguard). Disabling the VPN, rebooting, and recreating the URL filter configuration do not help. Log excerpt: neagent: updatePrefilterWithCompletionHandler - result 1 neagent: <NEPIRChecker> - Register with PIR Server (group <com.adguard.safari.AdGuard> ... PrivacyProxyFailOpen <0> ...) -> completed registration ciphermld: [C3 ...] proxy fail closed, proxy strict fail closed ciphermld: [C3.1.1 ... failed proxy (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, flow divert agg: 2, LQM: good)] event: proxy:children_failed ciphermld: queryStatus: NSURLErrorDomain -1009 / POSIX 50 "Network is down", _NSURLErrorPrivacyProxyFailureKey=true, NWPath=satisfied neagent: Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> nesessionmanager: NEURLFilterPlugin(com.adguard.safari.AdGuard[url-filter][inactive]): setStatus:error: - err Error Domain=NEAgentURLFilterErrorDomain Code=3 Filed as FB24933164.

Short version: we run a sandboxed helper as a hidden service account, started at boot by an SMAppService daemon. It works, even before login. But when the user turns our app off in Background App Activity, only the daemon stops. The helper keeps running. Is this setup supported, and what's the right way to manage the helper? What we want A Developer ID signed, notarized app (not Mac App Store) with a helper that parses untrusted input. The helper should: run as a dedicated, hidden, non-login local account; use App Sandbox, with its own container; be available before anyone logs in (after FileVault unlock). What we built An unsandboxed root LaunchDaemon, registered with SMAppService.daemon, runs this at boot: launchctl bootstrap user/<serviceUID> <fixed-agent-plist> The agent plist uses LimitLoadToSessionType=Background. The helper is a nested app in the same bundle, with com.apple.security.app-sandbox=true. We don't create a GUI session, change UID after the sandbox starts, or use private APIs. What we measured macOS 27.0 (26A428), arm64, dummy data only: Register and approve: the daemon starts. The helper starts as UID 60000, its container works, and reads outside it are denied. Turn the app off in Background App Activity: the daemon gets SIGTERM and stops. The helper keeps running (same PID). Turn it back on: the daemon starts again. Its bootstrap returns exit 5, because the old helper is still loaded. Call unregister(): the daemon stops. The helper keeps running. Cold boot (tested with a plain /Library/LaunchDaemons job, not yet SMAppService): the helper started and worked before login finished. For comparison, running the same sandboxed helper as a system daemon with UserName set to this account fails before main: Incoming message euid:60000 does not match secinitd uid:0. Questions Is this setup supported for shipping, including the sandbox starting before anyone logs in? Does the approval for daemon-bundled helpers cover a helper bootstrapped into another account's domain? Our plan: when the daemon gets SIGTERM, it runs bootout on the helper and its domain, and it treats bootstrap exit 5 as "already loaded". Is that the intended pattern, or is there a supported way for the helper to follow the app's Background App Activity setting? If this setup isn't supported, what public mechanism gives a sandboxed helper its own non-root identity before login? I can share the plists, entitlements and logs from a minimal reproducer.

Hi all, we are building a custom controller for ATDECC, which is a layer 2 protocol standardized by IEEE in 1722.1. Our controller can work on multiple network interfaces at the same time . It uses the interface's MAC address to identify, on which interface a certain AVB / ATDECC device was discovered. It then sends replies for this device only to this interface. This controller worked fine up to and including macOS 26, but when running the same code on macOS 27, we cannot get the MAC addresses for the local interfaces anymore, but we receive 02:00:00:00:00:00 for each of them. This seems to indicate that the MAC address was redacted (looks like the same MAC address, that is being returned since iOS 11 due to privacy reason). Is this a bug or is macOS going to redact the MAC addresses also in the final release? If MAC addresses are being redacted, would it help to request access to the new entitlement called com.apple.developer.networking.topology-observation? I attached a little code snippet, that returns actual MAC addresses on macOS 26, but redacted ones on macOS 27. Build with clang++ -std=c++23 -o ifprobe ifprobe.cpp and then run it with ./ifprobe. ifprobe.cpp

macOS guest (Virtualization.framework) freezes with all vCPUs halted right after a macOS update reboot - 3/3 on a macOS 26.7.1 (25G309) M4 host, seen with both UTM and Parallels Summary On a macOS 26.7.1 (25G309, beta/seed build) host with an Apple M4, every macOS guest that runs an in-place macOS update freezes at the same point: the in-OS phase of the update completes and reports success, the guest requests a reboot, records a shutdown stall 9 seconds later, reboots twice, shows the update progress screen for about a minute, and then stops. All four vCPUs enter WFI and never wake, paravirtualized graphics stops submitting, no I/O is pending on the host side, and no host service logs an error. The VM never recovers and has to be killed. Reproduced 3 out of 3 times, under two different front-ends (UTM and Parallels Desktop) and two guest versions (15.7.x and 26.6.2). Environment Host: iMac (Mac16,3), Apple M4, 16 GB RAM, macOS 26.7.1 build 25G309 (seed channel), installed the evening before the first failure. Primary guest: macOS 15.7.9 (24G830), hardware model VirtualMac2,1, 4 vCPUs, 6 GB RAM, 90 GB raw disk image (virtio-blk) stored on an external USB SSD. Networking bridged to the built-in Ethernet port. Devices enabled: memory balloon, audio, entropy, clipboard sharing; display 1920x1200 with dynamic resolution. Front-end for the primary case: UTM [version], Apple Virtualization backend. Guest was the only VM running, cold-booted, window open. Update being applied: MSU_UPDATE_24H23_patch_15.8_minor (15.7.9 -> 15.8). Other cases: a macOS 26.6.2 guest under UTM; a macOS 15.7.7 -> 15.8 guest under Parallels Desktop 26.4.2 (57518). Steps to reproduce Cold-boot a macOS 15.7.9 guest under Virtualization.framework, as the only VM on the host. In the guest: System Settings > Software Update > install macOS 15.8. Let it reboot. Expected The guest installs the update and boots into 15.8. Actual — timeline of the primary case (R = the moment Software Update requested the reboot; absolute timestamps are in the attached logs) R-23 min to R-5 min: UpdateBrainService prepares the update inside the guest, writing about 25 GB (two "disk writes" resource reports: 16.5 GB then 8.5 GB). No errors. R-1:56: post-logout install configured; disk space check passes (5.7 GB required, 40.7 GB free). R-1:44: "SUOSUPostLogoutInstallOperation: Applying MSU update". R: "Applied MSU update"; FileVault stash committed ("kAppleFDEKeyStore_commitStash success"); "Rebooting (success = 1, displayAsleep = 0, shutdown = 0)". This is the last line the guest ever writes to install.log. R+9 s: the guest writes a shutdown_stall diagnostic report. R+10 s: host sees ParavirtualizedGraphics "Device reset" / "PGDisplayNub[0]: Destroyed" (reboot #1). R+1:20: second device reset (reboot #2), 70 s after the first. On the host, the vmnet interface is torn down and recreated with no error, the AppleVirtualPlatformIdentity service completes boot attestation with no error, and the guest's graphics driver renegotiates ("Guest requested binary version: 209"). R+1:38: host logs "PGDisplay[0]: Change display mode to 3606x2254" — the guest is on the update progress screen. R+1:41 to R+2:25: the guest's six PGFifoThreads go idle one at a time. The progress bar stops partway. No further activity of any kind. R+11:35: spindump of the VM host process (com.apple.Virtualization.VirtualMachine): 0.042 s of CPU over a 5 s sample all four com.apple.virtualization.thread.cpu-N threads in Hv::Vcpu::run() -> HvCore::Hypervisor::VcpuStateManager::wait_for_interrupt() -> __psynch_cvwait cpu-0/cpu-1 wake on a ~20 ms timer tick and return to WFI; cpu-2/cpu-3 had not run for seconds no thread in any file read, write or fsync (no host I/O outstanding) PGFifoThreads last ran 550–614 s earlier process state Ss (sleeping), not U Host kernel log for the window: no USB, APFS, I/O error, timeout or reset entries. No hardware video decoder (AppleAVD) errors. The VM was left for over an hour with no change, then killed. Second case (same host, same day, UTM, guest macOS 26.6.2) Identical signature: two graphics device resets 69 s apart, display mode set 3 s after the second one, last graphics activity about a second later, then all vCPUs idle in WFI for ~6.5 hours until the VM was killed. Third case (same host, same day, Parallels Desktop 26.4.2, guest 15.7.7 -> 15.8) The guest was suspended in the middle of its update and resumed later. On resume ("-[_PGDevice willResumeWithSuspendState:error:]: Begin resume", preceded by "[VirtualMachineParameterBuilder] Failed to get auxiliary file identifier"), paravirtualized graphics never came back — its FIFO threads ran once and never again — and the guest's vCPUs sat in WFI. This may be a separate save/restore defect, but the end state is the same. What I believe is ruled out The in-OS phase of the update: it completed and reported success. Guest kernel panic: vCPUs are halted, not spinning, and there is no panic report on the guest's data volume. Disk space: 40.7 GB free in the guest at install time. Host storage stall: no uninterruptible wait, no I/O frames in the spindump, no kernel storage errors. Host hardware video decoder: no AppleAVD errors in the primary case. Host services: vmnet and AppleVirtualPlatformIdentity completed normally seconds before the hang. Guest memory: 6 GB allocated. Not yet isolated The VM images live on an external USB SSD; not yet reproduced from internal storage. The memory balloon, audio and clipboard-sharing devices were enabled; not yet reproduced with them disabled. A third-party VPN client was running on the host (guest networking is bridged, so guest traffic bypasses the host tunnel, but host firewall rules could still affect bridged frames). I don't have a confirmed-good in-place guest update on this machine from before 26.7.1, so I can't state with certainty that this is a regression. Frequency 3 of 3 attempts on this host. Attachments / available on request spindumps of the hung VM host process (primary case and second case) host unified-log excerpts for both hang windows the guest's full install.log the guest's shutdown_stall report and the two UpdateBrainService disk-writes reports sysdiagnose captured while hung, if obtained Has anyone seen macOS guests stop at this point on the 26.7.x seeds? If you can reproduce, your host build, hypervisor, and whether the VM image is on internal or external storage would be useful to compare.

We ship a ~6.2 GB Apple-hosted managed asset pack and request it with AssetPackManager.ensureLocalAvailability(of:). If the app goes to the background even once while the download runs, the transfer continues to the end and then fails with ManagedBackgroundAssetsProcessingPipeline.Dispatcher.PipelineNotFound. The system discards the resume data, and the next attempt starts again from byte 0. What the sysdiagnose shows: On backgrounding, backgroundassets.user logs allows BG activity, pausing any foreground downloads for background demotion and hands the download to nsurlsessiond. On return it logs re-promoted 1 previously-demoted foreground downloads. Each handoff moves the stream to another STExtractionService.privileged instance, which logs No processing pipeline with the ID "…" was found; defaulting to an extraction memory footprint of 50 MB. When the HTTP response ends: [Relay] No endpoint was found for the key "…" (fault) → The stream couldn't be finished: No processing pipeline with the ID "…" was found → Removing the resumption info → the download fails. This happened on every app-requested download that was backgrounded at least once. One run reached 100 % in the foreground and still failed. The only download that ever completed was the system's own prefetch download, which ran entirely in the background with the app never launched. Over one afternoon about 46 GB were downloaded for a single 6.2 GB pack. Questions: Is this a known issue with the demotion/promotion of foreground asset-pack downloads? Is AssetPack.download(for: nil) plus BADownloadManager.scheduleDownload(_:) a supported way to request a managed pack from the app, so the download never gets foreground priority? We're testing it now. Is there any other way to keep a download requested from a foreground app from being demoted? Filed as FB24888599.

(lldb) p [@"ΗΙzzz" caseInsensitiveCompare:@"ᾚabc"] (long long) -1 (lldb) p [@"ᾚabc" caseInsensitiveCompare:@"ΗΙzzz"] (long long) -1 Note the unicode char in the second string. The results can't be both -1, afaik, if one is -1 the other one should be +1. This causes inconsistent indexing in a sorted array resulting in obscure crashes of my app. Am I doing something wrong? Tested on iOS 27 and macOS 26.6.

I have an app that I am implementing background assets, using self hosted unmanaged. Everything compiles fine, and I get no errors. But I can't figure out how to trigger the 'install' phase into the extension. I have tried copying the app into /Applications without luck. I have deleted the entire DerivedData and all copies of the application. Nothing seems to work. I tried using the Apple provided sample app from here and got the same results. I don't understand why the CLI tool backgroundassets-debug only works with iOS based connected devices? Please let me know how can I test my BADownloaderExtension on Mac via XCode. Thank you.

I am a PSP for Apple Pay, and I have been experiencing timeouts while registering a domain for my merchant. What configurations should my merchant make?

Subject: Virtualization.framework VM execution ownership and crash reclamation on Intel macOS Monterey Hello, I’m investigating the lifecycle guarantees of Virtualization.framework on Intel macOS Monterey 12.7.x. The specific scenario is a VZVirtualMachine running a Linux guest. I need to understand the ownership and reclamation behavior when the process holding the VZVirtualMachine is abruptly terminated without calling stop() or performing normal cleanup. The key questions are: For a specific VZVirtualMachine on Intel macOS Monterey, which userspace task/process actually owns the Hypervisor VM and the vCPU threads backing guest execution? Is Hypervisor execution owned directly by the calling process, or by a separate process such as: com.apple.Virtualization.VirtualMachine or another Virtualization.framework backend? If the process holding the VZVirtualMachine is terminated with SIGKILL or crashes without executing cleanup code, is the underlying guest execution context necessarily destroyed? More specifically: Can guest vCPU execution continue after the client process has died? If a separate backend process owns the VM, is that backend guaranteed to terminate or destroy the VM when the client dies? Does this behavior apply to Intel macOS Monterey 12.7.x, or only to newer macOS releases? Is there a supported diagnostic on Monterey that can map one specific VZVirtualMachine instance to the task/process that actually owns its Hypervisor VM/vCPU execution? For example, would a diagnostic showing Hypervisor execution frames such as hv_vcpu_run in a process, combined with a reliable process-exit notification, be sufficient to establish that ownership relationship? If the Virtualization backend can survive the client process, what supported VM-specific recovery or termination mechanism is available to another process? The security property I need to establish is intentionally narrow: If the userspace owner of a VM is abruptly destroyed, guest computation must not be able to continue indefinitely as an independent execution domain. Persistent disk files or other inert VM artifacts are not the concern; the question is specifically about live guest/vCPU execution and its ownership lifecycle. I’m looking for the supported architectural contract or diagnostic approach, not undocumented implementation details. Target environment: macOS Monterey 12.7.x Intel x86_64 Virtualization.framework Hypervisor.framework Hardware virtualization available No private APIs or privileged/kernel extensions Thank you.

Hi, I’m seeing a CloudKit Production sync failure in an iOS app using SwiftData/Core Data with private CloudKit mirroring. Sync worked correctly after release, then stopped working without any new app build being released. Device logs show: CKInternalErrorDomain Code=1011 and Core Data reports that CloudKit mirroring was never successfully initialized. CloudKit Production logs also show a native PRIVATE database request failing with: USER_ERROR / BAD_REQUEST involving the internal record type: _pcs_data The Production schema, private zone, and subscription are still present. I have not reset Production or deleted any zones/subscriptions. I have already filed a Feedback Assistant report with diagnostics. Has anyone seen this pattern before? Is there a safe developer-side remediation, or is this typically an Apple-side CloudKit/PCS issue? I want to avoid any destructive action that could risk existing user data.

Apple's Location Services & Privacy notice (https://www.apple.com/legal/privacy/data/en/location-services/) describes per-app sharing of Visited Places and Preferred Routes/Predicted Destinations where available. We are investigating a transit companion with a watchOS app and an optional iPhone companion. We have checked public developer documentation and installed SDK interfaces but have not identified the API that delivers these shared records. Which public SDK interface, entitlement or enrollment process implements this capability for third-party apps? A documentation or sample link, with supported platforms and eligibility requirements, would let us build a minimal probe. We are asking about delivery of the shared records, rather than monitoring new visits with Core Location or supplying relevance hints to the system.

There have been 2 serious regressions in the hypervisor framework since developer beta 6 of macOS 27 that have continued into the final release, and the first beta of 27.2 The first is that since developer beta 6 of macOS 27, virtual machines that have an Apple ID with iCloud+ signed in fail to route traffic in Safari through iCloud Private Relay despite it being on. Parallels, UTM, VirtualBuddy have all been tested and the issue applies to all of them, exposing the host machine's IP address. I have reported the issue since I discovered it and there hasn't been any communication that Apple even knows its an issue to my open report in Feedback Assistant. The second issue is a newer one, and it affects macOS 26.6.2 and earlier virtual machines. Attempting to install 26.7 through the built-in software update causes the virtual machine to black screen upon reboot during the installation. Forcing the machine off and back on causes the virtual machine to revert back to macOS 26.6.2. There has been no available IPSW file to test if a clean install of 26.7 in a virtual machine is a viable workaround, or to see if there is a bug in the updating mechanism or bug in the 26.7 release itself in virtual machines. The Parallels Desktop forum is beginning to get reports from users of that software of the same black screen issue trying to update their own 26.6.2 VMs to 26.7. These issues have also not been corrected in either 27.2 Beta 1 nor 26.7.1 Has anyone found a workaround to either of these 2 issues, or submitted similar reports and got any kind of response from Apple? The feedback reports about these issues are FB24828992 and FB24791716

We have a group of Macs that mount SMB shares over 10 GbE with jumbo frames (MTU 9000). Since late June, they have been kernel panicking several times a day with the same assertion: panic(cpu N caller ...): assertion failed: m->m_flags & M_PKTHDR, file: .../xnu/bsd/kern/uipc_mbuf.c, line: 4839 @uipc_socket.c:8260 Panicked thread: dlil_input_en0 Last started kext: com.apple.filesystems.smbfs 6.0.1 Environment Clients: Mac Studio (M1 Max and M1 Ultra) and Mac Pro (2019, Intel with T2), using the built-in 10GBASE-T at MTU 9000 macOS 26.5.1 (25F80), 26.6.2 (25G83) and 26.7 (25G229); it panics on all three Servers: Samba-based NAS, SMB 3.1.1, signing on, encryption off Filed as FB24912731 What we've found It still panics with our third-party EDR fully uninstalled. The Mac that panics needs an active SMB session. A Mac left on the network without a share mounted stayed up through several events that took down the others. Panics are often simultaneous across machines: two to six Macs, with different hardware and different macOS builds, within the same minute. It doesn't need sustained heavy throughput. Some panics came within minutes of reconnecting, during light editing. Setting kern.skywalk.flowswitch.rx_agg_tcp_host=0 did not help. The switch and server links stay up, and spanning tree doesn't change during these events. Only the Macs' ports drop. In one server-side capture, the client stopped sending within about 0.2 ms of receiving a READ response made of 8948-byte frames. That fits the panicked thread being dlil_input. Two existing threads look related Kernel panic using Vagrant synced folders via NFS beginning with macOS 15.4 (FB17853906). A DTS reply there said the issue is in kernel mbuf management and that SMB "is very likely to experience a similar panic." Incorrect packet handling in SMBClient MacOS 26, which describes a race in SMBClient under heavy load above about 10 Gbps. Questions Is this the same underlying issue as FB17853906, and is a fix planned for macOS 26? Our 2019 Mac Pros can't move to a later major release. Is there a known workaround, such as a sysctl, an nsmb.conf option, or a change to MTU or offload settings? Is there logging or a diagnostic we can leave enabled to capture more state at panic time? We can't reproduce this on demand, but between several machines we see it multiple times a day. We can provide full panic reports, sysdiagnoses, and packet captures from both client and server sides.

Hi Quinn — following up from DTS case 22070584. I'm working on a Windows compatibility runtime (Wine plus a CPU translator) that runs natively on Apple Silicon. 64-bit x86 Windows programs work fine. 32-bit ones don't, because they need address space in the low 4 GB: guest pointers are 32-bit, and some Windows structures sit at fixed addresses like 0x7ffe0000 that programs read directly. On arm64 I can't get anything down there: task_info(TASK_VM_INFO) -> min_address 0x100ea0000 mmap(0x7ffe0000, MAP_FIXED) -> ENOMEM mach_vm_allocate(0x7ffe0000, VM_FLAGS_FIXED) -> KERN_INVALID_ADDRESS There's also nothing below 4 GB to remove: mach_vm_region finds no entry there at all, and mach_vm_deallocate(0, 4 GB) returns KERN_SUCCESS without changing anything. Building with a smaller __PAGEZERO doesn't help either — every size I tried (0x1000, 0x4000, 0x10000, 0x100000, 0x1000000, 0x10000000, 0x80000000) gets SIGKILLed before main, with no crash report. Ad-hoc signing, the hardened runtime and -no_pie made no difference. I did notice /usr/libexec/rosetta/runtime is arm64 with no __PAGEZERO segment at all and __TEXT at vmaddr 0, so the kernel can clearly do this, at least for platform binaries. Is there a supported way for a third-party arm64 process to map below 4 GB — an entitlement, a spawn attribute, something I've missed? If the answer is no, that's fine, I'd just like to know so I can stop looking and plan around it. I have two small test programs that print all of the above if they'd be useful.

On both iOS & macOS 27.2 Beta 2 the call: let token = try await MusicDataRequest.tokenProvider.developerToken(options: [.ignoreCache]) is throwing an error. I can reproduce this on all of my 27.2 Beta 2 devices and I have users worldwide reaching out to me with this issue. The error that gets thrown is: Unknown error "Error returned from daemon: Error Domain=com.apple.accounts Code=9 "(null)"" Have raised FB24895830.