Hi everyone, I’ve been encountering a recurring issue with the App Store Server API over the past 48 hours, specifically regarding the Get Transaction Info endpoint. Endpoint: GET /inApps/v1/transactions/{transactionId} Environment: Production Error Code: 4040010 (TransactionIdNotFound) The Issue When a user completes a purchase in our app, the client-side sends the transactionId to our backend for validation. However, when our server immediately calls the Get Transaction Info API using that ID, it frequently returns a 4040010 error, stating that the transaction ID cannot be found. Key Observations Eventual Consistency Delay: If we implement a retry logic and wait for 2 to 5 minutes, the exact same transactionId eventually becomes queryable and returns a valid signedTransactionInfo. Notifications vs. API: Interestingly, our server receives the App Store Server Notifications V2 (webhook) for these transactions almost instantly. The notifications contain the correct data, but the "Pull" API seems to lag behind the "Push" notification system. Recent Spikes: This behavior started occurring frequently within the last 2 days. Prior to this, the API was almost always near-instant. Questions Has anyone else noticed a spike in 4040010 errors or increased indexing latency in the Production environment recently? Is there a recommended "grace period" or backoff strategy when querying for a new transactionId? Apple's documentation doesn't explicitly mention an expected delay between a successful purchase and its availability via the Server API. Any insights or confirmation of similar issues would be greatly appreciated!

I accidentally deleted all CloudKit containers from the CloudKit Database console, and now I'm unable to create new containers. Both the CloudKit Console website and Xcode are not allowing me to create any new containers. Is there a way to restore the deleted containers? How can I create a new CloudKit container if the console website is not responding? Thank you.

Platform: macOS 26.3.1, M5 Pro MacBook Pro Framework: CoreWLAN Affected applications: NetViews, Air Tool 2, and our own tooling — appears to be specific to the new Wi-Fi 7 hardware Hardware Card Type: chip id: 0x11 api 1.2 firmware [Rev 72.11.260 N1B1 devFused=0] phy [17.1.17.0], core80211 [324.10.260 N1_silicon_b] Firmware: Jan 27 2026 21:18:32 version XBS_BUILD_TAG GIT_DESCRIBE FWID chip id: 0x11 api 1.2 firmware [Rev 72.11.260 N1B1 devFused=0] phy [17.1.17.0], core80211 [324.10.260 N1_silicon_b] Driver: IO80211_driverkit-1540.16 "IO80211_driverkit-1540.16" Jan 27 2026 Background Both issues described below were working correctly on macOS 26 with previous-generation hardware. The regression is specific to the Wi-Fi 7 card shipping in the M5 Pro MacBook Pro. This is not an OS regression — it is a hardware/driver/firmware compatibility issue with the new card under macOS 26. Issue 1: disassociate() + tcpdump/Wireshark -I no longer enters monitor mode Previously, the standard approach of calling disassociate() and then launching tcpdump -i en0 -I or Wireshark -i en0 -I -k would successfully put the interface into monitor mode. On the M5 Pro Wi-Fi 7 card, this no longer works. The capture tool launches but the interface either stays in station mode or enters mode 0 - where there is no connection, but still not able to be a monitor radio. This is the primary regression affecting third-party wireless tools. Issue 2: setWLANChannel reports success but the radio only retunes once As a workaround for Issue 1, we use the built-in Wireless Diagnostics → Sniffer tool to establish monitor mode (which works fairly reliably on this hardware). Once the interface is in monitor mode via that path, we attempt to change the channel using setWLANChannel: let iface = CWWiFiClient.shared().interface(withName: "en0")! let target = iface.supportedWLANChannels()! .first { $0.channelNumber == 6 && $0.channelWidth == .width20MHz }! try iface.setWLANChannel(target) The first call succeeds (eg: channel 48 -> 6) the radio actually tunes to the requested channel and Wireshark captures frames there. Any subsequent call (eg: channel 48 -> 6 -> 1) shows the same apparent success - no error thrown, wlanChannel() updates to reflect the new channel - but the radio does not retune. Wireshark continues capturing on the first changed channel. We have tested with disassociate() and interface power cycling between attempts — neither resets the ability to retune the radio. What we have ruled out Timing: delays between calls make no difference Competing processes holding the interface wlanChannel() returning a stale cache value — it updates correctly, but diverges from actual hardware state after the first channel change Key data point: Wireless Diagnostics Sniffer works The built-in Wireless Diagnostics → Sniffer tool successfully puts the interface into monitor mode on this hardware. This confirms the card and driver are capable - the issue is that the capability is no longer reachable via CoreWLAN or via tcpdump/Wireshark's -I flag. Wireless Diagnostics Sniffer does not support live channel changes, so it cannot serve as a full workaround. The questions Is there a supported path for third-party apps to enter monitor mode on the new Wi-Fi 7 hardware on macOS 26? What is the correct mechanism for changing channels while in monitor mode - is setWLANChannel expected to retune the radio on subsequent calls, or is there a different API intended for this? The fact that Wireless Diagnostics accomplishes both (albeit, not live) confirms the hardware and driver are fully capable - we are looking for the sanctioned equivalent for third-party tools.

