Since iOS 27.0, domain-bound SMS one-time codes are no longer offered above the keyboard in our app, where the code is entered on a web page in a WKWebView, although the app is associated with the domain through webcredentials. The same SMS is offered in Safari on the same device, and it is offered in our app on iOS 26.6 and iOS 18. SMS format (last line per the domain-bound code format): Your verification code is: 123456 @app.example.com #123456Setup Several builds of the same app with different bundle IDs (App Store, internal, development), all under one team Entitlement com.apple.developer.associated-domains: webcredentials:app.example.com (plus two more environments of the same domain) AASA at https://app.example.com/.well-known/apple-app-site-association: 200, application/json, no redirect, same content on app-site-association.cdn-apple.com: {"webcredentials":{"apps":["TEAMID.com.example.app","TEAMID.com.example.app.internal","TEAMID.com.example.app.dev"]}} The code field is an <input type="tel" autocomplete="one-time-code"> in a WKWebView showing a page on that domain. We also tested a native field with the one-time-code content type (the app is built with Flutter; the field is a Flutter TextField with the one-time-code autofill hint). Steps Open the verification page in the app and focus the code field. Receive the SMS above. Expected: the code is offered in the QuickType bar, as it is in Safari on the same domain and as it is in our app on iOS 26.6 and iOS 18. Actual: nothing is offered. The keyboard log: kbd Received verification code from Messages kbd One Time Code field has been entered. kbd Retrieving Current One-Time Codes for App kbd Current verification code is domain-bound to <mask.hash: '…'>. kbd Domain-bound verification code is NOT valid for app <mask.hash: 'X'>. E kbd Could not fetch application record for application identifier: <mask.hash: 'X'>. kbd Returning 0 available one-time codesWhat we checked swcd downloads the AASA for all domains without errors after a reinstall. The installed app's entitlements (read from the device) contain the expected application-identifier and associated domains; the profile is validated. The failure is the same in the WKWebView field and in a native one-time-code field, in the App Store build, a distribution-signed internal build and a development build, and in an older app version that used to work. The masked application identifier in the log (X above) is the same for two builds with different bundle IDs, so the lookup does not seem to use the app's bundle ID. All our builds share CFBundleExecutable = Runner (the Flutter default) and the same CFBundleName. The same app build and the same SMS work on iOS 26.6 and iOS 18.x, so the change happened between iOS 26.6 and 27.0. An SMS without the @domain #code line is offered in the app on iOS 27 (Returning 1 available one-time code), although Could not fetch application record is still logged. Questions Is this a known iOS 27 regression, or is there a new requirement for apps to receive domain-bound codes? What application identifier does the keyboard use for this lookup, and can anything in the app's configuration (for example the executable name) affect it? Device: iPhone 17 Pro Max, iOS 27.0

buenas consulta, a alguien mas le pasa que aun no cuenta con apple inteligence en los modelos CH/A? yo vivo en Argentina y aun nada.

We are experiencing a CarPlay layout issue on a physical iPhone Duo using CPMapTemplate and CPNavigationSession. When guidance cards appear, safeAreaInsets remain zero on the supplied CPWindow, its root view, and our map view. The location marker therefore stays centered and is obscured by the guidance and ETA cards. On a working non-Duo iPhone, the left inset updates correctly and our app shifts the map center accordingly. Apple Maps also shifts the location marker correctly on the affected Duo and displays smaller guidance cards. Environment iPhone Duo iOS 27.1 Xcode 27.1 Is this a known issue? Is there a new public API or configuration requirement in iOS 27+ for obtaining the unobscured map area?

