We are currently experiencing a very interesting issue when accessing the location in the background with CLLocationManager. The user has given our app the "whenInUse" permission for locations and in most cases the app provides location updates even when it's in the background. However, when we started to use other navigation apps in the foreground we saw that the func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) method was called with (kCLErrorDomain error 1.). The user hasn't changed the location permission and we saw that locations were delivered once the user opened the app again. I don't see anything in the documentation explaining this issue, but I chatted with other developers that confirm that specific behavior. Am I missing something here?

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

Hello, I'm trying to adopt the new BGContinuedProcessingTask API, but I'm having a little trouble imagining how the API authors intended it be used. I saw the WWDC talk, but it lacked higher-level details about how to integrate this API, and I can't find a sample project. I notice that we can list wildcard background task identifiers in our Info.plist files now, and it appears this is to be used with continued tasks - a user might start one video encoding, then while it is ongoing, enqueue another one from the same app, and these tasks would have identifiers such as "MyApp.VideoEncoding.ABCD" and "MyApp.VideoEncoding.EFGH" to distinguish them. When it comes to implementing this, is the expectation that we: a) Register a single handler for the wildcard pattern, which then figures out how to fulfil each request from the identifier of the passed-in task instance? Or b) Register a unique handler for each instance of the wildcard pattern? Since you can't unregister handlers, any resources captured by the handler would be leaked, so you'd need to make sure you only register immediately before submission - in other words register + submit should always be called as a pair. Of course, I'd like to design my application to use this API as the authors intended it be used, but I'm just not entirely sure what that is. When I try to register a single handler for a wildcard pattern, the system rejects it at runtime (while allowing registrations for each instance of the pattern, indicating that at least my Info.plist is configured correctly). That points towards option B. If it is option B, it's potentially worth calling that out in documentation - or even better, perhaps introduce a new call just for BGContinuedProcessingTask instead of the separate register + submit calls? Thanks for your insight. K Aside: Also, it would be really nice if the handler closure would be async. Currently if you need to await on something, you need to launch an unstructured Task, but that causes issues since BGContinuedProcessingTask is not Sendable, so you can't pass it in to that Task to do things like update the title or mark the BGTask as complete.

Hi there! Whenever I try to add a new Offer Code for my app's subscription, I get an unknown error. When I get to the last step of the "Create Offer for Codes" flow, I get an error that error reads "An error has occurred. Try again later." I have been getting this same error for over a week now, so any help figuring out how to add new offer codes would be greatly appreciated!

Hi there, We’re developing a companion app for a smart home product that communicates over the user’s local network. To provision the device, it initially creates its own Wi-Fi network. The user joins this temporary network and enters their home Wi-Fi credentials via our app. The app then sends those credentials directly to the device, which stores them and connects to the local network for normal operation. We’re using AccessorySetupKit to discover nearby devices (via SSID prefix) and NEHotspotManager to join the accessory’s Wi-Fi network once the user selects it. This workflow works well in general. However, we’ve encountered a problem: if the user factory-resets the accessory, or needs to restart setup (for example, after entering the wrong Wi-Fi password), the device no longer appears in the accessory picker. In iOS 18, we were able to work around this by calling removeAccessory() after the device is selected. This forces the picker to always display the accessory again. But in iOS 26, a new confirmation dialog now appears when calling removeAccessory(), which confuses users during setup. We’re looking for a cleaner way to handle this scenario — ideally a way to make the accessory rediscoverable without prompting the user to confirm removal. Thanks for your time and guidance.

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?

Hi, I’ve built an app that includes a Contacts Provider Extension (CPE). On iOS 18, I observed the expected behavior — when the main app is uninstalled, the corresponding CPE entry is also removed from the Contacts list. However, on iOS 26, this no longer happens. After uninstalling the app, the CPE remains visible and active in the Contacts list, even though the app is gone.

