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.

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?

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.

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.

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.

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?

Hello, I would like to clarify the exact technical behavior of the App Store Server API (V2) and StoreKit under the following two specific scenarios: Case A (Production Account on Sandbox Endpoint): If a user with a production Apple Account attempts to purchase through a build pointing to the Apple Sandbox environment (or Sandbox API), how does the Apple server handle this transaction and its data lifecycle? (Does StoreKit block this at the client-side, or does the API return a specific error code?) Case B (Restoring Cleared Sandbox Data): If a Sandbox tester's purchase history is cleared/deleted on the Apple server, and the app subsequently requests a "Restore Purchase" or queries the App Store Server API using a previously valid transactionID from that account, what specific error code (such as 4040010 TransactionNotFound) or empty response does the Apple server return? I would highly appreciate your confirmation or any technical insights on these behaviors. Thank you!

Hello, I would like to clarify the best practices and timing for our backend server to transition its main connection to the production App Store Server API. Currently, we are considering the following approach: We plan to switch our backend’s primary API endpoint from Sandbox to Production once our app passes the App Store review and its status changes to "Ready for Sale." Could you please confirm if this timing is standard and correct? Additionally, to handle App Store reviews (which run in the Sandbox environment) and TestFlight tests seamlessly without manual configuration changes, we are planning to implement an automatic fallback mechanism: Our backend always requests the Production App Store Server API first. If it returns a "TransactionNotFound" (e.g., 4040010) error, the backend automatically retries the request using the Sandbox API. Is this automatic fallback from Production to Sandbox considered a safe and recommended practice by Apple, especially for App Store reviews and post-release testing? Any advice or insights on backend transition timing and fallback strategies would be highly appreciated. Thank you!

Hi, During the App Review process, a test purchase was made using what appeared to be a production Apple account. When our app server sent this transactionId to the Production App Store Server API, it returned the error code 4040010 (TransactionIdNotFoundError). To handle this gracefully and prevent review rejections, we are considering implementing a dynamic fallback mechanism on our app server. Specifically, when the Production API returns 4040010, the server will automatically retry the request using the Sandbox App Store Server API URL. Could you please clarify the following points regarding this design? Is it expected behavior for an App Review purchase to return 4040010 on the Production API, and can it be successfully verified by routing it to the Sandbox API? Is this dynamic fallback logic (Production API ➔ if 4040010 ➔ Sandbox API) a recommended and officially supported best practice for handling App Review and TestFlight transactions? Any confirmation or advice from Apple engineers or the community would be greatly appreciated.Thank you.

Hi, I am designing a database schema to store App Store transaction data for our backend system, and I have a question regarding the uniqueness of transactionId. According to the documentation (apple.com), transactionId is a unique identifier for a transaction. However, it is not explicitly clear whether this uniqueness is guaranteed across different environments.Could you please clarify the following points? Is transactionId guaranteed to be unique across both the Production and Sandbox environments? (i.e., Is there any possibility that the exact same transactionId is generated in both environments?) For database design, is it safe to use transactionId alone as a Primary Key? Or is it strongly recommended to use a composite key consisting of both environment and transactionId? Any insights or best practices from Apple engineers or the community would be highly appreciated.Thank you.

I tried to compile the latest mDNSResponder (2881.120.11) for linux and discovered that it simply doesn't build: ../mDNSShared/uds_daemon.c: In function ‘resolve_result_callback’: ../mDNSShared/uds_daemon.c:3629:46: error: ‘request_state’ has no member named ‘resolve_awdl’ 3629 | const mDNSBool is_split_awdl_query = (req->resolve_awdl && question->InterfaceID == AWDLInterfaceID); | ^~ ../mDNSShared/uds_daemon.c:3629:89: error: ‘AWDLInterfaceID’ undeclared (first use in this function); did you mean ‘mDNSInterfaceID’? 3629 | const mDNSBool is_split_awdl_query = (req->resolve_awdl && question->InterfaceID == AWDLInterfaceID); | ^~~~~~~~~~~~~~~ This line was introduced in release 2881.60.4 (Jan 5, 2026), and all of the AWDL-related changes made to uds_daemon in that version look like unfinished code: The line shown above which references a non-existent struct field and nowhere-defined identifier/constant. Two functions in uds_daemon.c define a variable mDNSBool has_split_awdl_query = mDNSfalse; which is unused apart from its (unconditionally false) value being logged. The max-size-check for struct request_state in uds_daemon.h is increased but the struct itself wasn't changed (nor does the release introduce any other changes that might indirectly change the size of the struct) This code is common to all supported targets, so that means all four mDNSResponder releases done this year fail to build on all platforms. I'm a bit astonished how this even happens and has gone unnoticed for this long. Unfortunately it's not clear how to properly report this, the github repo has no issue tracker and the feedback assistant doesn't seem to have applicable options for this.