Hi everyone, I’ve been encountering a recurring issue with the App Store Server API over the past 48 hours, specifically regarding the Get Transaction Info endpoint. Endpoint: GET /inApps/v1/transactions/{transactionId} Environment: Production Error Code: 4040010 (TransactionIdNotFound) The Issue When a user completes a purchase in our app, the client-side sends the transactionId to our backend for validation. However, when our server immediately calls the Get Transaction Info API using that ID, it frequently returns a 4040010 error, stating that the transaction ID cannot be found. Key Observations Eventual Consistency Delay: If we implement a retry logic and wait for 2 to 5 minutes, the exact same transactionId eventually becomes queryable and returns a valid signedTransactionInfo. Notifications vs. API: Interestingly, our server receives the App Store Server Notifications V2 (webhook) for these transactions almost instantly. The notifications contain the correct data, but the "Pull" API seems to lag behind the "Push" notification system. Recent Spikes: This behavior started occurring frequently within the last 2 days. Prior to this, the API was almost always near-instant. Questions Has anyone else noticed a spike in 4040010 errors or increased indexing latency in the Production environment recently? Is there a recommended "grace period" or backoff strategy when querying for a new transactionId? Apple's documentation doesn't explicitly mention an expected delay between a successful purchase and its availability via the Server API. Any insights or confirmation of similar issues would be greatly appreciated!

在iOS26.4中，新的交易完成后[NSBundle mainBundle] appStoreReceiptURL 获取的是历史票据，未给出新的票据

Hello, We are currently testing subscription purchases in the Sandbox environment, and we are seeing an issue that we do not fully understand. When we attempt a single subscription purchase, multiple purchase signals or transaction events are sometimes delivered from Sandbox for what appears to be just one payment attempt. In some cases this happens twice, and in other cases we have seen it occur as many as five to seven times. The number is inconsistent each time, and we have not been able to identify any clear pattern. At this point, we are not sure whether this is a known instability or limitation of the Sandbox testing environment, or whether there may be something incorrect in our own implementation or configuration. Has anyone experienced similar behavior when testing auto-renewable subscriptions in Sandbox? If so, we would really appreciate any guidance on what to check. Thank you.

Given that we can't use isEligibleForAgeFeatures property on macOS, the documentation states that In macOS, isEligibleForAgeFeatures returns false because the system doesn’t require Age Assurance for the person or device. However, you can still call requestAgeRange in macOS to get the declared age range. But in unsuitable region the requestAgeRange request always returns DeclaredAgeRange.AgeRangeService.Error.notAvailable which is vague, as it might stand for API being unavailable just as well as "You receive this error when the system prompts a person and they decide not to share their age range with your app. ", as per documentation. Unfortunately, this error fires immediately instead of showing any kind of prompt for user, so the description is definitely wrong (or incomplete) in here. Possible solutions: expand Error cases to separate not available API and not available response expand isEligibleForAgeFeatures to properly support macOS Moreover, unlike iOS, there is still no usable tool or algorithm to test given feature for macOS (mock region, mock age, mock source of approval, revoke declared range, etc). Now I get a review with rejection, stating that I don't have age verification mechanisms present in my app. Also I found out that after filling the App Information regarding Age Ratings it spreads to all fresh releases, so even though my newest macOS release doesn't contain age verification mechanisms yet, it should, as iOS release has got this functionality up and running already and I had to check this when filling Age Ratings questionnaire. Now I'm stuck between removing this capability from App Information, so the macOS release can pass and stalling macOS releases until there is a proper usable API to implement Declared Age Range verification properly (at least the same way as on iOS). How should I properly develop and test this feature for macOS before releasing it publicly?