I'm struggling to understand what the impact of this flag is. Docs only say: For devices running iOS 18 and iPadOS 18 or later, you can add input-push-token: 1 to your payload to start a Live Activity and receive a new push token. After you receive a new push token, you can use it to send updates to a Live Activity. But things were working fine for iOS 17. Right? Does it somehow make the OS emit update tokens faster/more successfully? Should I include in all start, update, end events?

Since upgrading to Xcode 26 beta 4 and using the iOS 26 simulator for testing our app, we've stopped being able to receive device tokens for the simulator from the development APNS environment. The APNS environment is able to return meta device information (e.g. model, type, manufacturer) but there are no device tokens present. When running the same app using the iOS 18.5 simulator, we are able to register the device with the same APNS environment and receive a valid device token.

I am using a Raspberry Pi 5 (BLE 5.0) to read sensor data and send it via D-Bus and BlueZ to a Flutter application (flutter_blue_plus) for both iOS and Android. The goal is to display these real-time sensor updates directly on the device. On Android, the data transmission is immediate and the real-time visualization is extremely smooth and fast. However, on iOS, both BLE write and notification commands appear with noticeable latency—not only in real-time displays, but also when comparing ordinary notification feedback between the Raspberry Pi terminal and the iOS app. It seems that iOS buffers several BLE packets internally and then dispatches them in batches, which always introduces an additional delay. Additional setup details: I sample and transmit data every 25ms, sending binary packets of 20 bytes (length shouldn’t be a limiting factor). On the iOS side I am using an iPhone 15 Pro with iOS 18.6.2 (BLE 5.3). The Raspberry Pi (using btmon for logging) confirms after connection setup that the connection interval is fixed at 30ms (and cannot be changed). I have tried sending BLE packets every 30ms so that exactly one packet arrives per interval, but this made no difference—the latency and batch delivery remain. Interestingly, faster transmission rates (e.g. sending every 10ms) make the real-time display look smoother on iOS, but the guaranteed overall system latency does not improve. Also these methods used: write-without-response, using app in release modus (no debugging) Is there anyone familiar with this problem or a potential solution? Or is iOS simply not optimized for true real-time BLE data streaming and visualization? Any pointers, technical insights or workarounds would be greatly appreciated.

Hello, I understand that to discover and pair a device or accessory with Wi-Fi Aware, we can use either the DeviceDiscoveryUI or AccessorySetupKitUI frameworks. During the pairing process, both frameworks prompt the user to enter a pairing code. Is this step mandatory? What alternatives exist for devices or accessories that don't have a way to communicate a pairing code to the user (for example, devices or accessories without a display or voice capability)? Best regards, Gishan

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

HI, I am currently developing an app that utilizes Wi-Fi Aware. According to the Wi-Fi Aware framework examples and the WWDC25 session on Wi-Fi Aware, discovery is handled using DevicePairingView and DevicePicker from the DeviceDiscoveryUI module. However, these SwiftUI views present their connection UI modally when tapped. My app's design requires the ability to control the presentation of this UI programmatically, rather than relying on a user tap. While inspecting the DeviceDiscoveryUI module, I found DDDevicePairingViewController and DDDevicePickerViewController, which appear to be the UIViewController counterparts to the SwiftUI views. The initializer for DDDevicePairingViewController accepts a ListenerProvider, so it seems I can pass the same ListenerProvider instance that is used with the DevicePairingView. However, the initializer for DDDevicePickerViewController requires an NWBrowser.Descriptor, which seems incompatible with the parameters used for the SwiftUI DevicePicker. I have two main questions: (1) Can DDDevicePairingViewController and DDDevicePickerViewController be officially used for Wi-Fi Aware pairing? (2) Are there any plans to provide more customization or programmatic control over the DevicePairingView and DevicePicker (for example, allowing us to trigger their modal presentation programmatically)? Thank you.

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

iPhone12 ， iOS26 NFCTagReaderSession cannot read NFCTagTypeISO7816Compatible anymore

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!

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.

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

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 }

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.