iPhone12 ， iOS26 NFCTagReaderSession cannot read NFCTagTypeISO7816Compatible anymore

I’m implementing App Store subscriptions using StoreKit 2 and testing in the Sandbox environment. Until about a week ago everything worked fine, but recently the Settings > Subscriptions screen shows this message for my test account: “Your current payment method is not available.” The behavior: • Using a Sandbox tester account (not a production Apple ID) • Purchase flow works successfully — the transaction completes, and I receive server notifications • However, the system Settings app still displays that message under the subscription entry • No code changes were made since it last worked Questions: 1. What exactly does this message mean in the Sandbox environment? 2. Could this be related to any Apple system issue or recent backend update? 3. Has anyone else seen the same behavior in recent days? Environment: • Xcode 15.4 • iOS 17.5 (physical device) • StoreKit 2 / Swift 5.10 • Sandbox tester (Japan region) Thanks in advance for any insights or confirmations from others who are testing subscriptions in Sandbox!

I’m testing auto-renewable subscription purchases in the sandbox environment. When I buy a subscription package using a sandbox test user, I don’t receive any App Store Server Notifications from the sandbox. However, when I use the “Request Test Notification” option in App Store Connect, the notification is received successfully. My sandbox server notification URL is configured correctly and publicly accessible. I also call finishTransaction() after purchase, and the receipt is verified successfully with the sandbox verification endpoint. To further debug, I used the getNotificationHistory API to fetch notifications for yesterday and today (Nov 3–4, 2025). Apple’s API response does not include any notifications or transaction IDs for my today’s purchases (Nov 4, 2025) — even though I can confirm from logs that those transactions were completed and verified successfully. It looks like sandbox purchase notifications are not being sent or logged, even though test notifications work fine. Could someone from Apple please confirm if there’s currently an issue with sandbox server notifications for auto-renewable subscriptions?

I have an app developed by using the Callkit/Call-Blocking and received feedback from individual users, when using [cxcalldirectorymanager reloadextensionwithidentifier] to write call blocking data, it returned error code 11 with the following contents: errorCode: 11 errorDomain: com.apple.callkit.database.sqlite errorDescription: sqlite3_step for query 'DELETE FROM PhoneNumberBlockingEntry WHERE extension_id =?' returned 11 (11) errorMessage 'database disk image is malformed' I want to know the reasons for this error and how to solve it，Thanks!

Previously I could get the sub package information after each payment via webhook but today I didn't get it. What happened? My webhook url: https://r-connect-api-dev.mystg-env.com/webhook/appstore/notification/v2

I’m testing auto-renewable subscription purchases in the sandbox environment. When I buy a subscription package using a sandbox test user, I don’t receive any Apple Server Notifications from the sandbox. However, when I use the Request Test Notification option in App Store Connect, the notification is received successfully. My sandbox server notification URL is configured correctly and publicly accessible. I also call finishTransaction() after purchase. It looks like sandbox purchase notifications are not being sent, even though the test notification works fine.

My app attempts to upload events and logging data when the user backgrounds the app (i.e., when applicationDidEnterBackground is triggered) by creating an uploadTask using a URLSession with a URLSessionConfiguration.background. When uploading these events after being backgrounded, we call beginBackgroundTask on UIApplication, which gives us about 25-30 seconds before the expirationHandler gets triggered. I am noticing, however, that the expirationHandler is frequently called and no upload attempts have even started. This might be reasonable if, for example, I had other uploads in progress initiated prior to backgrounding, but this is not the case. Could someone confirm that, when initiating an uploadTask while the app is backgrounded using a backgroundSession, there's really no way to predict when that upload is going to begin? My observation is that about 10-20% of the time it does not begin within 20 seconds of backgrounding, and I have many events coming from clients in the field showing as much.