I am preparing the first release of my iOS game, Ippon Battle, and testing it on my own physical devices through TestFlight. I am looking for a supported workaround or further diagnostics for inconsistent product prices, and guidance on whether the same behavior can occur in production. Feedback report: FB25378742 (filed October 31, 2026; currently Open). Apple Developer Support directed me to Feedback Assistant for bug reporting and these forums for technical help. The feedback report includes screenshots and the app-specific identifiers. Environment and observations iPhone 15, iOS 27.0.1 (24A446). App version 1.7.11; raw catalog diagnostics were captured in TestFlight build 41. Two non-consumable products: ipponbattle.fighters5 (Japan: JPY 300) and ipponbattle.story (Japan: JPY 400). The Sandbox account is configured for Japan. The iPhone diagnostic reported Storefront country JPN and currency JPY. Japan prices were independently read-verified through the App Store Connect API on October 21, 2026. I have not changed prices as a troubleshooting step. For each exact product ID, native StoreKit calls returned: Product.products(for:): price = 1.99, priceFormatStyle.currencyCode = USD SKProductsRequest: price = 1.99, priceLocale currency = USD This occurred for BOTH products, despite their different configured Japanese prices. The original in-game shop displayed $1.99 for each. The fighter pack's Apple purchase confirmation sheet showed JPY 300. On a second physical device, an iPad running TestFlight build 44, a screenshot shows the story product at $1.99 in the shop behind Apple's purchase sheet showing JPY 400. The sheet explicitly identifies it as a test purchase with no charge. I did not capture raw storefront/API diagnostics on that iPad, so I am not assuming its internal storefront state was identical to the iPhone trace. Both products were successfully test-purchased in earlier tests. Restoration and ownership after relaunch also worked. The issue is the product metadata price/currency, rather than an inability to complete a purchase. Reproduction procedure Install the app through TestFlight and use the Japan-configured Sandbox account. Request the two product IDs with Product.products(for:) and inspect the returned product IDs, price, priceFormatStyle.currencyCode, and displayPrice alongside the current Storefront. Independently request the same IDs through SKProductsRequest and inspect price and priceLocale. Compare those values with the configured Japan prices and Apple's purchase confirmation sheet. Checks and mitigation Signing out of the Apple account did not resolve the problem. Product data is matched by product ID, not response order. There is no fixed USD fallback or persistent price cache in the app. The TestFlight build does not use a local StoreKit configuration file. These are native API results, not simulated UI test responses. The app refreshes product information when the shop opens and clears old quotes on refresh, failure, or storefront changes. StoreKit 1 is used only to cross-check catalog data. Purchases, transaction verification, and restoration remain on StoreKit 2. As a temporary mitigation for this Japan-only app, prices that cannot be verified as JPN/JPY are hidden. I do not relabel USD amounts as yen, convert them, or substitute hard-coded JPY prices. This prevents the misleading display but does not solve retrieval of the correct catalog prices. Questions Is a mismatch between StoreKit product metadata and the purchase sheet a known TestFlight/Sandbox behavior? Is there any supported way to determine whether production is affected before a first public release? What supported recovery or refresh procedure should I try to retrieve prices consistent with the purchase sheet, beyond re-requesting products and signing out/in? What additional diagnostics, logs, or reproduction details would help the StoreKit team investigate FB25378742? I found a similar report, but I do not know whether it has the same cause. I have not isolated the cause to the catalog service, OS, or account. Thank you.

I’m exploring the development of an iPhone application called DriverTouchLock, designed to help distinguish a vehicle’s driver from its passengers. One possible part of the system would be to use historical Bluetooth connection information as an indicator of which phone is regularly associated with a particular vehicle. For example, if one iPhone has connected to a vehicle’s Bluetooth system hundreds of times, while other phones have connected only occasionally, could that history be used as one factor in identifying the likely driver? My questions are: Can a normal third-party iOS app access the iPhone’s historical Bluetooth pairing information, including previously paired vehicle devices, connection frequency or timestamps, when those connections were made through iOS Settings or CarPlay rather than through the app itself? If this information is not accessible, is there an Apple-approved API, entitlement or alternative method that would allow an app to collect this information? Could an app build its own Bluetooth connection history if it established and managed its own connection to a compatible vehicle accessory? Are there any restrictions that would prevent this approach being used in a standard TestFlight application? I understand that Bluetooth history alone would not prove who is driving. The intention is to use it as one contextual signal alongside motion sensors and other data to improve driver/passenger identification. I’d appreciate any guidance from developers familiar with Core Bluetooth, CarPlay and iOS privacy restrictions. Thank you.