I’m looking for clarification on what iOS currently allows third-party apps to do in these areas: Siri integration and background voice activation: Can an iOS app implement a custom voice assistant that responds to a wake phrase such as “Hey Nowa” and performs app tasks through voice commands? Could it listen while the app is terminated or the iPhone is locked, similar to Siri? Call recordings: Is there a supported way for an iOS app to access recordings of phone calls made on the user’s iPhone and make them available within the app? I couldn’t find documentation for an API that provides access to these recordings. SMS access: Is there a supported way for an iOS app to access and fetch all SMS and iMessage conversations stored in the user’s Messages app, so they can be viewed within our app? As far as I understand, iOS may not allow these capabilities for third-party apps, but I’d appreciate clarification. If any are supported, could you please point me to the relevant Apple documentation?

Feedback ID: FB24937933 I’m seeing a persistent launch failure across multiple unrelated apps on an iPhone 15 Pro Max. Affected apps include Telegram, Box, LinkedIn, Amazon, Apple Podcasts, Shazam, and others. The behavior is consistent: I launch the app. The app stays on a black or frozen launch screen. After approximately 19–20 seconds, iOS terminates the app. Retrying may occasionally work temporarily, but the problem returns. Crash reports from multiple unrelated apps show essentially the same termination: EXC_CRASH / SIGKILL 0x8BADF00D scene-create watchdog transgression More importantly, the main thread repeatedly shows this pattern: xpc_connection_send_message_with_reply_sync NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY -[__NSURLBackgroundSession setupBackgroundSession] -[__NSURLBackgroundSession initWithConfiguration:delegate:delegateQueue:delegateDispatchQueue:] This appears to indicate that the app’s main thread is synchronously waiting for an XPC-backed system service while creating a background NSURLSession, and the response does not arrive before the scene-create watchdog timeout. I first reproduced this on iOS 26.6.2 and the problem still occurs after updating to iOS 27.0 (24A437). Troubleshooting already performed: • Force restart • Network Settings Reset • Background App Refresh disabled • VPN/proxy disabled • Affected apps deleted and reinstalled • iOS updated from 26.6.2 to 27.0 Because the same stack pattern is occurring across multiple unrelated third-party apps, as well as Apple apps such as Podcasts and Shazam, this does not appear to be isolated to a single application. Apple Support has also told me that similar cases have been reported and that the issue may be addressed in a future software update. Has anyone seen a system-level NSURLBackgroundSession / XPC service enter this kind of stuck state across multiple applications? Is there a known issue involving the background URLSession service or related networking daemon that could cause synchronous XPC calls during app launch to block until the watchdog terminates the process? I have submitted the full crash reports through Feedback Assistant under FB24937933.

Hello all, Looking for guidance for my app. I run a workout studio and the time frames for classes are all in military time. I have tried extensively to have this turned off and I am just unsure what is left to do. Has anyone dealt with something like this?

