Hi everyone, I observed a behavior with AirPrint from an iPhone and wanted to confirm if this is expected behavior from iOS. Scenario tested: File type: Photo Print-quality selected by the user: Normal Observation (from packet capture): When checking the PCAP for the request sent from the iPhone, the print-quality attribute is always sent as high, even though the user selected Normal in the UI. Question: Is this an expected behavior in iOS/AirPrint where photos are always sent with print-quality=high regardless of the user-selected print quality? Or could this be a bug?

I have a custom hardware board that I want to communicate serially with from an iPad. Should I use the DriverKit route or the MFi route?

I have a feature that relies on Apple Universal Links, which requires the apple-app-site-association file. I made some changes to this file a week ago, but I noticed that the corresponding file still hasn’t been updated when queried via: https://app-site-association.cdn-apple.com/a/v1/x When I query directly from our server, I can see the latest file here: https://x/.well-known/assetlinks.json Could anyone please help us update the file in the CDN? Thank you.

Hi Team, I want to retrieve the list of nearby Wi-Fi networks (SSIDs) directly inside the app. Currently, I can see the available Wi-Fi networks by going to Settings → Wi-Fi on the device, but I would like to access that scan list programmatically within my application. I am developing the app using the Angular Ionic platform. On Android, I am able to get the nearby Wi-Fi scan list using the npm package @capgo/capacitor-wifi (v8.1.8). However, on iOS, the scan results are not being returned. If anyone has experience with this or knows how to achieve Wi-Fi scanning on iOS in Ionic/Capacitor, please let me know. Thanks.

Hi Team, I want to retrieve the list of nearby Wi-Fi networks (SSIDs) directly inside the app. Currently, I can see the available Wi-Fi networks by going to Settings → Wi-Fi on the device, but I would like to access that scan list programmatically within my application. I am developing the app using the Angular Ionic platform. On Android, I am able to get the nearby Wi-Fi scan list using the npm package @capgo/capacitor-wifi (v8.1.8). However, on iOS, the scan results are not being returned. If anyone has experience with this or knows how to achieve Wi-Fi scanning on iOS in Ionic/Capacitor, please let me know. Thanks.

Hello, I’m trying to understand which Apple subscription offer best fits a coupon-like flow in our app. Our ideal case is a 1-month Pro benefit that users can trigger inside the app: without entering a code manually possibly more than once over time then continue into a normal paid auto-renewable subscription Ideally, this would work for new, existing, and lapsed users, and if possible, even for users who are already actively subscribed (though that part is not required). From the docs, I understand that: Offer Codes require redemption Promotional Offers are for existing or previously subscribed users Introductory Offers are for new eligible users Win-Back Offers are for lapsed subscribers So my questions are: Is there any Apple-supported way to do this without manual code entry? Can the same user receive this kind of 1-month benefit multiple times over time? Which offer type is the closest fit? Is this use case partly incompatible with Apple’s subscription system? Thanks.

Hi, I'v got the error by using NEHotspotConfiguration to connect a wifi spot but get:NEHotspotConfigurationErrorDomain code=8. I hope to get the same result as when scanning the code with the system camera. A pop-up window will appear, and I just need to click "Join" to successfully connect. Here's the logs: [OneAppWifi][iOS] handleCheckWifiEnabled start (iOS 12+) [OneAppWifi][iOS] handleCheckWifiEnabled pathUpdateHandler status=satisfied [OneAppWifi][iOS] handleConnectWifi start, ssid=OPPO Find X6 Pro, pwd=len=16, authType=Optional("sae"), hidden=false [OneAppWifi][iOS] handleConnectWifi cancelPendingConnection before new request ssid=OPPO Find X6 Pro [OneAppWifi][iOS] cancelPendingConnection called, errorCode=nil, currentSsid=nil [OneAppWifi][iOS] cancelPendingConnection silent cancel, just clear pendingConnectResult [OneAppWifi][iOS] handleConnectWifi apply completion with error, domain=NEHotspotConfigurationErrorDomain, code=8, userInfo=["NSLocalizedDescription": internal error.] [OneAppWifi][iOS] resolveNEError NEHotspotConfigurationErrorDomain code=8 [OneAppWifi][iOS] resolveNEError systemConfiguration / internal, map to connection_failed [OneAppWifi][iOS] handleConnectWifi resolved as failure errorCode=Optional("connection_failed") for ssid=OPPO Find X6 Pro [OneAppWifi][iOS] firePendingResult value=["success": false, "errorCode": Optional("connection_failed")], currentSsid=Optional("OPPO Find X6 Pro")

