We are unable to verify our Apple Pay merchant domains. Apple Developer Portal returns: “Domain verification failed. Review your TLS Certificate configuration to confirm that the certificate is accessible and a supported TLS Cipher Suite is used.” We have confirmed that the verification endpoints are publicly accessible, return HTTP 200, and support TLS 1.2/1.3 with valid certificates and supported cipher suites. The domains are behind Cloudflare. However, when verification is triggered, we do not see an HTTP request from Apple in our Cloudflare request logs. Has anyone experienced a similar issue with Apple Pay merchant domain verification, especially with domains behind Cloudflare? We have also submitted a report through Feedback Assistant.

My MacBook Pro M5 running MacOS Tahoe 26.3 beta fails to detect two identical ASUS ROG Swift OLED PG32UCDM monitors simultaneously. Only one display is recognized at a time. One potential root cause might be that both monitors report identical binary EDID serial numbers (0x01010101), and the MacBook Pro M5 appears to use this value exclusively for display identity rather than combining it with other more detailed information (e.g., port, or alphanumeric serial number). I've verified that the monitor EDID binary serial numbers are in fact identical -- however the alphanumerical serial numbers are not identical. NOTE: This behavior is specific to the MacBook Pro M5 — when connecting both monitors via usb-c to a Mac Mini M4 Pro running the same MacOS Tahoe 26.3 beta, the monitors work fine. The OS detects both and assigns different names to them (PG32UCDM (1) and PG32UCDM (2)). NOTE: I could be wrong about this root cause, I don't have a way to disprove it, though the fact the monitors work fine on a Mac Mini is suspicious. What I have tried: Connecting the two monitors using different monitor ports (one on DisplayPort, another on HDMI, etc.), and different MacBook ports (one on HDMI, another on USB-C, etc.) Bumping down the resolution on the monitors to "1920x1080 (low resolution)" and 30Hz to rule out bandwidth issues. Connecting one, or both, monitors to CalDigit TS5 Plus dock. Neither alternate configuration yields the device recognizing both screens. Using BetterDisplay to import a manually-edited EDID for the screen, with a different binary EDID value, manufacturer name, etc. I've also verified that if I plug in my Apple Studio Display as one of the monitors, then the MacBook recognizes both one of the PG32UCDM monitors and the Studio Display at the same time. The issue seems to occur only when both monitors plugged into it are the same PG32UCDM model. When I have both monitors plugged into my MacBook, each time I disconnect the cable to whichever monitor is currently recognized, it immediately recognizes the other monitor. Plugging the cable for the disconnected monitor back in has no effect. I'm at a loss. Has anyone run into this issue and found a successful workaround that is not one of the approaches I've described above?