I'm following up on a couple of forum threads from 2020 to get more clarity on the current guidance for supporting multiple XPC services in system extensions. For context, I'm trying to create a system extension that contains both an Endpoint Security client and a Network Extension filter, and I'm seeing indications that the system may not expect this and doesn't handle it smoothly. First: Previous guidance indicated that the system would automatically provide a Mach service named <TeamID>.<BundleID>.xpc to use for communicating with the system extension. However, the SystemExtension man page currently documents an Info.plist key called NSEndpointSecurityMachServiceName and suggests that the default service name is deprecated; and in fact if this key is not set, I find a message in the Console: The extension from () is using the deprecated default mach service name. Please update the extension to set the NSEndpointSecurityMachServiceName key in the Info.plist file. I have accordingly set this key, but I wanted to confirm that this is the current best practice. Second, and more interesting: Another user was trying to do something similar and observed that the Mach service for the endpoint security client wasn't available but the NE filter was. Quinn did some research and replied that this was intended behavior, quoting the EndpointSecurity man page: "If ES extension is combined with a Network Extension, set the NEMachServiceName key in the Info.plist" (which I have also done), and concluding from this: ... if you have a combined ES and NE system extension then the Mach service provided by the NE side takes precedence. However, the current man page does not include this quoted text and says nothing about a combined ES and NE system extension. So I'm wondering about current best practice. If I do combine the ES and NE clients in a single system extension, should they each declare the Mach service name under their respective Info.plist keys? And could there be a single XPC listener for both, using the same service name under each key, or would it be better to have separate XPC listeners? Alternatively, would it be preferable to have each component in a separate system extension? (This would entail some rearchitecting of the current design.)

Hi everyone, I'm running into what appears to be a stuck Family Controls entitlement request and wanted to see if anyone has experienced something similar. Request ID: 9D7MU547QH The request is still showing a status of "Submitted". Context: • Our main app bundle ID was already approved for the Family Controls entitlement. • Two related extensions (ShieldConfiguration and DeviceActivityMonitor) were also approved within a few days. • The remaining request is for a ShieldAction extension, which handles button taps from the shield UI. This entitlement is currently blocking our business's beta testing, so we’re trying to understand whether this is just normal queue delay or if the request might be stuck. Has anyone seen a case where the main app and other extensions were approved but a ShieldAction request remained in "Submitted" for an extended period? If an Apple engineer happens to see this, I’d greatly appreciate any guidance on whether the request might be stuck in the review queue. Thank you!

We are implementing promo/offer codes for our iOS app’s subscription in-app purchases and have several technical questions regarding validation, receipt data, and integration. Could you please provide guidance on the following points? Testing/Validating Custom Codes Without Production Release: How can we validate custom promo/offer codes in a non-production environment? Current documentation indicates promo codes only work in production, requiring app submission and future release date setup for testing. Receipt Data for Redeemed Codes: The receipt currently includes only offer_code_ref_name, not the exact redeemed code (e.g., “ABC123”) entered by the user. Is there a way to retrieve the specific offer code used via receipts, App Store Server API, or other endpoints? Server-Side Validation Best Practices: What are the recommended best practices for server-side validation of offer codes, including using App Store Server API for transaction verification? Passing appAccountToken for Coupons: How can we pass an appAccountToken when users redeem coupon/offer codes (e.g., via presentOfferCodeRedeemSheet or redemption flows)? StoreKit purchase options support it for regular purchases but not redemption sheets. Callbacks on Coupon Redemption: Is there a client-side callback or notification (e.g., via updatedTransactions or StoreKit observers) when a user successfully redeems a coupon code in the app? Server notifications are received, but app-side feedback appears unreliable.

Our app is using the CLLocationManager to wake up the app near an iBeacon and then tries to connect to the accessory via bluetooth and UWB. For this to work in the background we need to create a Live Activity and show the user that the app is doing something. When the app is in the foreground or just recently got into the inactivity mode this works fine and we can use CoreBluetooth/NearbyInteraction even when the app then enters the background mode. But when the app is longer in the background creating a Live Activity via Activity.request() throws an ActivityAuthorizationError.visibility. According to the documentation the LiveActivityIntent is able to workaround this background restriction but I get the same exception when I create the LiveActivity from the perform() method. Is there another API to create Live Activities? Do I need to prepare the LiveActivityIntent somehow?

