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

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.

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")

I am investigating a connectivity issue reported by a user running latest iOS 26.4 Public Beta on an iPhone 17 Pro Max. Unfortunately, I am unable to reproduce this behavior on my end as I do not have access to an iPhone 17 Pro Max for testing, and my current devices do not exhibit the issue. However, the user's logs suggest a system-level networking issue : Symptoms: Flutter App (package dio): Requests fail with The connection errored: Failed host lookup: 'mydomain.com' Firebase SDK: Unable to fetch Firestore documents Duration: The outage is random, lasting between 5 to 15 minutes before self-resolving Scope: It affects both Wi-Fi and Cellular data By the way I found this report from another developer experiencing the exact same behavior: "I run a mobile app that has millions of users. As of 1-2 weeks ago, we started getting reports that the app isn't working (failing to connect). It then goes back to connecting anywhere between 5 to 15-20 mins later. Every single one of those users was running iOS 26.4 beta, and their phones ranged from iPhone 17 PRO Max to regular iPhone 17s, to iPhone 16 PROs and Maxs. The only other thing is that all these users also had Apple Private Relay enabled. During the time the app wasn't able to connect, other apps on their phones like YouTube, also failed to connect. The issue is persistent whether on Wifi or cellular, didn't matter. I upgraded my iPhone 16 PRO Max to iOS 26.4, and wasn't experiencing the issue. I enabled Private Relay - and a few mins later on my own phone, I couldnt connect on my own app, and YouTube/Gmail also were experincing issue. It self-resolved 5-10 mins later. But it kept happening throughout the day. I've tested Network reset, I've also re-installed the apps, both still continued to have those weird intermittent outages. I just updated the phone to the latest version that was released a day ago, so far I'm not experiencing it, but as you can imagine, this is such a weird behaviour that it's concerning for me that I can't figure out the exact way to replicate it." I asked the user to test with iCloud Private Relay disabled, and it immediately fixed the problem -> so maybe this suggests that it might be related to how Private Relay handles traffic or DNS resolution in this beta ? Are other developers seeing an increase in SocketException or host lookup failures on the 26.4 Beta? Is this a known regression related to Private Relay that is expected to be patched before the RC/Final release?

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 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 ?

The FindMy device is currently MFI certified, but we plan to support UWB ranging functionality in the Find My app, similar to AirTag. After searching for relevant information, I found the relevant UWB functions in this article "Nearby-Interaction-Accessory-Protocol-Specification-Release-R4", but we need to develop third-party applications ourselves. So how can we make it display distance and direction in the "Find My" app like AirTag does?

When printing image/photo files via AirPrint, selected finishing options (e.g., Punch) are not applied unless a preset is chosen. reproduction steps: Select an image on iOS Tap Print → choose printer/server Set Finishing Options → Punch Print Observed: Finishing options not applied IPP trace shows no finisher attributes in the request working scenario: Select any Preset (e.g., Color) before printing Finishing options are then included in IPP and applied Note: Issue does not occur when printing PDFs from iOS; finisher attributes are sent correctly. Is this expected AirPrint behavior for image jobs, or could this be a bug in how iOS constructs the IPP request for photos?

How do we get addPaymentPassViewController response for in app verification without calling that function ? Currently we have working in app provisioning but not in app verification. The apple docs say "The process of generating the cryptographic OTP value is the same as for generating activationData for In-App Provisioning.". How is it the same when in in app provisioning we have this button that returns all necessary info and for in app verification there is no clear way of recieving same info.

after doing all the steps as in The app version submission must be in the “Prepare for Submission” state There must be at least one IAP/subscription in the “Ready to Submit” state All banking & agreements must set up and in place I am still not seeing the In-App purchase and subscription in my iOS App Version page to add to my newest version slash build