Hey We have noticed a change in the retry behavior of Apple Server Notifications webhooks V2 starting around March 12–13, 2026. Previously, when our webhook endpoint returned an HTTP 400 response, Apple would retry the notification delivery multiple times according to the documented retry policy. However, beginning around March 12–13, it appears that Apple no longer retries the webhook when a 400 response is returned. The notification is sent only once and no further retry attempts are made. From our understanding of the documentation, retries should occur when delivery fails, and historically we observed retries even for some 4xx responses. We would like to confirm: Has Apple recently changed the retry behavior for Server Notifications? Are HTTP 4xx responses (specifically 400) now considered terminal failures that will not trigger retries? Is this change intentional or related to a rollout in the webhook delivery system? We have called the "Notification History" endpoint for some users who purchased a sub and we are only getting one attempt with the following data in it: { attemptDate: 1773469202552, (2026-03-14T06:20:02.552Z) sendAttemptResult: 'UNSUCCESSFUL_HTTP_RESPONSE_CODE', } This was 2 days ago, based on the docs, the user should have a few attempts at least. This behavior change affects systems that rely on retries to handle temporary validation issues or transient failures. Thanks!

Testing copyfile on a folder on an external volume (which takes a bit a of time) I'm running into an issue where copyfile gets to the end of the operation and then just fails. In the callback I can see that the failure occurs on a .DS_Store file inside the folder. So for a .DS_Store it is simple enough for me to just ignore the error and return COPYFILE_SKIP but the somewhat more concerning issue here is that the true error reason is seemingly not reported? In the callback if I read errno it is 0. When copyfile returns it returns -1 after I return COPYFILE_QUIT (and errno is 0) so I don't know what the error is or the appropriate way to handle it. For .DS_Store just skipping seems reasonable but when copying a folder it may be appropriate to get the true failure reason. But checking the last path component of source path seems like a hack way to handle errors. If a file in the copying folder with important user data I can't just silently skip it - it isn't clear to me how I should properly proceed in a situation where I can't get the actual reason for the failure.

Hello, I submitted a Network Extension entitlement request (Packet Tunnel Provider) and opened case 102837721995. The case history says Apple sent a message on March 12, but I did not receive it and cannot reply through the support portal. Could someone from Apple Developer Support check the case? Also, it is possible that I misunderstood something or submitted the wrong entitlement request. My application will use WireGuard to establish the VPN connection. If a different entitlement is required for this scenario, please let me know. Thank you.

Hi, my app was rejected because IAP were not present in the app. I followed guidelines more carefully and filled all buisness detail since then. And now I have: StoreKit Configuration in XCode is set to None, Products (subscription + consumable product) are already approved (from the previous review) Paid Apps Agreement - active Bank account - active Tax forms - active Compliance - active Problems: When trying to test it with TestFlight + sandbox account, StoreKit is returning zero products. When trying to check my products by "initiate transaction" from Sandbox App Store manage dashboard I am getting an error "This item is not available" I am totally stuck and don't know what to process next. Unfortunately API.