Environment iOS Version: 26.4 Beta (Build 17E5170d) Xcode Version: 26.4 Beta Framework: AccessoryNotifications, AccessoryTransportExtension Description When implementing AccessoryNotifications.NotificationsForwarding.AccessoryNotificationsHandler, I'm unable to retrieve the URL for sourceIcon from AccessoryNotification. The file.url property throws AccessoryError error 0 with the message "unable to get file URL". Code Sample func add( notification: AccessoryNotification, alertingContext: AlertingContext, alertCoordinator: any AlertCoordinating ) { Task { if let sourceIcon = notification.sourceIcon { do { let url = try await sourceIcon.url // Throws AccessoryError error 0 let data = try Data(contentsOf: url) // Process icon data... } catch { print("Failed to get sourceIcon URL: (error)") // Error: The operation couldn't be completed. // (AccessoryNotifications.AccessoryError error 0.) } } } } Observed Behavior The sourceIcon property is present and its type is correctly reported as public.image: │ sourceIcon : present │ type.identifier : public.image │ type.description : image │ url : (error: The operation couldn't be completed. (AccessoryNotifications.AccessoryError error 0.)) Error details: Error: customError(message: "unable to get file URL") Type: AccessoryError Code: 0 Expected Behavior The file.url property should return a valid URL that allows reading the source icon image data, or the documentation should clarify any limitations or prerequisites for accessing this resource. Questions Is this a known limitation in the current beta? Are there additional entitlements or permissions required to access sourceIcon.url? Is there an alternative API to retrieve the actual image data for sourceIcon? Additional Context The same error occurs when accessing url in both describeNotification (debug logging) and sendAttachment methods contextIcon is typically nil for the notifications tested (e.g., WeChat messages) The notification metadata (title, body, actions, etc.) is correctly received