Hello, I am working on an audit of file operations for a DLP agent. I am trying to implement this mechanism using Endpoint Security. One of the customer's requirements is that write event reports must provide information about the file size both before and after the write operation. The challenge is that the ES_EVENT_TYPE_NOTIFY_WRITE event does not provide information about the changes, and in the stat structure, I see the file's stat prior to the write event. I tried to implement a mechanism based on tracking the sequence of events (open -> write -> close), but it seems macOS does not guarantee such a sequence, as the agent receives ES_EVENT_TYPE_NOTIFY_CLOSE earlier than ES_EVENT_TYPE_NOTIFY_OPEN. Unfortunately, Auth events cannot be used due to no guarantee the DLP agent is the only ES client. Is there any way within the Endpoint Security Framework to guarantee the sequence of NOTIFY events? Are there any other supported (public) APIs or methods besides Endpoint Security to track file system changes? As far as I know, ktrace (which powers fs_usage) is a private framework. Thank you in advance!

We are experiencing a CarPlay layout issue on a physical iPhone Duo using CPMapTemplate and CPNavigationSession. When guidance cards appear, safeAreaInsets remain zero on the supplied CPWindow, its root view, and our map view. The location marker therefore stays centered and is obscured by the guidance and ETA cards. On a working non-Duo iPhone, the left inset updates correctly and our app shifts the map center accordingly. Apple Maps also shifts the location marker correctly on the affected Duo and displays smaller guidance cards. Environment iPhone Duo iOS 27.1 Xcode 27.1 Is there a new public API or configuration requirement in iOS 27+ for obtaining the unobscured map area? Thank you.

Summary: Starting from iPadOS 26.4, the maximum memory available to a single app has been reduced from approximately 6GB to 3GB on an 8GB iPad. This change persists in iPadOS 26.5 and has not been addressed. This breaks core functionality of memory-intensive applications such as 3D scanning apps that require large amounts of RAM to process models. Device: iPad with 8GB RAM Affected versions: iPadOS 26.4, iPadOS 26.5 Working version: iPadOS 26.0 / 26.1 / 26.2 / 26.3 Measured Data: iPadOS 26.0–26.3: App available memory ≈ 6GB (75% of total RAM) iPadOS 26.4–26.5: App available memory ≈ 3GB (37.5% of total RAM) Measurement method: Apple system API Impact: This is a regression, not expected behavior. The available memory per app has been cut by 50% without any official documentation or release notes mentioning this change. As a result, our 3D scanning application crashes immediately when attempting to process 3D models on iPadOS 26.4 and later. The app requires substantial RAM to load and process 3D model data. With only 3GB available, memory allocation fails during model processing, causing the app to crash (EXC_RESOURCE / OOM kill). This core functionality was working correctly on iPadOS 26.3 and earlier with the same device and same app binary. This regression makes our app's primary feature completely unusable for all users on iPadOS 26.4+. Steps to Reproduce: On an 8GB iPad, install iPadOS 26.0 Measure available app memory using Apple system API Upgrade to iPadOS 26.4 or 26.5 Measure available app memory again Observe: available memory drops from ~6GB to ~3GB Expected Result: Available memory per app should remain consistent across minor OS updates, or any changes should be documented. Actual Result: Available memory per app dropped by 50% starting in iPadOS 26.4, with no documentation of this change. Additional Notes: Disabling Apple Intelligence does not resolve the issue This issue was not fixed in iPadOS 26.5 Other developers have reported increased crash rates starting in iPadOS 26.4 (Apple Developer Forums)

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