We are implementing Apple Pay In-App Provisioning in our issuer iOS application and are encountering a HTTP 500 error returned from Apple servers during the provisioning flow. The issue occurs after generating the encrypted payload and attempting to complete the provisioning process. The Apple service responds with 500 Internal Server Error, preventing the card from being added to Wallet. We would appreciate assistance identifying whether this is caused by: • a payload formatting issue, • cryptographic material mismatch, • entitlement / configuration issue, • or a server-side issue. Environment Platform • iOS: 26.3.1 • Device: iPhone 13 mini • Xcode: 26.3.1 Apple Pay configuration • In-App Provisioning entitlement enabled • Issuer app authorized by Apple for provisioning • Payment Network: Mastercard • Token Service Provider (TSP): MDES Testing environment • Production • App distribution method: TestFlight Provisioning Flow Overview Our implementation follows the standard Apple Pay In-App Provisioning flow: 1. User taps Add to Apple Wallet in issuer app. 2. App presents PKAddPaymentPassViewController. 3. App receives: • Apple public certificates • nonce • nonceSignature 4. Issuer backend generates: • encryptedPassData • activationData • ephemeralPublicKey 5. These values are returned to the app. 6. App constructs PKAddPaymentPassRequest. 7. Wallet attempts provisioning. At this point the request fails and Apple servers return HTTP 500. We see this in the system console, with the phone having Wallet debugging profile installed. Checklist – Common Issues Verified Based on the Apple Pay In-App Provisioning demo guidance, we verified the following configuration items. Entitlements • com.apple.developer.payment-pass-provisioning enabled • Apple Pay capability enabled in Xcode • Correct Team ID and bundle configuration App configuration • PKAddPaymentPassViewController used for provisioning • PKAddPaymentPassViewControllerDelegate implemented • generateRequestWithCertificateChain implemented correctly Cryptographic data • encryptedPassData • activationData • ephemeralPublicKey All values are generated by our issuer backend and returned to the app Feedback ID: FB22249031 (In app provisioning error 500)

Hello everyone, We've encountered a blocking issue while integrating Apple Pay on the Web within a Salesforce Commerce Cloud (SFCC) environment. The session fails immediately after a successful user authentication. Problem Summary: After a user authenticates a payment with Touch ID or Face ID, the Apple Pay sheet showing error "Payment not completed" message. The core of the issue is that the onpaymentauthorized event handler is never invoked in our client-side JavaScript. As a result, the corresponding server-side SFCC paymentAuthorized hooks are never triggered, and we cannot obtain a payment token to complete the transaction. Also, No console logs are observed. Observed Flow of Events: The ApplePaySession proceeds correctly through the initial callbacks. We have verified through server-side logs that the corresponding SFCC platform hooks (getRequest, prepareBasket, shippingContactSelected, shippingMethodSelected) fire and complete successfully. The payment sheet correctly updates with shipping costs and the final transaction amount. Failure Point & Steps to Reproduce: A user initiates an Apple Pay transaction within our SFCC site. They select their shipping contact and method. The payment sheet updates the total amount. The user taps the "Pay" button and authenticates successfully via Touch ID / Face ID. Failure: The sheet immediately displays "Payment not completed" error. The onpaymentauthorized event is never fired on the client, and no paymentAuthorized calls reach our SFCC backend. We have confirmed this behavior is reproducible even when using the standard plugin_applepay provided by SFCC. There are no associated errors in the browser's JavaScript console or any server-side logs, as the process appears to fail within the native Apple Pay session before control is returned to our client-side code. Our Questions: Given this is occurring within an SFCC integration, we are trying to understand what could cause the session to terminate at this specific point. Are there internal validation checks that occur after successful user authentication but before the onpaymentauthorized event is dispatched? What configuration issues (e.g., in the ApplePayPaymentRequest, merchant identity certificate, etc.) are known to cause a failure at this exact step, especially within a platform integration like SFCC? Is there any additional client-side logging or debugging we can enable to get more insight into the internal state of the ApplePaySession? Any guidance from Apple engineers or other developers who have integrated Apple Pay with SFCC would be greatly appreciated. Thank you