Hello, I submitted a Family Controls (Distribution) entitlement request on February 25, 2026 for my prayer/productivity app that uses the Screen Time API to block distracting apps. I also submitted requests for two extensions on March 6, 2026: com.prayfirst.prayFirst.ShieldAction com.prayfirst.prayFirst.ShieldConfiguration All three requests still show "Submitted" status in the Certificates, Identifiers & Profiles portal with no progress. I contacted Apple Developer Support (Case #102839422791), and they mentioned I should have received a "follow-up number" after submission — but I never received one. This entitlement is the only blocker preventing me from building and distributing my app. Could a DTS engineer please assist or escalate this? Team ID: BH752TBX9L Thank you.

Could you please provide guidance on the following points: Start Token Throttling Are there any throttling limits or rate restrictions applied to Start Tokens? Token Invalidation Scenarios Under what specific conditions can a Start Token become invalidated? Are there known scenarios that trigger invalidation? Token Regeneration Timeline Once a Start Token is invalidated, how long does it typically take before a new token can be successfully generated and validated? Frequency of Invalidation Is there any documented or expected frequency with which Start Tokens may become invalid, assuming a normal development workflow? Impact on Push Notification Token When a live activity Start Token becomes invalid, does this also cause APNs Push Notification Tokens to be invalidated or refreshed automatically?

We are trying to intercept raw reports from the built-in MacBook haptic trackpad using a DriverKit IOUserHIDEventDriver dext. Our dext installs and activates successfully: OSSystemExtensionRequest finishes with result 0 systemextensionsctl list shows the dext as activated enabled the dext is embedded correctly in the app bundle However, it never attaches to the built-in trackpad IOHIDInterface. ioreg shows the built-in trackpad interface still matched only by Apple’s HID dext. We also observed that Apple’s own HID dext appears to use com.apple.developer.driverkit.builtin, while that entitlement is not available in our provisioning profile. Our dext specifically relies on: IOUserHIDEventDriver::handleReport(...) SetProperties() with kIOHIDEventDriverHandlesReport Questions: Is com.apple.developer.driverkit.builtin required for a third-party IOUserHIDEventDriver to match a built-in internal trackpad IOHIDInterface? Is that entitlement public/requestable, or Apple-internal only? At what stage is it enforced: activation, personality matching, provider attach, or before Start()? If builtin is not available to third parties, is there any officially supported way to receive raw reports from the built-in MacBook trackpad in DriverKit? Our conclusion so far is that activation succeeds, but provider binding to the built-in trackpad fails due to built-in-only authorization/matching.

Crash on CFRelease(res) com.zscaler.zscaler.TRPTunnel-2026-03-02-195306.ips.txt , com.zscaler.zscaler.TRPTunnel-2026-03-02-200554.ips.txt below is the codes, please help how to fix it. { dispatch_block_t block = ^{ //All this dancing is an attempt to work around some weird crash: //seems like ARC is trying to release NULL before assigning new value CFDictionaryRef res = SCDynamicStoreCopyMultiple(store, NULL, keyPatterns); if (res && store) { NSDictionary *nsRes = (__bridge_transfer NSDictionary *)CFPropertyListCreateDeepCopy(kCFAllocatorDefault, (CFPropertyListRef)res, kCFPropertyListImmutable); setDynamicStore(nsRes); } else { ZLogError("SCU:[%s]%s refreshDynamicStore failed", dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL), __FUNCTION__); setDynamicStore(NULL); } if(res) { CFRelease(res); } }; if (dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL) == dispatch_queue_get_label(queue)) { block(); } else { dispatch_async(queue, block); } }

I have been experiencing many issues trying to integrate the Apple AlarmKit in my app. I essentially keeping getting authorization errors. I was wondering if anyone else was experiencing issues like this and if anyone had guidance or a fix for what I am experiencing. I was under the impression that any devices IOS26+ could use the AlarmKit but maybe I am mistaken. Getting (com.apple.AlarmKit.Alarm error 1.) every time I try and enable alarms.

We are assisting a client with their app integration. The client believes that NEPacketTunnelProvider, NEHotspotHelper, and NEHotspotManager extensions stop functioning if the containing app hasn't been launched by the user within some recent window (e.g. 30, 60, or 90 days). We haven't been able to find any documentation supporting this claim. Specifically, we'd like to know: Is there any app launch recency requirement that would cause iOS to stop invoking a registered NEHotspotHelper or NEHotspotManager configuration? Is there any app launch recency requirement that would cause iOS to tear down or prevent activation of a NEPacketTunnelProvider? More generally, does iOS enforce any kind of "staleness" check on apps that provide Network Extension or Hotspot-related functionality, where not being foregrounded for some period causes the system to stop honoring their registrations? If such a mechanism exists, we'd appreciate any pointers to documentation or technical notes describing the behavior and timeframes involved. If it doesn't exist, confirmation would help us guide our client's debugging in the right direction. Thank you.

I am referencing: https://developer.apple.com/documentation/foundation/pausing-and-resuming-uploads Specifically: You can’t resume all uploads. The server must support the latest resumable upload protocol draft from the HTTP Working Group at the IETF. Also, uploads that use a background configuration handle resumption automatically, so manual resuming is only needed for non-background uploads. I have control over both the app and the server, and can't seem to get it to work automatically with a background url session. In other words, making multiple requests to get the offset then upload, easy but I am trying to leverage this background configuration resume OS magic. So anyone know what spec version does the server/client need to implement? The docs reference version 3, however the standard is now at like 11. Of course, I am trying out 3. Does anyone know how exactly this resume is implemented in iOS, and what exactly it takes care of? I assumed that I can just POST to a generic end point, say /files, then the OS receives a 104 Location, and saves that. If the upload is interrupted, when the OS resumes the upload, it has enough information to figure out how to resume from the exact offset, either by making a HEAD request to get the offset, or handle a 409. I am assuming it does this, as if it doesn't, the 'uploads that use a background configuration handle resumption automatically' is useless, if it just restarts from 0. Note, of course making individual POST/HEAD/PATCH requests manually works, but at that point I'm not really leveraging any OS auto-magic, and am just consuming an API that could really implement any spec. This won't work in the background, as the OS seems to disallow random HTTP requests when it wakes the app for URLSession background resumes. As of right now, I have it 'partially' working, insofar as the app does receive the 104 didReceiveInformationalResponse url delegate call, however it seems to then hang; it stops sending bytes, seemingly when the 104 is received. However, the request does not complete. In other words, it doesn't seem to receive a client timeout or otherwise indicate the request has finished. Right now, I am starting a single request, POSTing to a /files end point, i.e. I am not getting the location first, then PATCHing to that, as if I do that, the OS 'automatic' resuming fails with a 409, i.e. it doesn't seem to make a HEAD request and/or use the 409 offset correction then continue with the PATCH. Any idea what could be going on?

Situation: We have an app that only uses location UIBackgroundModes key to restart our app on significant change events as we need it to connect with a BLE device (mounted in the car) when someone starts driving. We cannot use geofence as the car might be used by multiple people so position changes and we don't want to store locations and sent them to multiple users via our servers. So currently we use significant change and just ignore all other location data. During app review we got the following feedback: If the app does not require persistent real-time location updates, please remove the "location" setting from the UIBackgroundModes key. You may wish to use the significant-change location service or the region monitoring location service if persistent real-time location updates are not required for the app features. Question: How to use the significant-change location service without the "location" setting from the UIBackgroundModes key or is there any other way to start the app / connect with the BLE device when it is fully terminated/swiped away? Because the docs state that AuthorizationStatusAuthorizedAlways is required and without the UIBackgroundModes key location that wouldn't be triggered when app is in the background/swiped away. Reference: https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html#//apple_ref/doc/uid/TP40009497-CH2-SW8