I'm developing an app that uses SMAppService to register a launch daemon. I'm running into big troubles with having the daemon start up reliably because, over the course of testing, the location of my app bundle has changed. Various workflows for this app require testing it running from with /Applications, /Applications/Utilities, or in the project's build directories, which includes both debug and release builds. And I need to account for users moving the app bundle around. The trouble is that the launch daemon seems to want to launch from the first path it was registered, not at the path it was last registered. For example, if my app originally registered it while located in /Applications/MyApp.app, then the launch daemon will only run from within an app bundle at that specific location, even if there is no app bundle at that path. As per advice on these forums, I've tried accounting for this by unregistering the daemon, waiting two seconds, and then re-registering it. But in practice this isn't working. I can use sfltool dumbtm and see that the app is still registered in /Applications/MyApp.app and not its new location, and the launch daemon simply silently fails to launch -- SMAppService returns no error. sudo launchctl list displays the job as having status 78. If I set up a stdout/stderr redireciton in its job file, the files are empty. (I'm aware that I can use sfltool resetbtm to completely reset all login items and background tasks and temporarily fix this issue at least on my own system, but I can hardly have my app use that as part of its standard installation procedure. I need some way of dealing with this that doesn't requiring reseting the state of every app that has a background item.) I'm starting to pull my hair out dealing with this! (Figuratively, mind you. Not literally, at least not yet.) How can I get this to work? This API is starting to seem like a downgrade from placing a plist file in /Library/LaunchDaemons because at least that was able to work very reliably.

We are implementing a Transparent Proxy for HTTPS (via TCP and QUIC). The following rules are set in startProxy: settings.includedNetworkRules = [ NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .UDP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .UDP) ] Handling TCP connections seems to work fine. But opening UDP flows from Chrome (or Brave) always fails with Error Domain=NEAppProxyFlowErrorDomain Code=2 "The peer closed the flow" (Doing the same for Firefox works!) BTW: We first create a remote UDP connection (using the Network framework) and when it is in the ready state, we use connection?.currentPath?.localEndpoint as the localEndpoint parameter in the open method of the flow. Is it a known issue that QUIC connections from Chrome cannot be handled by a Transparent Proxy Provider?

Hello, We are investigating an issue where our iOS app, running as a “Designed for iPad” app on an Apple Silicon Mac, is terminated when it is suspended in the background. Environment OS: macOS 27.0.1 Hardware: Apple Silicon Mac App type: An iOS/iPadOS app running on Mac, rather than a separately developed macOS app The app uses Core Image’s CIContext to generate some image effects Steps to reproduce Launch the app on Mac and start playing a podcast. Move the app to the background. Start playback on another device. Our app’s cross-device playback coordination pauses playback on the Mac. After a short period, the Mac app is terminated. We have also observed similar termination after visiting a screen that uses Core Image image effects. Actual result The debugger reports: Terminated due to signal 9 RunningBoard logs indicate that the app was terminated with code 0xDEAD10CC because it was suspended while holding a disallowed shared file lock. The file identified in the log is: /var/folders/.../C/app.podcast.cosmos/app.podcast.cosmos/com.apple.metal/archiveUsage.db/lock.mdb The relevant log message includes: suspended while holding a shared file lock Investigation so far Using breakpoints on open and openat, we captured a call stack corresponding to: App creates a CIContext → Core Image CI::MetalContext → Metal recordBinaryArchiveUsage → archiveUsage.db/lock.mdb is opened We also tried: CIContext(options: [.useSoftwareRenderer: true]) However, in our test environment, we still observed Metal initialization and access to the relevant cache files. This option did not avoid the issue. For the gradient-mask generation code we had identified, we replaced the Core Image implementation with a CPU implementation using CGContext and CGGradient, avoiding CIContext creation on that path. After repeatedly testing the same reproduction steps, we could no longer reproduce the termination in that scenario. This suggests a connection to the Metal cache file lock accessed during Core Image initialization. However, we have not established the exact lifetime or internal owner of the lock, and we have not confirmed a thread deadlock. Questions Is this a known issue involving Core Image/Metal and suspension of iOS apps running on macOS 27.0.1? Why would a system-managed Metal cache file lock cause the app to be terminated with 0xDEAD10CC when suspended? Is there a recommended context configuration, resource cleanup procedure, or lifecycle handling approach that allows us to continue using Core Image safely in this environment?

On macOS 26.7.1 with Xcode 26.6 on Apple silicon, a small set of ordinary development source/resource files and one project directory carry the private extended attribute com.apple.macl. We need to create a new APFS compilation-input tree, not a filesystem backup. The proposed implementation opens source and destination objects using descriptor-relative no-follow traversal and calls fcopyfile(sourceFD, destinationFD, NULL, COPYFILE_DATA), then independently verifies exact content hashes and applies an explicit destination mode and ACL policy. It does not request COPYFILE_XATTR, COPYFILE_ACL, or COPYFILE_STAT. Is omitting com.apple.macl supported for this data-only compilation export? Could preserving it transfer stale or inappropriate access authority to the destination? Which supported API or documented postconditions should establish the destination's correct security state? Is there an Apple-recommended procedure for exporting ordinary development source content without transferring private mandatory-access metadata? We are seeking an API and security contract, not an interpretation of the attribute's private bytes. No production paths, source code, private attribute values, credentials, datasets, or personal information are included.