I am evaluating a hypothetical file collector that uses fixed approved directory roots. Its requirement includes rename-after-open: if another process moves an opened file or an ancestor outside the approved namespace, the collector must not continue accessing it there. This concerns input reads, directory enumeration, preview reacquisition, and writes to exclusively created output files. Retaining a previously approved descriptor or detecting a move after access does not meet the requirement. I am considering whether Endpoint Security can prevent the relevant namespace mutations before they occur for the complete access interval. No Endpoint Security client has been created or exercised for this candidate. This is a request for a documented, versioned contract, not permission to deploy a client, obtain an entitlement, or change the system. The deadline-mode documentation describes the response to an unanswered authorization within its deadline. The mode values describe deny without killing the client, allow without killing the client, and killing the client as the default. The setter documentation also describes denial of a queue-full AUTH drop under FAIL_CLOSED. I have not found, in the specific pages listed below, an explicit contract for the separate case of client loss. I am not assuming that deadline policy covers disappearance of a client. Could you clarify the following? Pending authorization at client loss For a relevant authorization such as ES_EVENT_TYPE_AUTH_RENAME or ES_EVENT_TYPE_AUTH_UNLINK that is already pending, what exact verdict applies if the matching client crashes, disconnects, is deleted with es_delete_client, or unsubscribes before responding? Please distinguish each case, including when it was the last matching client and when other matching clients remain. Does a configured FAIL_CLOSED deadline policy remain attached to that pending request after client loss? Operations after the last matching client is gone What controls a later rename, reparenting, exchange, unlink, or other relevant namespace mutation after the last matching client has disappeared or unsubscribed? Is there a supported policy that remains effective independently of that client's lifetime? Please distinguish new operations from an authorization that was already pending, including cached decisions and any interval before a replacement client is ready. A supported complete protection interval Is there a supported way, through Endpoint Security or another supported kernel-enforced mechanism, to keep the necessary namespace mutations denied from before the collector's first access until its final read/write ends, despite authorization-client loss, partial setup, or owner death? The mutating actor may be outside the collector's process subtree. A later watchdog termination, restart, or notification of a completed operation would not establish denial during the intervening interval. If protection must end before that interval is complete, please identify the exact limitation. Client types and failure cases Which guarantees differ between es_new_client and es_new_descendants_client? Beyond the unanswered-deadline and full-queue cases, does any deadline mode affect the cases in questions 1 and 2? Please identify any self-process, muting, caching, scope, or actor limitations that prevent the proposed all-relevant-mutator coverage. I am not assuming a descendant-scoped client can authorize operations by unrelated processes. Versioned support and prerequisites For any supported contract, please cite the public documentation or other authoritative reference, applicable released macOS versions, exact API and deployment configuration, and required entitlements, privilege, consent, or system-extension conditions. API introduction metadata alone is not being treated as evidence about an installed target, and an upgrade or privilege change is not assumed. If no public supported mechanism provides the requested interval, an explicit statement of the missing guarantee or required independent enforcement boundary would be useful. Public references reviewed https://developer.apple.com/documentation/endpointsecurity/es_set_deadline_miss_mode(::) https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_t https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_closed https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_open https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_kill https://developer.apple.com/documentation/endpointsecurity/client https://developer.apple.com/documentation/endpointsecurity/es_client_t https://developer.apple.com/documentation/endpointsecurity/es_new_client(::) https://developer.apple.com/documentation/endpointsecurity/es_new_descendants_client(::) https://developer.apple.com/documentation/endpointsecurity/es_delete_client(:) https://developer.apple.com/documentation/endpointsecurity/es_unsubscribe_all(:) The scoped document reviews did not establish the two client-loss cases above; this is not a claim that every relevant Apple document or mechanism has been exhausted. No real data, credentials, private artifacts, logs, or host identifiers are needed for this clarification.

Hello, I submitted a couple of requests with justification for NSE filtering on an app of mine, but I have not received correspondence on either. The initial ticket is RY24AB5J5T, if anyone who reviews them happens to see this post. Happy to hop on a call, exchange emails, or anything else that may be required to process it toward a conclusion. 🙂

We're looking for clarification on how APNs enforces provider authentication token update limits across independent HTTP/2 connections. We operate a production APNs sender using ES256 JWT-based authentication. The sender: Signs a provider JWT using an APNs authentication key. Caches and reuses that JWT for approximately 50 minutes. Opens a new HTTP/2 connection to api.push.apple.com for each notification, then closes it after receiving the response. We want to perform a single-notification delivery test from a separate, short-lived process using the same Production APNs environment. Our concern is avoiding any disruption to the existing production sender. Apple's token-based connection documentation states that using a new authentication token too frequently can cause errors "on the same connection" and that "You can use the same token from multiple provider servers." The APNs response documentation also describes HTTP 429 TooManyProviderTokenUpdates. Questions Throttle scope: Is TooManyProviderTokenUpdates enforced strictly per HTTP/2 connection, or can it apply across connections sharing the same signing key, Apple Developer team, topic, or Production environment? Independent JWT signing: If our test process signs a fresh provider JWT using the same APNs key and sends one notification over a new HTTP/2 connection, could that cause throttling for our production sender, which continues using its previously cached JWT on separate connections? Separate signing keys: Would using a different APNs authentication key under the same developer team isolate token-update throttling, or could limits still be shared at the team or topic level? Recovery behavior: If APNs returns TooManyProviderTokenUpdates, how long does the restriction last? Can existing valid tokens on other connections continue working? Could continuing to send requests with an unchanged cached JWT prolong the restriction? Recommended approach: For a one-time delivery test alongside a production sender, is it preferable to reuse the existing cached JWT across processes rather than independently sign a new one? We have not executed the test because we want to understand the potential impact on production push delivery first. Any guidance from Apple engineers on the enforcement scope, recovery behavior, or recommended testing procedure would be appreciated. Thank you!