When working with this example code from Apple Implementing Interactions Between Users in Close Proximity, the example comes by default in Swift5, however when I switch to Swift6, the example would crash. I also observed the same crash in my personal project (this is why I tried the example code), currently blocking me. To repro: Download sample code from link Go to build settings and use Swift 6 Go to AppDelegate and change @UIApplicationMain to @main as this is required for Swift 6. Run the sample app on 2 iOS devices. Observe the crash: Thread 1 Queue : com.apple.main-thread (serial) Thread 5 Queue : TPC issue queue (serial) com.apple.uikit.eventfetch-threadThread 11 Queue : com.apple.MCSession.syncQueue (serial) Thread 15 Queue : com.apple.MCSession.callbackQueue (serial) #0 0x00000001010738e4 in _dispatch_assert_queue_fail () #1 0x00000001010aa018 in dispatch_assert_queue$V2.cold.1 () #2 0x0000000101073868 in dispatch_assert_queue () #3 0x000000019381f03c in _swift_task_checkIsolatedSwift () #4 0x000000019387f21c in swift_task_isCurrentExecutorWithFlagsImpl () #5 0x000000019381ed88 in _checkExpectedExecutor () #6 0x0000000101016d48 in @objc MPCSession.session(_:peer:didChange:) () #7 0x000000024a09f758 in __56-[MCSession syncPeer:changeStateTo:shouldForceCallback:]_block_invoke () #8 0x000000010107063c in _dispatch_call_block_and_release () #9 0x000000010108a2d0 in _dispatch_client_callout () #10 0x0000000101078b4c in _dispatch_lane_serial_drain () #11 0x00000001010797d4 in _dispatch_lane_invoke () #12 0x0000000101085b20 in _dispatch_root_queue_drain_deferred_wlh () #13 0x00000001010851c4 in _dispatch_workloop_worker_thread () #14 0x00000001f01633b8 in _pthread_wqthread () Enqueued from com.apple.MCSession.syncQueue (Thread 11) Queue : com.apple.MCSession.syncQueue (serial) #0 0x0000000101075be0 in dispatch_async () #1 0x000000024a09f660 in -[MCSession syncPeer:changeStateTo:shouldForceCallback:] () #2 0x000000024a0a365c in __63-[MCSession nearbyConnectionDataForPeer:withCompletionHandler:]_block_invoke () #3 0x000000010107063c in _dispatch_call_block_and_release () #4 0x000000010108a2d0 in _dispatch_client_callout () #5 0x0000000101078b4c in _dispatch_lane_serial_drain () #6 0x00000001010797d4 in _dispatch_lane_invoke () #7 0x0000000101085b20 in _dispatch_root_queue_drain_deferred_wlh () #8 0x00000001010851c4 in _dispatch_workloop_worker_thread () #9 0x00000001f01633b8 in _pthread_wqthread () #10 0x00000001f01628c0 in start_wqthread () Enqueued from com.apple.main-thread (Thread 1) Queue : com.apple.main-thread (serial) #0 0x0000000101075be0 in dispatch_async () #1 0x000000024a0a352c in -[MCSession nearbyConnectionDataForPeer:withCompletionHandler:] () #2 0x000000024a0bb8c0 in __55-[MCNearbyServiceAdvertiser syncHandleInvite:fromPeer:]_block_invoke_2 () #3 0x0000000101018004 in thunk for @escaping @callee_unowned @convention(block) (@unowned ObjCBool, @unowned MCSession?) -> () () #4 0x0000000101017db0 in MPCSession.advertiser(_:didReceiveInvitationFromPeer:withContext:invitationHandler:) at /Users/lyt/Downloads/ImplementingInteractionsBetweenUsersInCloseProximity/NIPeekaboo/MultipeerConnectivitySupport/MPCSession.swift:161 #5 0x0000000101017f74 in @objc MPCSession.advertiser(_:didReceiveInvitationFromPeer:withContext:invitationHandler:) () #6 0x000000024a0bb784 in __55-[MCNearbyServiceAdvertiser syncHandleInvite:fromPeer:]_block_invoke () #7 0x000000010107063c in _dispatch_call_block_and_release () #8 0x000000010108a2d0 in _dispatch_client_callout () #9 0x00000001010ab4c0 in _dispatch_main_queue_drain.cold.5 () #10 0x0000000101080778 in _dispatch_main_queue_drain () #11 0x00000001010806b4 in _dispatch_main_queue_callback_4CF () #12 0x0000000195380520 in __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ () #13 0x0000000195332d14 in __CFRunLoopRun () #14 0x0000000195331c44 in _CFRunLoopRunSpecificWithOptions () #15 0x0000000234706498 in GSEventRunModal () #16 0x000000019acacddc in -[UIApplication _run] () #17 0x000000019ac51b0c in UIApplicationMain () #18 0x000000019ad8d860 in ___lldb_unnamed_symbol296044 () #19 0x000000010101a680 in static UIApplicationDelegate.main() () #20 0x000000010101a5f0 in static AppDelegate.$main() () #21 0x000000010101a7bc in main () #22 0x00000001923aae28 in start () com.apple.multipeerconnectivity.gcksession.recvproccom.apple.multipeerconnectivity.gcksession.sendproccom.apple.multipeerconnectivity.eventcallback.eventcbproccom.apple.CFSocket.privatecom.apple.CFStream.LegacyThreadcom.apple.NSURLConnectionLoader