I'm implementing a security-sensitive filesystem metadata verifier on macOS 27.0.1 (Apple Silicon, MacOSX27.0.sdk). The verifier must distinguish three states: ACL absent: Supported evidence establishes that the file or directory has no filesystem ACL. ACL present: An ACL exists, including an empty ACL. Unknown: The observation is ambiguous, unavailable, unsupported, or incomplete. Only authoritative ACL absence is acceptable. All other states are rejected. I'm investigating fstatx_np() with a filesec_t object, followed by filesec_query_property(security, FILESEC_ACL, &present). My questions are: Does this combination provide a supported API guarantee that a file or directory has no ACL when present is reported as false? Can an unset FILESEC_ACL property be reliably distinguished from an omitted or unavailable ACL observation? If this mechanism cannot establish absence, is there another supported descriptor-based macOS API that can? Is there Apple documentation specifying these semantics, including relevant error and unsupported-operation behavior? I am not treating an empty ACL entry list, an unset property, or a command-line display without ACL entries as proof of absence. I'm seeking the native API contract so the verifier can fail closed whenever ACL absence is not authoritatively established.

Background We are developing Share&Share, an offline device-to-device content transfer application. An iPad automatically joins a nearby Samsung Android LocalOnlyHotspot. The hotspot credentials are delivered through an authenticated, encrypted Bluetooth Low Energy (BLE) session. On iPadOS, our application decrypts the credentials natively in Swift and uses NEHotspotConfigurationManager.apply() to join the hotspot. We are investigating an intermittent connection problem during the initial automatic join. We have also submitted a private report through Apple Feedback Assistant: Feedback ID: FB25408475 Test environment Receiver: Physical iPad with a Home button. Sender/hotspot: Samsung SM-E055F. Android version: Android 16. Hotspot security: WPA2/WPA3 transition configuration. iOS implementation: Swift and NetworkExtension. joinOnce = false. The hidden property is not explicitly set. Observed behaviour Two independently instrumented automatic-join sessions showed a similar sequence: A1: The iPad associates with the Samsung hotspot and completes the WPA3 authentication exchange recorded by the Samsung. Approximately 3.35 seconds after the iPad-side join completion, iOS records a beacon-loss/roam declaration and the connection drops. A2: iOS attempts to reconnect, but the authentication exchange does not complete. A3: iOS automatically reconnects successfully, obtains a DHCP address and remains connected during the observation period. The same encrypted credentials work during both the initial and subsequent successful attempts. The apply() completion handler returns without an error. We understand that this does not establish that the device has joined successfully or that local IP connectivity is ready. What we have investigated The first join used cached beacon information approximately eight seconds old; the subsequent successful join used fresh scan information. AWDL activity was observed, but we have not established a causal relationship. Location Services scanning does not explain the first failure in our second instrumented session. The diagnostic label "Beacons Lost" is not being treated as proof of actual missed beacon frames. We have not independently established which WPA mode the iPad negotiated. We have not yet measured TCP readiness during the failed and successful attempts. We do not currently have a standalone minimal Xcode reproduction project. The behaviour was observed using our Flutter-based iOS probe and physical devices. Questions for developers familiar with NetworkExtension Has anyone observed intermittent first-join instability with NEHotspotConfigurationManager when joining a newly created Android LocalOnlyHotspot using WPA2/WPA3 transition mode? Are there documented limitations or known issues involving the first automatic join to a newly created hotspot profile? What is the recommended supported approach for determining that the intended Wi-Fi network is genuinely connected after apply() completes? What is the most reliable way to establish that local TCP communication is ready before beginning an application-level transfer? Are there additional public diagnostic facilities or measurements that could help distinguish Wi-Fi association instability from DHCP or subsequent network-path problems? We are looking for a documented, App Store-compatible approach. We are not assuming a particular root cause and do not want to rely on private APIs or undocumented system behaviour. Any practical experience or pointers to relevant Apple documentation would be appreciated.