Our CarPlay app plays video on the car display through AirPlay video streaming in CarPlay Simulator ("Standard Video Playback"), and falls back to audio when video is unavailable. On a real vehicle (wireless CarPlay, iOS 27.0.1) the iPhone log shows at connection: vehicle supports theme assets: NO supportedCarPlayFeatures: vehicle doesn't support features requiring asset (includes videoPlayback) CarPlay videoPlayback supported: noSo CPSessionConfiguration.supportsVideoPlayback is false and the app can only show Now Playing. The same head unit shows parked video with another phone projection system, so the screen itself is capable. Is this a vehicle-side capability that only the automaker can enable? Is there any supported way for a CarPlay app to show parked video on such a vehicle? A code-level support request is also open (DTS Case-ID 23112107). Thank you.

If I create a BGContinuedProcessingTaskRequest, register it, and then "do work" within it appropriately reporting progress, and before my task has finished doing all the work it had to do, its expirationHandler triggers... does the task later try again? Or does it lose the execution opportunity until the app is next re-launched to the foreground? In my testing, I never saw my task execute again once expired (which suggests the latter?). I was able to easily force this expiry by starting my task, backgrounding my app, then launching the iOS Camera App. My example is just using test code inspired from https://developer.apple.com/documentation/backgroundtasks/performing-long-running-tasks-on-ios-and-ipados let request = BGContinuedProcessingTaskRequest(identifier: taskIdentifier, title: "Video Upload", subtitle: "Starting Upload") request.strategy = .queue BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: nil) { task in guard let task = task as? BGContinuedProcessingTask else { return } print("i am a good task") var wasExpired = false task.expirationHandler = { wasExpired = true } let progress = task.progress progress.totalUnitCount = 100 while !progress.isFinished && !wasExpired { progress.completedUnitCount += 1 let formattedProgress = String(format: "%.2f", progress.fractionCompleted * 100) task.updateTitle(task.title, subtitle: "Completed \(formattedProgress)%") sleep(1) } if progress.isFinished { print ("i was a good task") task.setTaskCompleted(success: true) } else { print("i was not a good task") task.setTaskCompleted(success: false) } } try? BGTaskScheduler.shared.submit(request) Apologies if this is clearly stated somewhere and I'm missing it.

We are an acquirer/payment provider offering Apple Pay. Our merchants use our hosted checkout to accept payments. After a user pays with Apple Pay on our checkout, the Wallet transaction record shows our checkout domain as the payee. We would like it to display the merchant’s brand/name so users can recognize or contact the merchant. Is there any parameter or configuration that controls what Wallet shows as the payee? For example, can this be set via a specific field/parameter, or is it strictly derived from the Merchant ID’s display name (or other Apple Pay configuration)? What is the correct approach for a PSP/acquirer to have the merchant’s brand shown in Wallet transaction record? Additional detail: The field in question is the merchant/payee name shown in the Apple Wallet receipt—directly under the transaction amount at the top of the receipt, and again beneath the “Total” line.

iOS/macOS 26 added share access requests: CKShare.allowsAccessRequests, CKShare.requesters, CKShareRequestAccessOperation, and deny/block requesters on CKShare. My app uses this flow on iOS, macOS and watchOS: The owner sets allowsAccessRequests = true and shows the share URL as a QR code. The joiner runs CKShareRequestAccessOperation for that URL. The owner reads requesters and approves (adds a participant), denies or blocks. I'd like to do part of this from the web. I can't find anything about access requests in the CloudKit Web Services reference or the CloudKit JS docs. Is there a supported way to read/set allowsAccessRequests, submit an access request, or list/approve/deny/block requesters through Web Services or CloudKit JS? If not, is there a recommended workaround? I've filed this as a suggestion: FB25372887

Hi Apple team, We’re evaluating how we generate appAccountToken for in-app purchases. For privacy and security reasons, rather than using a stable UUID associated with an account across all purchases, we’re considering generating a different opaque value for each purchase/context. Internally, our backend would maintain the mapping needed to associate each value with the correct customer account and, potentially, additional purchase context. In other words, the same customer account may result in different appAccountToken values across separate purchases, while our backend can still deterministically resolve each token to the correct account. We’d like to confirm: Does Apple expect or recommend that appAccountToken remain stable for the same app account across purchases? Are there any concerns with this approach for non-subscription / one-time purchases, assuming we maintain the account association on our backend? Our goal is to avoid exposing a stable account-correlatable identifier while still maintaining reliable server-side attribution. Thanks!

