Hello, I have implemented a URL Filter using the sample provided here: Filtering Traffic by URL. I am also using an App Group to dynamically manage the Bloom filter and block list data. However, when I update my block list URLs and create a new Bloom filter plist in the App Group, the extension does not seem to use the updated Bloom filter even after the prefetch interval expires. Also for testing purpose can I keep this interval to 10 mins or below ?

Error 8 in the NEHotspotConfigurationError domain is .internal, aka NEHotspotConfigurationErrorInternal. This error typically indicates that something went wrong in some sort of expected way, but we decided not to surface the exact cause [1]. This has come up a bunch of times before on the forums, and I have various titbits to share. To start, I want to address some specific cases: You’ll see this error if your app isn’t signed with the com.apple.developer.networking.HotspotConfiguration entitlement. To fix this, use Xcode’s Signing & Capabilities editor to add the Hotspot capability to your app. Historically developers reported a situation where once they encountered the error it would show up consistently, but then it would go away on restarting the device. If you see behaviour like that, that’s definitely a bug and I encourage you to file it as such. I have more about filing such bugs in Filing a Wi-Fi Bug Report. Of course, you have to wait to reproduce the error again before you’ll be able to file that bug, because the act of restarting cleared the issue. I’ve seen reports where such problems only occur on a specific type of device, for example, on iPhone 16 but not on earlier or later iPhones. That’s definitely something that Apple should investigate, and I recommend that you file a bug about it. If the problem is being reported by your users but you can’t reproduce it yourself, consider the various suggestions in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. Assuming you’re still here (-: the next step is to determine whether the problem is specific to NEHotspotConfigurationManager or not. Try joining the accessory’s network from Settings > Wi-Fi. Does that also have problems? If so, that’s not something we can help you with here on the forums. The focus of the Apple Developer Forums is primarily to help developers with the APIs in Apple’s various platform SDKs [2]. We’re not set up to help accessory developers with Wi-Fi issues. However, there are still things you can do, as I explain in Filing a Wi-Fi Bug Report. At this point you have an error that: Persists across restarts Happens with all Apple devices You can reproduce Only affects NEHotspotConfigurationManager If that’s correct then there are a couple of things you might look at: Coerce the error to an NSError and print that. Does it reveal anything interesting? Also check the underlying error property (NSUnderlyingErrorKey) for hints. When reproducing the error, monitor the system log for log entries in the com.apple.networkextension subsystem. Do those offer any clues? Note For lots of hints and tips about the system log, see Your Friend the System Log. And finally, if you have questions about this case, feel free to start a thread here on the forums and we’ll try to help you out. Put it in the App & System Services > Networking subtopic and tag it with Network Extension. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] There’s also the .unknown error. See this post for a brief summary of the difference. [2] And with Apple tools and some developer-oriented services. Revision History 2026-03-18 Added a missing entitlement bullet to the specific case list. 2026-03-17 First posted.

Every now and again I end up helping a developer with a Wi-Fi issue. These fall into two groups: User-level Wi-Fi issues Development Wi-Fi issues A user-level Wi-Fi issue is one where the developer hasn’t created any of the products involved. An example of this is when you’re developing an app for an accessory and iOS is having problems connecting to that accessory but you don’t control the accessory’s firmware. In general, I recommend that you escalate such issues to the accessory vendor. They can then run their own investigation and, if necessary, file their own bug report. A development Wi-Fi issue is one that directly affects one of your products. For example, you’re developing a Wi-Fi accessory and iOS is having problems connecting to it. In that case, the onus is on you [1] to investigate why things are failing. If your conclusion is that iOS is behaving incorrectly, file a bug about that. IMPORTANT If you do file a bug in the context of some forums thread, please post your bug number to the thread, just for the record. When filing this sort of bug report it’s important to provide: Solid evidence that the problem is on the Apple side of the fence Enough information for Apple’s engineers to investigate it effectively Let’s start with that second point. If you can reproduce the problem reliably, install the Wi-Fi debug profile on your device, reproduce the problem, noting down a rough timestamp, and include the resulting logs and that timestamp in your bug report. Also, consider attaching a packet trace. There are three options here: Record a packet trace from the perspective of the Apple device. On iOS, use an RVI packet trace for this. Record a packet trace from the perspective of your accessory. Record a Wi-Fi level packet trace. You can do this from your Mac (see Recording a Wi-Fi Packet Trace) but it might be easier to do this with the infrastructure you used during the bring up of your accessory. It’s fine to include all three (-: Also include any relevant context about the issue. For example: If the issue is tied to a specific device model (In that case, it’d be good to include the above information for both the successful and failing cases.) If the problem shows up when joining from Settings > Wi-Fi, or whether it’s tied to a specific API, like NEHotspotConfigurationManager Finally, make sure to include an explanation of why you think this is an Apple bug, referencing specific items in the logs and packet traces that you attached. Of course, it’s only possible to do all of this if you can reproduce the problem. Investigating an intermittent issue based on reports coming in from users is much harder. It’s OK to file a bug about such issues, but your bug might not be actionable. At a minimum you should aim to include a sysdiagnose log with your bug. IMPORTANT This log has to be taken shortly after reproducing the problem. Don’t just attach any old log. One option is to request such a log from your users. I talk more about this in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. You can also ask your users to file their own bugs using the Feedback Assistant app. It should automatically capture and attach a sysdiagnose log. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Well, your organisation. It’s rare to find a team where the same engineer works on both the iOS app and the accessory firmware. But if that’s you, good job!

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.