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.

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.

In the LAPACK interface of Accelerate (the default, without ACCELERATE_NEW_LAPACK), zheev with JOBZ='V', UPLO='U' returns eigenvectors that are neither orthonormal nor eigenvectors, while INFO=0. The eigenvalues are correct. zhegv with UPLO='U' fails the same way (tested with B = identity). It happens when: the matrix is complex Hermitian of order N >= 130 (N = 129 is correct, N = 130 already fails, N = 300 fails), and its last two or more rows and columns are exactly zero (one zero row is fine). Zero rows at the start or in the middle are fine. Banded and dense matrices both fail. On the same matrices the following are correct to rounding (1e-15): zheev and zhegv with UPLO='L', zheevd with UPLO='U', dsyev with UPLO='U' on real symmetric matrices of the same shape, zheev with UPLO='U' through the new LAPACK interface (-DACCELERATE_NEW_LAPACK). Since only the eigenvectors are wrong, and only above N=129 (presumably where zhetrd switches to its blocked code), the fault seems to be in the blocked Householder reduction or in the back-transformation (zhetrd/zlatrd or zungtr/zungql) of the legacy library, for columns that are zero. Asking LAPACK for the optimal LWORK (LWORK = -1 query) does not change the result. We found this in a physics code (Quanty, quanty.org), where a matrix of this shape arises naturally: a block tridiagonal (block Lanczos) matrix whose last block is padded with zeros after deflation. The wrong eigenvectors silently degraded results by 1e-4 relative, instead of 1e-15. STEPS TO REPRODUCE Save the attached zheev_upper_bug.c. clang -O2 zheev_upper_bug.c -o zheev_upper_bug -framework Accelerate ./zheev_upper_bug For comparison: clang -O2 -DACCELERATE_NEW_LAPACK zheev_upper_bug.c -o zheev_upper_bug_new -framework Accelerate && ./zheev_upper_bug_new The program builds a random Hermitian matrix (fixed seed, entries in [-0.5,0.5), bandwidth 11 or dense), zeroes its last NZERO rows and columns, calls zheev/zhegv/zheevd and prints max|V^H V - 1| and max|A V - V diag(W)|. EXPECTED RESULT Both numbers of order 1e-15 for every line, as with the new LAPACK interface. ACTUAL RESULT (legacy interface) zheev UPLO=U N=129 zero trailing rows=2 INFO=0 max|V^H V - 1| = 4.0e-15 max|A V - V W| = 4.4e-15 ok zheev UPLO=U N=130 zero trailing rows=2 INFO=0 max|V^H V - 1| = 9.8e-01 max|A V - V W| = 1.1e+00 <-- WRONG zheev UPLO=U N=130 zero trailing rows=1 INFO=0 max|V^H V - 1| = 4.7e-15 max|A V - V W| = 3.3e-15 ok zheev UPLO=U N=138 zero trailing rows=5 INFO=0 max|V^H V - 1| = 1.1e+00 max|A V - V W| = 1.2e+00 <-- WRONG zheev UPLO=U N=138 zero trailing rows=5 INFO=0 max|V^H V - 1| = 2.1e-01 max|A V - V W| = 2.2e+00 <-- WRONG zheev UPLO=U N=300 zero trailing rows=2 INFO=0 max|V^H V - 1| = 7.0e-01 max|A V - V W| = 1.5e+00 <-- WRONG zhegv UPLO=U N=138 zero trailing rows=5 INFO=0 max|V^H V - 1| = 1.1e+00 max|A V - V W| = 1.2e+00 <-- WRONG the same matrices with UPLO = 'L' or zheevd: zheev UPLO=L N=138 zero trailing rows=5 INFO=0 max|V^H V - 1| = 5.9e-15 max|A V - V W| = 3.6e-15 ok zhegv UPLO=L N=138 zero trailing rows=5 INFO=0 max|V^H V - 1| = 4.4e-15 max|A V - V W| = 3.7e-15 ok zheevd UPLO=U N=138 zero trailing rows=5 INFO=0 max|V^H V - 1| = 1.9e-15 max|A V - V W| = 1.4e-15 ok With -DACCELERATE_NEW_LAPACK every line is "ok" (1e-15). Code to reproduce the error: zheev_upper_bug.c.txt