On iOS 26.3.1, deviceactivityd produces zero log output and never wakes a DeviceActivityMonitor extension at the scheduled time, even when the schedule is successfully registered. The extension's intervalDidStart(for:) method is never called. Steps to Reproduce: Create an app with a DeviceActivityMonitor extension subclass Add the com.apple.developer.family-controls entitlement to both the main app and extension targets Add a shared App Group entitlement to both targets In the main app, call: let center = DeviceActivityCenter() center.stopMonitoring([.myActivity]) let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour: 17, minute: 30), intervalEnd: DateComponents(hour: 17, minute: 45), repeats: true ) try center.startMonitoring(.myActivity, during: schedule) Verify registration succeeds: DeviceActivityCenter().activities.contains(.myActivity) returns true Background the app completely and wait for the intervalStart time (5:30 PM in this example) Expected Result: intervalDidStart(for:) is called in the extension process at 5:30 PM. ManagedSettings shields are applied without any user interaction. Actual Result: intervalDidStart(for:) is never called. No extension process is launched. Filtering Console.app for deviceactivityd on the device returns 0 messages — the daemon produces no logs whatsoever despite an active registered schedule. Shields are never applied. Additional Evidence: Third-party apps using DeviceActivity (e.g. Prayer Lock) successfully apply shields at scheduled times on the same device and OS version, confirming the framework is not universally broken Filtering Console.app for the app's bundle ID at the trigger time shows the main app process applying shields via a UNCalendarNotificationTrigger fallback — but no extension process activity DeviceActivityCenter().activities correctly lists the registered activity before and after the trigger time, confirming the schedule registration API is functional Environment: iOS 26.3.1 Physical device (required for FamilyControls) Development-signed build with com.apple.developer.family-controls entitlement provisioned App Group shared between main app and extension targets

I've encountered an issue where we need multiple domain associations with separate Apple Pay implementations. Briefly, we have a /.well-known/apple-developer-merchantid-domain-association already setup with Stripe, and now we need another, different version of the file to get setup with FreedomPay. FreedomPay insists this file represents a three-way relationship between all parties and I have no reason to disbelieve them. I'm wondering if anyone has encountered this or if there is a standard procedure. I'm currently trying to find documentation on the exact way Apple Pay verification interacts with this file to see if we can produce it dynamically.

Similar Issue to FB13556935: On iOS 26.3.1, deviceactivityd produces zero log output and never wakes a DeviceActivityMonitor extension at the scheduled time, even when the schedule is successfully registered. The extension's intervalDidStart(for:) method is never called. Steps to Reproduce: Create an app with a DeviceActivityMonitor extension subclass Add the com.apple.developer.family-controls entitlement to both the main app and extension targets Add a shared App Group entitlement to both targets In the main app, call: let center = DeviceActivityCenter() center.stopMonitoring([.myActivity]) let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour: 17, minute: 30), intervalEnd: DateComponents(hour: 17, minute: 45), repeats: true ) try center.startMonitoring(.myActivity, during: schedule) Verify registration succeeds: DeviceActivityCenter().activities.contains(.myActivity) returns true Background the app completely and wait for the intervalStart time (5:30 PM in this example) Expected Result: intervalDidStart(for:) is called in the extension process at 5:30 PM. ManagedSettings shields are applied without any user interaction. Actual Result: intervalDidStart(for:) is never called. No extension process is launched. Filtering Console.app for deviceactivityd on the device returns 0 messages — the daemon produces no logs whatsoever despite an active registered schedule. Shields are never applied. Additional Evidence: Third-party apps using DeviceActivity (e.g. Prayer Lock) successfully apply shields at scheduled times on the same device and OS version, confirming the framework is not universally broken Filtering Console.app for the app's bundle ID at the trigger time shows the main app process applying shields via a UNCalendarNotificationTrigger fallback — but no extension process activity DeviceActivityCenter().activities correctly lists the registered activity before and after the trigger time, confirming the schedule registration API is functional Environment: iOS 26.3.1 Physical device (required for FamilyControls) Development-signed build with com.apple.developer.family-controls entitlement provisioned App Group shared between main app and extension targets