I am working on a cycling fitness app and I want to read the cycling power recorded using my Garmin edge from the Garmin Connect App. Currently the data is not transferred to the Health/Fitness Apps. Ideally it would be good to be able to query the power samples similar to the heart rate samples, but even the average power would suffice, as I could then calculate the Kilojoules.

Hello, We have observed a change in the presentation behavior of the AlarmKit Live Activity banner when our application is in the foreground, following the update from iOS 26.0 to iOS 26.1. We would like to clarify which behavior is intended. In iOS 26.0: When our application was in the foreground, the AlarmKit Live Activity banner did not present. In iOS 26.1: The AlarmKit Live Activity banner now presents even when our application is in the foreground. Could you please advise on what the correct or desired behavior is for this scenario? Thank you for your clarification.

I'm developing an App that works with BLE connection based devices. The BLE connection process, which connects well to the iPhone 16 without any problems, has not worked at all since the iPhone 17. Even when using the same iOS26 version, iPhone 17 is the only one having problems. Progress is stuck after frame 124 in the entire snoop below. Please check if it is a known problem or if there is a solution. 123 2025-11-04 02:01:39.262000 0.000000 localhost () 7c:c6:b6:91:10:04 () ATT 12 Sent Exchange MTU Response, Server Rx MTU: 232 124 2025-11-04 02:01:39.265000 0.003000 localhost () 7c:c6:b6:91:10:04 () ATT 16 Sent Read By Group Type Request, GATT Primary Service Declaration, Handles: 0x0001..0xffff

Colombia is not yet listed as a Tap to Pay user, but it is in the process of becoming so. We are currently a group of developers at a company in Colombia working on a project to integrate Tap to Pay into our application. After reviewing Apple's documentation, my company is not certified to meet Apple's security requirements, PCI standards, or licensing requirements. However, the payment service provider we have contracted for this is in the process of obtaining the certifications, authorizations, and licenses that Apple specifies. Our team members and managers overseeing this Tap to Pay project have told us that we, as iOS developers, should integrate and use the Proximity Reader API, but we know that we, as developers, are not authorized by Apple to do so. Is the payment service provider the only one who can make this possible, enabling its use with NFC and Proximity Reader? I would like to know if the service provider will provide us with the SDK containing the Proximity Reader API for integration into the project, or if my company will have to implement the Proximity Reader API ourselves?

My process running with root privilege, but got below error with API SecStaticCodeCreateWithPath(::_:) to create static code object for Cortex XDR Agent app, it working fine for other app like Safari on same device. 2025-07-22 02:02:05.857719(-0600)[23221:520725] DBG Found /Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app,/Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app running. Will verify the process now 2025-07-22 02:02:05.859209(-0600)[23221:520725] ERR Failed to create static code for path /Library/Application Support/PaloAltoNetworks/Traps/bin/Cortex XDR Agent.app/Contents/MacOS/Cortex XDR Agent. Error: Optional(UNIX[Operation not permitted]) Code Snippet let fileURL = URL(fileURLWithPath: processPath) var code: SecStaticCode? let rc = SecStaticCodeCreateWithPath(fileURL as CFURL, [], &code) if rc == errSecSuccess, let code = code { staticCode = code } else { ZSLoggerError("Failed to create static code for path \(processPath). Error: \(String(describing: SecCopyErrorMessageString(rc, nil)))") return nil }