App Store Server Notification returns successful purchase while customer's payment remains Pending We have encountered an edge case with a Non-Renewing Subscription and would appreciate clarification on the expected developer behavior. Steps to reproduce User initiates an in-app purchase using a credit card. The purchase succeeds in the app. Our backend receives an App Store Server Notification V2 (ONE_TIME_CHARGE). We successfully verify the signed JWS transaction. The same transaction is also returned by the App Store Server API. Based on the verified transaction, we grant the user's entitlement. However, on the customer's Apple account: The purchase is shown as Pending in Purchase History / Report a Problem. The customer reports that their credit card has not yet been charged. Question From a developer's perspective, should entitlement be granted immediately after receiving a valid App Store Server Notification and successfully verifying the transaction, even if the customer's purchase is still shown as Pending? Is there any App Store Server API or transaction field that indicates the payment has not yet been settled, allowing developers to delay granting entitlement until the payment is finalized? Or is the expected implementation to grant entitlement upon successful transaction verification and revoke it only if Apple later sends a refund notification? Any clarification on the expected workflow would be greatly appreciated. Thanks in advance. :)

Hello, I’m experiencing an issue with App Store Server Notifications Version 2 in the sandbox environment. Initially, an old sandbox callback URL was configured. I then replaced it with a new callback URL in App Store Connect. The new URL was saved successfully, but newly created sandbox TEST notifications continued to be sent to the old URL. To investigate further, I removed both the production and sandbox callback URLs completely. App Store Connect showed both fields as empty, and the App Store Connect API returned null for the corresponding URL attributes. However, newly created sandbox TEST notifications were still sent to the same old URL. I later used the “Modify an App” API to configure the new production and sandbox callback URLs. The PATCH request returned HTTP 200, and a subsequent GET request confirmed the new URLs and Version 2 settings. Despite this, new sandbox TEST notifications continued to use the old hostname in the HTTP Host header. I confirmed that these are new notifications, not retries: Every test returns a new testNotificationToken. The notificationUUID matches the UUID in that new testNotificationToken. The new callback URL is publicly accessible over HTTPS. The new URL returns HTTP 200 and doesn’t redirect to the old URL. The behavior is therefore: Configure a new URL → notifications still go to the old URL. Remove all configured URLs → notifications still go to the old URL. Update the URLs through the App Store Connect API → notifications still go to the old URL. It appears that the notification delivery service is using a stale callback configuration that isn’t synchronized with App Store Connect. Is there a separate cache or routing configuration for App Store Server Notifications? Is there a way to force the effective callback URL to refresh? Thank you.

We are a Payment Service Provider (PSP)/Payment Processor/Payment Gateway and have completed the Apple Pay integration and successfully tested transactions in the Sandbox environment. We are now planning to move the integration to Production and would like to understand the prerequisites, certification requirements and process involved in enabling Apple Pay for our merchants. Could you please clarify the following: Production Enablement: What are the mandatory prerequisites for a PSP/Payment Processor/Payment Gateway to move from Sandbox to Production? Certification: Is formal certification or approval from Apple required for the Payment Processor before Go-Live? Certificates: Are separate Production Payment Processing and Merchant Identity Certificates required? Merchant Onboarding: What is the process for onboarding and enabling individual merchants under our PSP/Payment Processor setup? Any provisions for Bulk On-boarding? Testing & Validation: Are there any mandatory test scenarios or validations required before Production enablement? Production Access: What approvals, configurations or access enablements are required from Apple's end? Go-Live Process: What is the recommended sequence of activities and expected timeline for Production activation?

