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

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!

I’m developing a macOS app that reads a wired controller and publishes a generic BLE HID gamepad for an iPhone. BLE communication works, but iOS does not expose the device through GameController. I’m looking for guidance on supported device-identity publication and controller-admission requirements. Environment Apple Silicon MacBookPro17,1: macOS 27.0, build 26A428 iPhone 15 Pro Max: iOS 27.0, build 24A437 Xcode 27 Peripheral implemented using CBPeripheralManager What works The iPhone can connect, perform dynamic characteristic reads, and read encryption-required characteristics using the retained pairing. It discovers the application’s HID service and reads its Report Map, HID Information, Report Reference, and Input Report. The descriptor in the iPhone’s system HID record matches the application’s remotely read report map byte-for-byte. The peripheral also receives an input subscription, although I cannot independently identify the subscribing consumer. What fails An independent GCController.controllers() observer remains empty. During the recorded HID initialization, the iPhone logs: Un-authenticated game controller device attached Start failed: 0xe00002bc IOHIDEventDriver start failed. For the same registry device, gamecontrollerd records: vendorID = 0 productID = 0 version = 0 manufacturer = 'Apple Inc.' product = '[Mac device name]' transport = 'BluetoothLowEnergy' I am not assuming that “Un-authenticated” identifies a specific authentication requirement. I would like to understand which supported admission requirement is unmet. Device Information observations The iPhone’s CoreBluetooth discovery exposes two distinct Device Information service instances: System service Observed UUID: 180A Manufacturer: Apple Inc. Model: MacBookPro17,1 No PnP characteristic exposed by successful all-characteristic discovery Application service Observed UUID: 0000180A-0000-1000-8000-00805F9B34FB Manufacturer: PS3 Bridge Model: BLE Gamepad Prototype PnP bytes: 02 00 00 01 00 00 01 The application publishes expanded Bluetooth-base UUIDs. I understand these represent the same assigned UUIDs; I am preserving the observed representations because I have not established whether every host component handles them identically. The application PnP value represents vendor-ID source 2, vendor 0, product 1, and version 0x0100. The system HID record therefore does not simply reflect that value unchanged. The duplicate-DIS layout also appears inconsistent with the unique primary DIS expected by HOGP. I have not established that this causes the driver rejection. Questions Is there a supported macOS API or architecture for publishing a coherent BLE HID device identity when macOS already exposes its own Device Information service? How does iOS select DIS/PnP information when constructing a system HID device in this arrangement? Is a generic BLE HID gamepad published through macOS CoreBluetooth a supported path to iOS GameController recognition? If so, what additional profile, identity, or authentication requirements apply? What supported diagnostics would distinguish an identity-selection problem from a separate controller-admission requirement? Available evidence I have diagnostic source, corrected per-service-instance inventories, and redacted phone logs available. I also have a small standalone CoreBluetooth publication reproducer. It is reduced and has not been validated as independently reproducing the full bridge’s controller rejection. A later connection-only observation reused an existing shared Bluetooth link and still showed zero controllers. I am not treating that as a fresh HID initialization or admission attempt. I’m seeking a supported implementation path without private APIs, Bluetooth daemon modifications, or changes to system security.

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.

App Store Server API: Sandbox returns 200, Production returns 401 with the same JWT We are seeing a reproducible authentication issue with the App Store Server API for our app FYRT. Bundle ID: com.fyrt.Fyrt We performed a fresh read-only test on September 29, 2026 using our In-App Purchase key BJ5HR5GSY6. Both requests used: the same In-App Purchase key the same Issuer ID the same Bundle ID ES256 the same JWT structure 300-second token lifetime correct system time with no relevant clock skew Only the environment changed. Sandbox: HTTP 200 Apple Request ID: 458b3b32-8e0d-1404-19fe-6c92ba2ccd27 Production: HTTP 401 Apple Request ID: 193406ac-80d2-d135-8cc8-34e4ebe76fc5 The Production response does not include an additional Apple error code. The request is read-only and requests notification history. No purchase is triggered and no Production data is changed. We verified: correct Key ID correct Issuer ID correct Bundle ID ES256 signing current iat valid exp correct Sandbox and Production endpoints no environment mixing fresh JWT generation for each request no clock skew The same behavior was already reproduced on September 11, 2026. Our existing Apple Support case is: 102960057430 Has anyone seen Sandbox accept the same authentication while Production returns 401? Could this be related to Production-side provisioning, app status, team/account authorization, or the fact that the app has not yet had a version released on the App Store? Any guidance from Apple engineers would be greatly appreciated.

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.

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.