Network.framework: Happy Eyeballs cancels also-ran only after WebSocket handshake (duplicate WS sessions) Hi everyone 👋 When using NWConnection with NWProtocolWebSocket, I’ve noticed that Happy Eyeballs cancels the losing connection only after the WebSocket handshake completes on the winning path. As a result, both IPv4 and IPv6 attempts can send the GET / Upgrade request in parallel, which may cause duplicate WebSocket sessions on the server. Standards context RFC 8305 §6 (Happy Eyeballs v2) states: Once one of the connection attempts succeeds (generally when the TCP handshake completes), all other connections attempts that have not yet succeeded SHOULD be canceled. This “SHOULD” is intentionally non-mandatory — implementations may reasonably delay cancellation to account for additional factors (e.g. TLS success or ALPN negotiation). So Network.framework’s current behavior — canceling after the WebSocket handshake — is technically valid, but it can have practical side effects at the application layer. Why this matters WebSocket upgrades are semantically HTTP GET requests (RFC 6455 §4.1). Per RFC 9110 §9.2, GET requests are expected to be safe and idempotent — they should not have side effects on the server. In practice, though, WebSocket upgrades often: include Authorization headers or cookies create authenticated or persistent sessions So if both IPv4 and IPv6 paths reach the upgrade stage, the server may create duplicate sessions before one connection is canceled. Questions / Request Is there a way to make Happy Eyeballs cancel the losing path earlier — for example, right after TCP or TLS handshake — when using NWProtocolWebSocket? If not, could Apple consider adding an option (e.g. in NWProtocolWebSocket.Options) to control the cancellation threshold, such as: after TCP handshake after TLS handshake after protocol handshake (current behavior) That would align the implementation more closely with RFC 8305 and help prevent duplicate, non-idempotent upgrade requests. Context I’m aware of Quinn’s post Understanding Also-Ran Connections. This report focuses specifically on the cancellation timing for NWProtocolWebSocket and the impact of duplicate upgrade requests. Although RFC 6455 and RFC 9110 define WebSocket upgrades as safe and idempotent HTTP GETs, in practice they often establish authenticated or stateful sessions. Thus, delaying cancellation until after the upgrade can create duplicate sessions — even though the behavior is technically RFC-compliant. Happy to share a sysdiagnose and sample project via Feedback if helpful. Thanks! 🙏 Example log output With Network Link Conditioner (Edge): log stream --info --predicate 'subsystem == "com.apple.network" && process == "WS happy eyeballs"' 2025-11-03 17:02:48.875258 [C3] create connection to wss://echo.websocket.org:443 2025-11-03 17:02:48.878949 [C3.1] starting child endpoint 2a09:8280:1::37:b5c3:443 # IPv6 2025-11-03 17:02:48.990206 [C3.1] starting child endpoint 66.241.124.119:443 # IPv4 2025-11-03 17:03:00.251928 [C3.1.1] Socket received CONNECTED event # IPv6 TCP up 2025-11-03 17:03:00.515837 [C3.1.2] Socket received CONNECTED event # IPv4 TCP up 2025-11-03 17:03:04.543651 [C3.1.1] Output protocol connected (WebSocket) # WS ready on IPv6 2025-11-03 17:03:04.544390 [C3.1.2] nw_endpoint_handler_cancel # cancel IPv4 path 2025-11-03 17:03:04.544913 [C3.1.2] TLS warning: close_notify # graceful close IPv4

Getting -10985 error from urlSession while attempting to make a connection. Not sure why this is happening if anyone is aware please help