Hello, I am investigating a case where two different transaction IDs appear to refer to the same purchase, and I would like clarification on whether this behavior is expected. Additional context StoreKit version: StoreKit 1 (SKPaymentTransaction) Environment: Production Product type: Auto-renewable subscription Transaction sources The values are obtained from the following APIs: transaction_id from SKPaymentTransaction https://developer.apple.com/documentation/storekit/skpaymentqueue receipt_data from the App Store receipt https://developer.apple.com/documentation/foundation/bundle/appstorereceipturl Observed behavior After an In-App Purchase completes, the app receives: a transaction_id from SKPaymentTransaction the corresponding receipt_data for the purchase When inspecting the receipt, the transaction_id inside latest_receipt_info differs from the transaction_id received directly from the purchase transaction. For clarity: A = transaction_id received from the purchase flow (SKPaymentTransaction) A' = transaction_id found in receipt_data.latest_receipt_info The two values are different, but they differ only by 1. Additional observation The original_transaction_id for A and A' is identical, which suggests that both transaction IDs belong to the same subscription purchase chain. Pattern observation on the ID difference We have observed that the difference between A and A' is consistently exactly 1 (i.e., A' = A + 1) across multiple transactions, not just a single case. This appears to be a reproducible pattern rather than a coincidence. This observation raises an additional question (Question 6 below). API verification When calling: GET /inApps/v1/transactions/{transactionId} Both A and A' return what appears to be the same purchase record. The response data is effectively identical except for the transactionId field. However, when calling: GET /inApps/v2/history/{transactionId} A does not appear in the transaction history only A' appears in the history response Questions If A does not appear in transaction history, where does this transaction ID originate from? Why does Get Transaction Info (/inApps/v1/transactions/{transactionId}) return a valid response for A even though it is not present in the transaction history? Why do A and A' both resolve to what appears to be the same purchase? In this situation, which transaction ID should be treated as the canonical transaction ID for server-side validation? Is this difference related to how StoreKit 1 (SKPaymentTransaction) and the App Store Server API represent transactions? Is the consistent off-by-one difference between the transaction_id from SKPaymentTransaction and the one recorded in latest_receipt_info an intentional behavior of StoreKit 1's internal transaction ID assignment? Specifically, we are wondering whether StoreKit 1 applies some form of internal offset when delivering the transaction ID to the client, while the App Store server records a different (adjacent) ID in the receipt. If so, is this documented anywhere? Note We are currently in the process of migrating to StoreKit 2, but this behavior was observed while investigating our existing StoreKit 1 implementation. Any clarification would help us better understand the correct transaction model during the migration.

I am developing an app used by public safety agencies. Part of the app is used to determine live agency staffing using geofences. For example, a geofence exists around a station, and when a user enters or exits that geofence, the app updates the staffing count at that station in real time. The issue I am having is reliably detecting when a user enters or exits the geofence while the app is killed (meaning the user force quit the app from the app launcher). I understand that iOS can relaunch an app in the background if the system terminated the process using Region Monitoring, but I haven't gotten a clear answer about whether or how this is possible if the user kills (force quits) the app. Thank you in advance for your assistance.

We are evaluating the new behavior mentioned in the Nearby Interaction documentation for iOS 18.4+, which states: “In iOS 18.4 and later, your app can continue ranging in the background with any supported device if the app starts a Live Activity as it goes to the background." Could you clarify what situations are considered “can continue ranging” versus cases where it will not continue? Specifically, if my app: starts a NISession in the foreground starts a Live Activity with that data then the app goes to background should the NI session still deliver ranging updates so the app can update the Live Activity? also, my app already enable Background Modes capability

While I welcome the arrival of a userspace implementation of drivers, DriverKit as it stands has some notable flaws. My main concern is the ability of open-source projects like HoRNDIS being able to access paid developer accounts and the limited entitlement scope (plus the waiting period) for what is essentially a hobbyist free project. Even if the developer is a professional company, some legacy hardware will go unsupported because of a lack of support from the vendor. Providing a way for users who need access to older hardware would be needed. Three concrete requests: A class-level or wildcard VID/PID entitlement for open source projects with a verifiable public repository A free or reduced-cost entitlement path for non-commercial volunteer-maintained drivers Published approval criteria and timelines so projects can plan accordingly Depreciating kexts without providing an accessible successor for community projects isn't security, it is gatekeeping access to hardware that is critically needed. Is this use case on the roadmap at all? Developers deserve a clear answer.