Hello, We are investigating an auto-renewable monthly subscription in the Production environment. Timeline and observed behavior: On June 29, 2026, the user initiated the first subscription purchase. The Apple Account used WeChat Pay as its payment method. The WeChat charge failed because the balance was insufficient, and no funds were deducted from any available payment source. Nevertheless, StoreKit returned a verified transaction, the subscription purchase succeeded in the app, and App Store Connect Sales Analytics reports proceeds for the purchase. We grant entitlement based only on Apple's signed transaction and subscription status, so the user currently has access. As of July 20, 2026, Get All Subscription Statuses from App Store Server API returns: environment: Production status: 1 (Active) expiresDate: 2026-07-29T03:37:11Z autoRenewStatus: 1 no gracePeriodExpiresDate no revocationDate no expirationIntent no billing retry indication Our App Store Server Notifications endpoint has received only: SUBSCRIBED / INITIAL_BUY We have not received DID_FAIL_TO_RENEW, EXPIRED, REFUND, or REVOKE. Questions: Is it expected for Apple to issue a valid production initial-purchase transaction and report proceeds even when the underlying WeChat Pay charge failed and no money was deducted? Could this be an unpaid Apple Account balance or delayed settlement that is invisible to the developer? While the Server API returns status 1, should the developer continue granting entitlement until expiresDate? Is there another authoritative App Store Server API or signed field that indicates the payment has not actually been collected? If renewal or collection later fails, when should we expect DID_FAIL_TO_RENEW or a change to billing retry or expired status? We have intentionally omitted transaction IDs and account identifiers from this public post. I can provide them privately to Apple Support if needed. Thanks