Our application uses NEFilterPacketProvider to filter network traffic and we sometimes get a wired crash when removing/updating the network extension. It only happens on MacOS 11-12 . The crashing thread is always this one and it shows up after I call the completionHandler from the stopFilter func Application Specific Information: BUG IN CLIENT OF LIBDISPATCH: Release of a suspended object Thread 6 Crashed:: Dispatch queue: com.apple.network.connections 0 libdispatch.dylib 0x00007fff2039cc35 _dispatch_queue_xref_dispose.cold.1 + 24 1 libdispatch.dylib 0x00007fff20373808 _dispatch_queue_xref_dispose + 50 2 libdispatch.dylib 0x00007fff2036e2eb -[OS_dispatch_source _xref_dispose] + 17 3 libnetwork.dylib 0x00007fff242b5999 __nw_queue_context_create_source_block_invoke + 41 4 libdispatch.dylib 0x00007fff2036d623 _dispatch_call_block_and_release + 12 5 libdispatch.dylib 0x00007fff2036e806 _dispatch_client_callout + 8 6 libdispatch.dylib 0x00007fff203711b0 _dispatch_continuation_pop + 423 7 libdispatch.dylib 0x00007fff203811f4 _dispatch_source_invoke + 1181 8 libdispatch.dylib 0x00007fff20376318 _dispatch_workloop_invoke + 1784 9 libdispatch.dylib 0x00007fff2037ec0d _dispatch_workloop_worker_thread + 811 10 libsystem_pthread.dylib 0x00007fff2051545d _pthread_wqthread + 314 11 libsystem_pthread.dylib 0x00007fff2051442f start_wqthread + 15 I do have a DispatchSourceTimer but I cancel it in the stop func. Any ideas on how to tackle this?

TN 3115 states that apps that do not use AccessorySetupKit will loose the ability to launch into the background to service bluetooth in iOS26. Starting in iOS 26 and iPadOS 26, only apps that use AccessorySetupKit to setup Bluetooth accessories will be relaunched. Is there any more information regarding this? Will it affect any app under iOS26 or only those build against the iOS26 SDK? My app (dev build) is still relaunched, even though I'm running iOS26, so I wonder if there are any more conditions checked.

I would like to know whether BGContinuedProcessingTaskRequest supports executing asynchronous tasks internally, or if it can only execute synchronous tasks within BGContinuedProcessingTaskRequest? Our project is very complex, and we now need to use BGContinuedProcessingTaskRequest to perform some long-running operations when the app enters the background (such as video encoding/decoding & export). However, our export interface is an asynchronous function, for example video.export(callback: FinishCallback). This export call returns immediately, and when the export completes internally, it calls back through the passed-in callback. So when I call BGTaskScheduler.shared.register to register a BGContinuedProcessingTask, what should be the correct approach? Should I directly call video.export(nil) without any waiting, or should I wait for the export function to complete in the callback? For example: BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.xxx.xxx.xxx.xxx", using: nil) { task in guard let continuedTask = task as? BGContinuedProcessingTask else { task.setTaskCompleted(success: false) return } let scanner = SmartAssetsManager.shared let semaphore = DispatchSemaphore(value: 0) continuedTask.expirationHandler = { logError(items: "xwxdebug finished.") semaphore.signal() } logInfo(items: "xwxdebug start！") video.export { _ in semaphore.signal() } semaphore.wait() logError(items: "xwxdebug finished！") }

Hello, I am currently researching for ways to get the versions of all of the Mach-O executables and dylibs installed on my MacOS machine. Based on my initial research, I am able to get the information of installed applications from commands like "lsappinfo" and "system_profiler SPApplicationsDataType". However, the above commands only give me information about applications installed in my machine, not all the Mach-O binaries and dylibs. I also saw otool -L output is not very reliable as some dylibs don't show the current version. Are there any alternate commands I can try to get this information? Can this be achievable through any frameworks on MacOS? Any pointers will help me a lot.

Howdy, I've been developing a packet tunnel extension meant to run on iOS and MacOS. For development I'm using xcodegen + xcodebuild to assemble a bunch of swift and rust code together. I'm moving from direct TUN device management on Mac to shipping a Network Extension (appex). With that move I noticed that on some mac laptops NE fails to start completely, whilst on others everything works fine. I'm using CODE_SIGN_STYLE: Automatic, Apple IDs are within the same team, all devices are registered as dev devices. Signing dev certificates, managed by xcode. Some suspicious logs: (NetworkExtension) [com.apple.networkextension:] Signature check failed: code failed to satisfy specified code requirement(s) ... (NetworkExtension) [com.apple.networkextension:] Provider is not signed with a Developer ID certificate What could be the issue? Where those inconsistencies across devices might come from?