Mounting NFS to the application's own container directory using NetFSMountURLSync failed. Mounted to /Users/li/Library/Containers/com.xxxxx.navm.MyNavm/Data/Documents/NFSMount Do sandbox applications not allow mounting NFS cloud storage? code: // 1. NFS 服务器 URL（指定 NFSv3） let urlString = "nfs://192.168.64.4/seaweed?vers=3&resvport&nolocks&locallocks&soft&intr&timeo=600" guard let nfsURL = URL(string: urlString) else { os_log("❌ 无效的 URL: %@", log: netfsLog, type: .error, urlString) return } // 2. 挂载点（必须在沙盒容器内） let fileManager = FileManager.default guard let documentsURL = fileManager.urls(for: .documentDirectory, in: .userDomainMask).first else { os_log("❌ 无法获取 Documents 目录", log: netfsLog, type: .error) return } let mountPointURL = documentsURL.appendingPathComponent("NFSMount", isDirectory: true) // 创建挂载点目录 do { try fileManager.createDirectory(at: mountPointURL, withIntermediateDirectories: true, attributes: nil) os_log("✅ 挂载点目录已准备: %@", log: netfsLog, type: .info, mountPointURL.path) } catch { os_log("❌ 创建挂载点目录失败: %@", log: netfsLog, type: .error, error.localizedDescription) return } // 3. 挂载选项（使用 NSMutableDictionary 以匹配 CFMutableDictionary） let mountOptions = NSMutableDictionary() // 如果需要，可以添加选项，例如： // mountOptions[kNetFSNoUserAuthenticationKey as String] = true // 4. 调用 NetFSMountURLSync var mountPoints: Unmanaged<CFArray>? = nil let status = NetFSMountURLSync( nfsURL as CFURL, mountPointURL as CFURL, nil, // user nil, // password nil, // open_options mountOptions, // 直接传递 NSMutableDictionary，自动桥接为 CFMutableDictionary &mountPoints ) log: 0 sandboxd: (TCC) [com.apple.TCC:cache] REMOVE: (kTCCServiceSystemPolicyAppData, <Credential (0x7ed0b4230) | Audit Token, 42834.109774/501>) 2026-03-03 21:38:27.656702+0800 0x2de8d8 Info 0x867e9d 408 0 sandboxd: (TCC) [com.apple.TCC:cache] SET: (kTCCServiceSystemPolicyAppData, <Credential (0x7ed0b4230) | Audit Token, 42834.109774/501>) -> <Authorization Record (0x7ecca8180) | Service: kTCCServiceSystemPolicyAppData, AuthRight: Unknown, Reason: None, Version: 1, Session pid: 42832, Session pid version: 109769, Boot UUID: 7DDB03FC-132C-4E56-BA65-5C858D2CC8DD, > 2026-03-03 21:38:27.656753+0800 0x2de8d8 Default 0x867e9d 408 0 sandboxd: (libxpc.dylib) [com.apple.xpc:connection] [0x7ecc88640] invalidated after the last release of the connection object 2026-03-03 21:38:27.656772+0800 0x2de8d8 Debug 0x867e9b 408 0 sandboxd: (TCC) [com.apple.TCC:access] disposing: 0x7ecc3aa80(OS_tcc_message_options) 2026-03-03 21:38:27.656779+0800 0x2de8d8 Debug 0x867e9b 408 0 sandboxd: (TCC) [com.apple.TCC:access] disposing: 0x7ecc44820(OS_tcc_server) 2026-03-03 21:38:27.656788+0800 0x2de8d8 Info 0x867e9b 408 0 sandboxd: [com.apple.sandbox:sandcastle] kTCCServiceSystemPolicyAppData would require prompt by TCC for mount_nfs

There's a purchase I make pretty often on a particular site and I'm trying to automate the boring parts with a macOS app. I can pull the merchant session from their ValidateMerchant endpoint. I can see the Apple Pay dialogue appear, then it will disappear with "Payment Not Completed." Is it fundamentally not possible to use someone else's merchant session in your own app? Thanks

Hello, I am developing with the Nearby Interaction framework using third-party UWB accessories (Murata SR040/SR150). I observed a difference between U1-based and U2-based iPhones: iPhone 12 Pro (U1 chip) NINearbyObject.direction returns valid 3D vector (x, y, z). Distance and direction both work as expected. iPhone 15 Pro and iPhone 16 Pro (U2 chip) NINearbyObject.direction is always nil. Only distance is returned (around 0.35–0.40 m in my test). Effectively behaves as "distance-only mode". Environment: Hardware: iPhone 12 Pro, iPhone 15 Pro iOS version: 18.5 Accessory: Murata UWB SR040 / SR150 App: Using NINearbyAccessoryConfiguration with BLE-based discovery Info.plist includes NSNearbyInteractionUsageDescription Camera assistance was tested both ON and OFF Expectation: I expected the U2 chip to behave consistently with U1, i.e. provide direction vectors when possible. Instead, on iPhone 15 Pro, direction is always unavailable (nil) while distance is returned correctly. Questions: Is this an intentional limitation for U2 chip + third-party accessories? Is there a new requirement (e.g. certification, firmware update, capability flags) to enable direction on U2 devices? Could this be related to NIDeviceCapability or the new Extended Distance Measurement (EDM) mode in U2? Thanks in advance for any clarification.

I am trying on iOS 16.1.1 the Nearby Interaction framework. I am testing it on two iPhones 14 Pro Max. The supportsDirectionMeasurement property returns false (!) and the direction property on the NINearbyObjects is nil. Has someone experienced the same issue?

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.

Hello, my app is frequently loosing / forgetting the Screen Time Permission that had been granted previously on iOS 26. I have experienced it myself, sysdiagnose is in this radar: FB18997699 But also also my App Store users who have updated to iOS 26 already have reported this bug. It would be great if Apple could ensure that this bug is addressed before iOS 26 is released to the public.