Subject: Supported macOS containment for a sandboxed worker after controller failure I'm investigating an Apple Silicon/macOS architecture in which an untrusted, signed, sandboxed worker must be independently containable by a separate trusted supervisor. The worker needs only a narrow authenticated communication channel. It requires no direct network access, external operational credentials, privileged file access or authority to launch helpers. I understand that App Sandbox does not inherently prevent child-process creation, and that RLIMIT_NPROC alone does not prevent every form of execution delegation. Could you clarify: Is there a public, supported macOS mechanism to deny all worker-originated subprocess creation and execution delegation at launch, while retaining one restricted communication channel? Alternatively, is there a supported mechanism for a surviving supervisor to identify, terminate and positively verify the complete execution domain of a worker, including any descendants, after its controller crashes or is suspended? What guarantees and limitations apply to stable identity, process exit, automatic relaunch and loss of the supervisor? I'm specifically seeking supported operating-system guarantees, not private sandbox profiles, polling, heartbeat inference or best-effort process-tree enumeration. The goal is to determine whether a bounded synthetic containment experiment is technically justified. No production implementation has been attempted.

Hello, Our first release was rejected under Guideline 2.1(b) because subscriptions were unavailable during App Review. We have been unable to reproduce the issue and would appreciate guidance on further diagnostics. Review environment App version: 1.0.0 (9) Device: iPad Air 11-inch (M3) OS: iPadOS 27.0.1 Internet connection: Active, according to the review message The app integrates StoreKit through RevenueCat and offers three auto-renewable subscriptions. We verified that : The Paid Apps Agreement, banking information, and tax forms are active. All three subscriptions and their subscription group are included in the submission. The subscriptions are available in all countries and regions. The submitted build uses the RevenueCat App Store SDK key, rather than a Test Store key. We tested subscription loading 15 times across two networks, including on iPad. Prices loaded successfully, and we completed a sandbox purchase that unlocked Premium. Additional diagnostics on an iPad Air 11-inch (M3) simulator running iPadOS 26.5 returned all three products both through a direct StoreKit Product.products(for:) request and through RevenueCat. No local StoreKit configuration file was attached. We have not reproduced the exact iPadOS 27.0.1 review environment. The simulator runtime is unavailable through our installed Xcode. The rejection message states that subscriptions were unavailable, but does not identify whether product retrieval failed, the subscription options were missing, or a purchase attempt failed. We are asking App Review for those details and a retry. We were wondering: What additional diagnostics would help investigate product availability failures that occur only during App Review? Are there sandbox account or storefront conditions we should test beyond successful product loading and sandbox purchases? Is there a recommended way to collect useful StoreKit error information from a review session when the failure cannot be reproduced locally? Thanks !

After updating to the public release of Xcode 27.2 (27B52), I'm seeing this warning in Apple's StoreKitTest framework: **File**: `SKTestTransaction.h`, line 34 **Warning**: `'SKPaymentTransactionState' is deprecated: first deprecated in iOS 18.0` The warning recommends using `PurchaseResult` from `Product.purchase(confirmIn:options:)`. Is this a known issue?