According to the release notes for macOS Tahoe 26.4 beta, a warning dialog should appear when launching apps that require Rosetta 2, informing users that these apps will stop working in a future macOS release. However, on my MacBook Air M1 running Tahoe 26.4 Beta 4 (25E5233c), no such warning appears when launching Intel (x86_64) apps. Test case: VLC media player Downloaded from the official VLC website: https://www.videolan.org/vlc/ Selected the Intel 64-bit version (vlc-3.0.21-intel64.dmg) Copied VLC.app to /Applications Code signature verified: Identifier: org.videolan.vlc Format: Mach-O thin (x86_64) Team ID: 75GAHG3SZQ Timestamp: June 2024 Flags: hardened runtime Notarization: accepted (Notarized Developer ID) spctl --assess --verbose /Applications/VLC.app → accepted, source=Notarized Developer ID Launched VLC.app — no Rosetta deprecation warning appeared System log findings: The following entry was repeated many times in the system log: Sandbox: oahd-helper deny(1) file-read-data /usr/libexec/rosetta/oahd-helper This suggests that oahd-helper is being blocked by the Sandbox from reading its own binary, which may be preventing the warning dialog from appearing. My questions: Is this a known bug in Beta 4? Does the absence of a warning mean the app will continue to work in macOS 28 and beyond? Should I file a Feedback report for this? Any insights would be appreciated. Thank you. Environment: Device: MacBook Air 2020 M1 OS: macOS Tahoe 26.4 Beta 4 (25E5233c) Test app: VLC 3.0.21 Intel 64-bit (org.videolan.vlc, Team ID: 75GAHG3SZQ) Source: https://www.videolan.org/vlc/

I'm running into a problem in my attempt to clear CKAssets on the iCloud server. The documentation for CKAsset says: If you no longer require an asset that’s on the server, you don’t delete it. Instead, orphan the asset by setting any fields that contain the asset to nil and then saving the record. CloudKit periodically deletes orphaned assets from the server. I'm deleting image file assets which are properties on an ImageReference type (largeImage and thumbNailImage properties). When I delete an image, I am setting those properties to nil and sending the record for the ImageReference to iCloud using the async CKDatabase.modifyRecords method. This always results in an error: <CKError 0x600000d92a60: "Asset File Not Found" (16/3002); "open error: 2 (No such file or directory)"> And of course the assets still appear in the CloudKit dashboard. What is the proper way of orphaning the assets on the CloudKit server?

We are using BGContinuedProcessingTask on iOS 26 for long-running background video compression and upload. This work usually takes about 30 minutes to 1 hour. In testing on physical devices, expirationHandler is invoked irregularly. In some cases, it seems like it is caused by total task duration, and in other cases, it seems related to system resource conditions such as CPU, memory, or battery. However, even after many experiments, we have not been able to find a clear or consistent pattern. The important problem for us is that we cannot tell why expirationHandler was called. From the app’s perspective, we need to handle the following cases differently: the user taps Stop in the Live Activity the system expires the task due to time expiration the task is terminated due to system resource pressure (CPU, memory, battery, etc.) other system-driven termination cases However, at the moment, it is difficult or practically impossible to distinguish these cases reliably. My questions are: In the context of BGContinuedProcessingTask, is it correct to think that expirationHandler may be triggered by reasons such as time expiration, system resource pressure, and user stop? If so, is there any official or supported way for the app to distinguish between these reasons? For long-running work such as video compression and upload, is it expected behavior that expirationHandler is invoked irregularly? If BGContinuedProcessingTask is not a stable approach for 30-minute to 1-hour background work, is there any other recommended or more reliable way to perform this kind of long-running background processing on iOS without unexpected interruption? Environment: iOS 26, physical device