Hello, We are validating Wi-Fi Calling (VoWiFi) deployment in a mobile operator IMS network and would appreciate clarification regarding IPv6 support on iPhone devices. Our current environment includes: IMS Core supporting IPv4 and IPv6 connectivity ePDG platform with planned IPv6 enablement Dual-stack and IPv6-only access scenarios under evaluation Wi-Fi Calling service already operational over IPv4 We would like to understand Apple's requirements and recommendations for enabling VoWiFi over IPv6. Specifically: Does iPhone officially support Wi-Fi Calling over IPv6-only Wi-Fi access networks? Is VoWiFi supported when the Wi-Fi access network provides only IPv6 connectivity and the ePDG is reachable through AAAA DNS records? Are there any specific requirements regarding: ePDG IPv6 reachability AAAA DNS records IKEv2/IPsec over IPv6 transport Carrier Bundle configuration IMS APN IPv6 / IPv4v6 settings Are there iOS version dependencies or carrier configuration requirements to enable VoWiFi over IPv6? Is there any public Apple documentation covering IPv6 support for Wi-Fi Calling deployments from a carrier perspective? Our objective is to validate a future IPv6-based VoWiFi deployment and ensure compatibility with iPhone devices before enabling IPv6 transport in production. Any guidance or references would be greatly appreciated. Thank you.

需要满足 （1）后台保活，在后台时任务仍然能一直运行直到任务完成 （2）任务在后台运行时，且前台负载较低时让任务分配尽量多的CPU资源，保持任务的性能和前台时接近 （3）需要使用GPU和NPU，需要跑AI模型，如果可以用GPU就更好，（GPU不跑也行） （4）方案合法，能上架苹果APP Store. 可以通过蓝牙连接来进行后台保活，这个任务本身就需要通过蓝牙连接一个外设，但是这种保活方式任务在后台时CPU权限较低，性能时延劣化很严重。 任务本身是类似做图片/视频处理的任务，需要跑几秒到几分钟的量级，最好可以尽量多地跑久一些。 我们试过了，后台保活后性能都大幅下降，降了6~10倍，体验较差 有没有做过类似的后台任务的，最终做到前后台性能接近的（前台空负载时）？

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.

After a REFUND_REVERSED notification, with no new purchase or renewal, is the transaction’s signedDate in signedTransactionInfo from Get All Subscription Statuses guaranteed to be strictly later than the reversal notification’s outer signedDate? Or can the API return an active subscription with a transaction signedDate equal to or older than the reversal’s timestamp? We’re deciding whether a strictly newer timestamp is a reliable condition for restoring access.

On macOS 26.7.1 with Xcode 26.6 on Apple silicon, several directories in a development tree carry the private extended-attribute names com.apple.fileprovider.dir#N and com.apple.fileprovider.fpfs#P. On this host, the supported xattr_flags_from_name decoder returns XATTR_FLAG_NEVER_PRESERVE for the first exact name and XATTR_FLAG_NO_EXPORT for the second exact name. Apple's public API defines those flag meanings; the literal name encoding and the attributes' private values are not treated as a public semantic contract. We want a self-contained APFS compilation-input tree using descriptor-based COPYFILE_DATA for regular files, with independent inventory and hash verification and no private-xattr copying. For this compilation-only export, does Apple support deliberate non-preservation when xattr_flags_from_name returns XATTR_FLAG_NEVER_PRESERVE, and when it returns XATTR_FLAG_NO_EXPORT for a governed SHARE operation? Separately, what public, non-hydrating API can establish that every required file is already fully materialized and that export will not trigger provider downloads? Does enumeratorForMaterializedItems establish that state for a closed descendant tree, or must each item be checked by another supported API? Can reading or hashing an item itself cause materialization? We are asking about documented APIs, supported export behavior, and security postconditions. We are not asking to decode or preserve private attribute values. No production paths, source code, credentials, datasets, or personal information are included.