Hi Apple Developer Support, I have performed additional experiments to investigate whether AccessoryControlDevice.current(for:) and update(_:) can be used from a custom ExtensionFoundation extension. The results have helped narrow down the issue. 1. Host app registration succeeds The host app successfully obtains the accessory from its AccessorySetupKit session and registers the placement capability: try await AccessoryControlDevice.register( accessory, capabilities: [.placement] )Log: [ASK] AAK 步骤0 ASK配件 id=22E9E2E0-46B4-9435-C0C2-4F16FB6A0568 name=Buds Pro 2 inSession=true sessionCount=1 placement=inEar state=authorized source=session.accessories sessionActivated=true caps=placement [ASK] AAK 步骤1(主App) register 成功 placement=inEar id=22E9E2E0-46B4-9435-C0C2-4F16FB6A0568The registration call completes successfully. 2. Custom ExtensionFoundation extension launches successfully I created a custom extension point using: AppExtensionPoint.Definition AppExtensionPoint.Bind AppExtensionPoint.Monitor AppExtensionProcess The host app successfully discovers the extension and launches it. Logs: [ASK][PLC] 扩展点构造成功 id=com.nothing.smartcenter.placement [ASK][PLC] Monitor 结果 identities=1 stateIdentities=1 unapproved=0 disabled=0 [ASK][PLC] 发现扩展 bundle=com.nothing.smartcenter.placement point=com.nothing.smartcenter.placement [ASK][PLC] AppExtensionProcess 创建成功 [ASK][PLC] XPCSession 创建成功 [ASK][PLC] XPCSession activate 成功 [ASK][PLC] sendSync 成功 —— 扩展已响应，进程确实起来了Therefore, the custom extension is installed, discovered, launched, and able to communicate with the host app through XPC. 3. AccessoryControlDevice.current(for:) still fails inside the extension Inside the running extension, I obtain the accessory from its AccessorySetupKit session. The session contains one accessory. However, calling: let device = try await AccessoryControlDevice.current( for: accessory )consistently fails with: AccessoryControlDevice.Error.invalidated Request invalidatedLogs: [ASK][PLC] 实验3-current 请求已送达 op=probe worn=false [ASK][PLC] e3 扩展回传： ask-session 复用 count=1 [ASK][PLC] e3 扩展回传： current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedThe same result occurs when attempting the placement update experiment: [ASK][PLC] 实验4-offHead 请求已送达 [ASK][PLC] e4off 扩展回传： ask-session 复用 count=1 [ASK][PLC] e4off 扩展回传： current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedBecause current(for:) fails, I have not yet been able to verify whether update(_:) itself works. 4. Questions for Apple I would appreciate clarification on the following points: Does AudioAccessoryKit support custom ExtensionFoundation extensions? Specifically, are extensions created using AppExtensionPoint.Definition and AppExtensionPoint.Bind, and launched through AppExtensionPoint.Monitor and AppExtensionProcess, considered valid app extensions for AudioAccessoryKit? Does AccessoryControlDevice.current(for:) require a specific system-defined extension point or extension type, rather than a custom extension point? Does AudioAccessoryKit require any additional entitlement, capability, extension configuration, or authorization for current(for:) to succeed? Is the ASAccessory instance required by current(for:) expected to be obtained from the same ASK session used by the host app during register(), or can the extension obtain the accessory from its own ASK session? What does AccessoryControlDevice.Error.invalidated / Request invalidated specifically indicate in this situation? Is there a way to obtain more diagnostic information about why the request was invalidated? Is there an official sample project demonstrating the complete integration of AccessorySetupKit, AudioAccessoryKit placement updates, and the required app extension? Environment iOS: 26.4 Accessory: Nothing Ear / Buds Pro 2 (internal model B172) Frameworks: AccessorySetupKit, AudioAccessoryKit, ExtensionFoundation, CoreBluetooth Host app bundle ID: com.nothing.smartcenter Custom extension point: com.nothing.smartcenter.placement At this point, BLE communication, AccessorySetupKit pairing, host-side AudioAccessoryKit registration, extension discovery, extension process launch, and XPC communication are all working. The remaining blocker is that AccessoryControlDevice.current(for:) returns Request invalidated even when called inside the successfully running custom extension. Could you please clarify whether this custom ExtensionFoundation architecture is supported by AudioAccessoryKit, or whether a specific Apple-defined extension type is required? Thank you for your help.

Hi everyone, I'm developing a third-party Bluetooth audio accessory and investigating AudioAccessoryKit placement updates on iOS 26.4. My goal is to update the accessory's wearing state (for example, .inEar / .offHead) based on BLE notifications from the accessory. Implementation flow Pair the Bluetooth accessory using AccessorySetupKit. Obtain the paired ASAccessory. Register the accessory in the host app: try await AccessoryControlDevice.register( accessory, capabilities: [.audioSwitching, .placement] )Attempt to retrieve the registered device: let device = try await AccessoryControlDevice.current(for: accessory)However, current(for:) consistently fails with: AccessoryControlDevice.Error.invalidated Request invalidatedBLE communication status The BLE communication itself appears to be successful. The following logs show that the command was sent and the accessory returned a response: [ASK] cmd didWrite ok 68745353-1810-4B13-83A2-C1B21B652C9B notifying=false [ASK] cmd toSend mac=2a:e6:e7:eb:be:2c model=B172 bytes=5560014FC000000F status=connected shaking=false [ASK] cmd write direct mac=2a:e6:e7:eb:be:2c bytes=5560014FC000000F chars=10 peripheral=2 delegate=Optional<CBPeripheralDelegate> connected=connected [ASK] cmd reply ok uuid=CA235943-1810-45E6-8326-FC8CA3BC45CE bytes=5560014F4001000F [ASK][PLC] Experiment 4 - inEar request delivered, op=update worn=true [ASK][PLC] Experiment 4 - inEar current baseline: current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedThe BLE command is successfully delivered to the accessory, and the accessory responds. However, the AudioAccessoryKit API still returns invalidated. Questions Does AccessoryControlDevice.current(for:) require a specific app extension context, entitlement, or authorization? Is it expected to call current(for:) from the host app, or must it be called from an app extension? Does registering .placement and .audioSwitching in the host app guarantee that the accessory can subsequently be retrieved using current(for:)? Are there any additional requirements for the accessory, firmware, or system-side registration before current(for:) can succeed? Is there a known issue with AccessoryControlDevice.current(for:) returning Error.invalidated on iOS 26.4? I understand that AccessoryControlDevice.update(_:) is documented as an API that must only be called from an app extension. I'm trying to determine whether the failure of current(for:) in the host app is expected behavior or indicates a registration/configuration problem. Any sample code, implementation guidance, or clarification from Apple engineers would be greatly appreciated. Thanks!