My custom filesystem kernel extension stores ACLs as an extended attribute, com.apple.system.Security. Sanboxed apps such as TextEdit, Pages, etc., running as a non-privileged process, fail to save modified contents when permissive ACLs are in use. Running them as a privileged process, does allow for file changes to be saved though. Non-sandboxed apps, such as VSCode, and command line programs are not susceptible to this behaviour. APFS, on the other hand, seems to handle ACLs as an ATTR_CMN_EXTENDED_SECURITY filesystem attribute, rather than as an EA. In this case, sandboxed apps have no trouble accessing the ACL data. I implemented a minimal PoC within my custom kext to verify this. I construct an ACL in memory allowing a given user to write,append,delete file contents, and return it that via vnop_getattr. This allows the file contents to be modified and saved by sandboxed apps. Can you please confirm if my findings are accurate and sandboxed apps fail to read the com.apple.system.Security EA by design? Also, Is it an accurate assumption, that ACLs should be handled either as an EA, or an ATTR_CMN_EXTENDED_SECURITY, but not both? Thanks.

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.

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.

I’m building a SwiftUI app that fetches public JSON data using URLSession.shared. The request works correctly in the iPhone 17 Pro Max Simulator, but fails on my physical iPhone 16 Pro Max running iOS 27 beta. Endpoint: https://api.jolpi.ca/ergast/f1/2026/driverstandings.json?limit=100 Error: NSURLErrorDomain Code=-1009 “The Internet connection appears to be offline.” NWPath: unsatisfied (Denied over Wi-Fi interface) Resolved 0 endpoints in 1ms The device can access the endpoint through Safari, and the same request works in Simulator. VPN, cellular permissions, Wi-Fi changes, and ATS settings have been checked. Could this be an iOS 27 beta networking regression affecting URLSession on physical devices? Are there recommended workarounds or diagnostics?

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 Live Caller ID Lookup extension (PIR-based) for spam call blocking. It works, and our PIR server is fast. But in practice, whether a call gets blocked depends on the quality of the user's internet connection at the moment the call arrives. The system waits only about 1 second for the blocking response. On a fast, stable connection it arrives in time. On an average or unstable connection it often doesn't, and the spam call rings through. So under the current platform limits we cannot guarantee blocking for every call. How we measured For each call we read the device syslog (CommCenter, CallDirectory, ciphermld, callservicesd) and our server logs. The extension cache was reset before each call, so every call triggered a real network lookup. All times are in ms and measured from addNewIncomingCall. Server-side processing of the PIR query was consistently 51–61 ms. The variance is almost entirely network transfer between the device and the server (or relay): In call D, HTTP/2 metrics show the ~28 KB request was handed to the network stack immediately (outbound_duration_ms=0), but response headers arrived only after 2216 ms. In call E, the device waited ~660 ms between finishing the upload to the relay and receiving the first byte of the response. Connection setup on a new connection cost 176–271 ms (DNS + TCP + TLS, or a QUIC handshake to the relay). Before the first byte was sent, the system spent another 54–225 ms after the call arrived. In the failing cases the syslog shows: CallDirectory: not all blocking fetches returned within 1 second(s) callservicesd: shouldBlock: NO shouldSilence NO The block response (shouldBlock=1) then arrives 100–1500 ms too late, and the call keeps ringing. What works: repeat calls After the first lookup the result is cached on the device. A repeat call from the same number is silenced without contacting the server, whatever the connection speed. In our logs, follow-up calls from the same number were silenced within ~65 ms of addNewIncomingCall, with no network request. So a user may get the first spam call from a number but not the next ones. The first call, though, is exactly the one users complain about. The problem with the 1-second budget Each blocking lookup has to: Send a PIR query Receive a response of ~22–25 KB. Often open a new TLS/QUIC connection through the OHTTP relay. All of this has to fit into about 1 second, together with the system's own overhead before the request is sent. On a good connection that takes about 250–650 ms. On an average mobile or congested Wi-Fi connection it easily goes past 1 second, and nothing the developer can optimize on the server helps. Our server already responds in about 50 ms.

The language in the new EULA seems to indicate we can get permission to run more than 2 VMs on a single host. "(iii) except as otherwise provided in writing, signed, or issued by an authorized representative of Apple, to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use." This is important because we often have use-cases that require running docker containers and other Virtualization tools along-side of two VMs on the host and obviously cant. What's the steps we can take to get written permission for this? Thank you!