I'm getting a persistent WeatherKit authentication failure that survives every standard troubleshooting step. Hoping someone from the WeatherKit team can check the backend sync for my Team ID. Team ID: 9CQUMUHB42 Bundle ID: com.martin.MinimalWidgets (app) Bundle ID: com.martin.MinimalWidgets.MinimalWidgetsWidget (widget extension) Error: Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" What I've verified: WeatherKit capability is enabled in Xcode for BOTH the app and widget extension targets WeatherKit is enabled in the App ID configuration for both identifiers in the Developer Portal Confirmed with codesign -d --entitlements :- that com.apple.developer. weatherkit is correctly present and set to true in the signed binaries for both the app and the extension WeatherKit Usage dashboard shows 500,000 calls/month quota, 0 used Cleared the provisioning profile cache at ~/Library/Developer/Xcode/UserData/Provisioning Profiles, ran Download Manual Profiles again Clean Build Folder, deleted the app from device, reinstalled Restarted the test device Waited over 24 hours since first enabling the capability None of the above resolved it — the exact same error persists on every attempt, including today. This looks like a backend entitlement sync issue between the Developer Portal and the WeatherKit auth service rather than a local configuration problem, since the signed entitlements are confirmed correct on my end. Could someone from the WeatherKit team check the sync status for this Team ID / Bundle ID and confirm whether WeatherKit token generation is enabled server-side? Happy to provide any additional diagnostic info (sysdiagnose, device logs, etc.) if needed. Thanks in advance!

We are currently verifying the functionality of CXSetTranslatingCallAction. We tested its implementation in a VoIP app—using Apple's Translate app by default—and confirmed that it works correctly in some instances. However, we have encountered an issue where, under certain conditions, the real-time translation feature becomes unavailable until the device is rebooted. The issue manifests as follows: When the real-time translation feature is enabled in CallKit, a beep sounds accompanied by the announcement "Starting translation," but the translation fails to proceed and terminates immediately. This behavior persists upon repeated attempts. Restarting the app does not resolve the issue; once this occurs, the feature remains unusable until the device itself is rebooted. Since the feature works normally after a device reboot, it does not appear to be a fundamental implementation error; I would like to investigate the root cause of this behavior. What information or steps are required to investigate this? I conducted the test using an iPhone 16 Pro running OS version 26.5. It is the same for both CallKit and LCK.

Hi team, I’m working on an ActivityKit use case where a Live Activity is useful on the Lock Screen, but not in the Dynamic Island. Today, Live Activities appear to be treated as a unified presentation across system surfaces: Lock Screen, Dynamic Island, StandBy, etc. For our app, the Lock Screen presentation is the right user experience, but showing the same activity in the Dynamic Island creates unnecessary persistent foreground UI while the user is actively using the device. Is there any supported way to create a Live Activity that appears on the Lock Screen but opts out of Dynamic Island presentation on supported iPhones? If not, I’d love to request an ActivityKit enhancement that lets developers specify supported presentation destinations for a Live Activity, for example something like: Lock Screen only or Lock Screen + StandBy, but not Dynamic Island This would be useful for apps where the Live Activity is meant to act as a passive lock-screen status/reminder, rather than an ongoing foreground indicator. Thanks!

I am evaluating a local diagnostic design before implementation or deployment and need to identify a public, supported macOS confinement mechanism. Proposed arrangement: A privileged custodian remains outside a separate privileged guardian's process group. The guardian launches a fixed diagnostic parent under a dedicated unprivileged identity. That parent sequentially launches three fixed sandboxed Python workloads, one child at a time. The current termination design targets the guardian's process group. It must not rely on whole-host process scans or indiscriminate killing. The proposed sandbox profiles are allow-default with file/network restrictions; the test-child profiles deny process-fork. We have not established that these restrictions prevent an existing process from changing its own group or session. Is there a public, supported interface or configuration that keeps all workload descendants within the supervisor's termination boundary from the initial child transition through final cleanup, while still allowing the parent to launch its authorized sequential children? In particular, please clarify: Escape through setsid/setpgid, spawn attributes, exec or native-library paths. When enforcement begins and whether descendants can relax it. Behavior when the diagnostic parent or guardian exits. Required privileges, entitlements, and supported OS/SDK versions. If the described sandbox categories do not establish that property, please identify the supported alternative boundary, if one exists. A different boundary would require an explicit design change on our side. I am requesting documented interface behavior and limitations—not private sandbox internals, a review of project code, or an absolute termination guarantee during kernel failure. No experiment has been performed to establish this property.

For our app, we saved a sandbox App Store Server Notifications URL with V2 enabled and independently read the configuration back. A subsequent test-notification request returned HTTP 404 / 4040007. An authenticated sandbox notification-history request shortly beforehand returned HTTP 200. We restored the original settings after collecting diagnostics. The recorded failure is covered by Feedback Assistant report FB24885397. What could explain this discrepancy, and what additional diagnostics would help Apple investigate?