I’m testing In-App Purchases in the sandbox on a real iPhone. Auto-renewable subscriptions work correctly with the same app build, bundle ID, and sandbox tester account: com.aifalling.sides.vip.monthly com.aifalling.sides.vip.yearly However, a non-consumable product can’t be purchased: Product ID: com.aifalling.sides.vip.onetime App Store Connect IAP Apple ID: 6794812888 Type: Non-Consumable Status: Ready to Submit Bundle ID: com.aifalling.sides The native StoreKit payment request fails immediately with: The purchase identifier was invalid. The wrapper reports error code 700605. I verified the non-consumable product through the App Store Connect API: Product ID exists and is returned by the API One localization exists: zh-Hans A price schedule is configured, including a base territory and prices Availability includes China (CHN) and many other territories availableInNewTerritories is true I waited more than one hour after the latest metadata changes I completely removed the app, rebuilt/reinstalled the custom development build, and retried The same signed build can successfully purchase the two auto-renewable subscriptions This is the first non-consumable IAP type for this app. The app and IAPs have not been submitted for App Review yet because I’m trying to complete sandbox testing first. Does a non-consumable IAP require any additional App Store Connect setup or association that an auto-renewable subscription doesn’t require for sandbox testing? Is Ready to Submit sufficient for sandbox testing of a non-consumable product in this situation? Any guidance would be appreciated.

Hello Apple Developer Community, We are developing a hardware diagnostic solution consisting of a macOS desktop application and a companion iOS application. Our iOS application is currently distributed through Apple TestFlight for testing purposes. The application installs and functions correctly when users download it manually through TestFlight. However, we are facing an issue when attempting to automatically install the same iOS application onto iPhones connected to our macOS application via USB. Our Intended Workflow A user connects one or multiple iPhones to a Mac using USB cables. Our macOS application automatically detects the connected devices. The macOS application initiates installation of our iOS diagnostic application onto the connected iPhones. The iOS application performs hardware diagnostic tests. Test results are transferred back to the macOS application. Once testing is completed, the iOS application can be removed from the connected devices. Current Issue When installing the iOS application manually through TestFlight, everything works correctly. However, when attempting to install the application programmatically from our macOS application over USB, we encounter a developer recognition or trust-related error. Our objective is to support commercial hardware diagnostic testing on customer-owned iPhones without requiring users to manually install the application, enable Developer Mode, trust developer certificates, or register individual device UDIDs. Questions Is there an officially supported Apple API, framework, or method that allows a macOS application to programmatically install an iOS application onto USB-connected iPhones? Is this functionality available for applications distributed through TestFlight, or does it require an App Store production release? Can installation be initiated on customer-owned, unmanaged iPhones without requiring Developer Mode, manual certificate trust, or device registration? Are there specific code-signing, provisioning profile, or distribution requirements for installing an iOS application through USB? Does Apple provide a supported solution for deploying diagnostic applications to multiple USB-connected iPhones simultaneously? If direct USB installation is restricted, what alternative Apple-supported workflow would be recommended for commercial device diagnostic and refurbishment applications? Additional Information Our iOS diagnostic application and macOS desktop application have already been developed, and the core diagnostic functionality is working. The remaining challenge is determining the correct Apple-supported method for installing the iOS companion application automatically onto connected devices. We would appreciate guidance from Apple engineers or developers who have experience with USB-based iOS application deployment, device management, or commercial diagnostic solutions. Thank you for your assistance.