Hello, We are contacting you regarding an issue we are currently experiencing during the App Review process related to In-App Purchases and StoreKit product retrieval. After extensive internal testing and investigation, we believe the behavior we are seeing is identical to the issue discussed in the following Apple Developer Forum thread: https://developer.apple.com/forums/thread/827016 Our application was rejected under Guideline 2.1 - Performance because the subscription plans reportedly failed to load during review. According to the review notes, the In-App Purchase product list appeared empty in the review environment, which prevented the paywall from loading correctly. We would like to provide additional technical context because, despite significant testing efforts on our side, we have been unable to reproduce this behavior outside of the App Review environment. The exact same binary that was reviewed by App Review has been thoroughly tested by us through TestFlight on multiple physical devices, including iPhone and iPad devices, using multiple Sandbox tester accounts and different network conditions. In all of our tests, the subscription system functions correctly and consistently. Specifically, we verified that: StoreKit successfully retrieves all configured subscription products RevenueCat offerings load correctly without timeout or empty states Localized pricing information is displayed properly Subscription packages appear correctly in the paywall UI Purchase flows complete successfully Restore purchases functionality works correctly Products are returned both on cold launch and repeated application launches The issue does not occur intermittently in TestFlight or Sandbox testing on our side We also carefully reviewed our App Store Connect configuration and verified the following items multiple times: All In-App Purchase subscriptions are attached to the submitted app version Product identifiers used in the application code exactly match the identifiers configured in App Store Connect All products are marked as “Cleared for Sale” Paid Applications Agreement has been accepted and remains active Tax and banking information are complete and active Subscription localization settings are configured properly Pricing information is active and visible The products are available in the storefronts being tested The submitted binary is identical to the binary tested successfully through TestFlight Additionally, we implemented defensive handling in the application to minimize the impact of temporary StoreKit failures. The application now includes: Retry logic for offerings retrieval Graceful fallback handling for empty offerings Protection against infinite loading states Additional RevenueCat and StoreKit logging UI fallbacks when products temporarily fail to load Despite these safeguards, the review feedback still indicates that the products are not being returned in the App Review environment. At this point, because the issue cannot be reproduced externally and only appears during App Review, we suspect there may be an intermittent or environment-specific issue affecting StoreKit product retrieval in the review sandbox environment. One important detail is that the exact same build consistently works in TestFlight immediately before and after submission. This makes the behavior particularly difficult for us to diagnose because there appears to be no configuration difference between our successful tests and the App Review scenario. We also understand from Apple documentation and previous App Review communication that In-App Purchases are tested within an Apple-provided sandbox environment. Based on the evidence currently available to us, the failure appears to occur specifically within that review sandbox process rather than within the application logic itself. If possible, we would greatly appreciate assistance with the following: Verifying whether StoreKit product retrieval is functioning correctly in the App Review sandbox environment Confirming whether the review device successfully established communication with App Store sandbox services Providing any available diagnostic logs related to the failed product request Confirming whether the product identifiers were visible to StoreKit during review Sharing any guidance on how we may reproduce the App Review behavior locally Clarifying whether there are known intermittent issues affecting StoreKit product loading during App Review We are fully committed to resolving the issue and ensuring complete compliance with App Store requirements. However, because the issue currently appears environment-specific and non-reproducible from our side, we are struggling to determine what additional changes are necessary. If there are any additional diagnostics, logging methods, StoreKit verification steps, or App Review recommendations you would like us to implement, we would be happy to do so immediately. Thank you very much for your assistance, support, and time. We sincerely appreciate your help in investigating this issue. Best regards, Mert Akgün

For an In-App Purchase made by a customer whose App Store account is in the Saudi Arabia storefront, where Apple acts as commissionaire and remits VAT, does Apple issue the customer any tax document (a VAT invoice or a tax receipt), or is the customer's purchase history the only record available? Apple's support article 'View your purchase history for the App Store and other Apple media services' (support.apple.com/en-us/118212) documents viewing purchase history only — the words 'receipt', 'invoice' and 'tax' do not appear on that page.

Does App Review accept multiple In-App Purchases in the same app sharing an identical display name (for example ten non-renewing subscriptions all named 'Example Digital', differing only in price and duration)? The purchase sheet always shows the price alongside the name. App Store Connect Help documents a 2–30 character limit for the display name but states no uniqueness rule.

Does changing the price of an already-approved In-App Purchase trigger a new App Review, or does the new price take effect without review? App Store Connect Help states that changes to localized information require review and that 'New pricing will go into effect immediately', but never says explicitly whether a price change alone is exempt from review. We need this for a non-renewing subscription sold in the Saudi Arabia storefront.

Can an In-App Purchase that has reached the 'Approved' state ever be deleted from App Store Connect, either in the UI or through the App Store Connect API? App Store Connect Help documents no deletion procedure and no 'deleted' status. If deletion is possible, is it blocked while the product has existing purchases, or while it is still available for sale?

Does the App Store send a CONSUMPTION_REQUEST App Store Server Notification when a customer requests a refund for a non-renewing subscription? The documentation is inconsistent: the notificationType page lists only 'a consumable In-App Purchase or auto-renewable subscription', beginRefundRequest(in:) mentions only consumables, but the Send Consumption Information endpoint states it applies to 'any product type (consumable, non-consumable, non-renewing subscription, or auto-renewable subscription)'. Which is correct for a non-renewing subscription sold in the Saudi Arabia storefront?

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.

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.

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