When my Bluetooth peripheral device has both HID and MIDI services, the iOS Bluetooth host repeatedly sends different "Control Opcode: LL_CONNECTION_UPDATE_IND" to the peripheral, updating approximately every 100ms. The Bluetooth peripheral cannot handle such high-frequency update requests and typically disconnects with an error 0x28. My Bluetooth device uses the NRF52832 chip, and I have communicated with NORDIC and replicated this issue. This problem only occurs on iOS 26; it does not happen on earlier versions. I think it might be caused by the HID service in iOS requesting faster connection parameters for low latency, which then gets erroneously reverted for an unknown reason, leading to repeated competition and entering into a deadlock. Here is the communication record with NORDIC: https://devzone.nordicsemi.com/f/nordic-q-a/124994/ios-26-bluetooth-disconnect-issues This is the screenshot captured using the Bluetooth sniffer:

We are preparing to implement document signing using USB tokens on iOS and macOS. Several other applications already support this feature. From my testing and development efforts, I've been unable to reliably access or utilize certificates stored on a smartcard through the iOS APIs. Here are the specifics: Environment iOS: 15 and later Xcode: Versions 18 and 26 Smartcard/Token: ePass 2003 (eMudhra), Feitien token (Capricorn) Observed Issue : The token is recognized at the system level, with certificates visible in Keychain Access. However, programmatic access to the private keys on the smartcard from within the app is not working. Signing attempts result in Error 6985 and CACC errors. Approaches Tried: Updated provisioning profiles with the following entitlements: com.apple.developer.smartcard com.apple.security.device.usb TKSmartCard Employed TKSmartCard and TKSmartCardSession for interaction. The token is detected successfully. A session can be established, but there's no straightforward method to leverage it for certificate-based signing. Access to signing functions is unavailable; operations yield Error 6985 or CACC errors. if let smartCard = TKSmartCard(slot: someSlot) { smartCard.openSession { session, error in if let session = session { let command: [UInt8] = [0x00, 0xA4, 0x04, 0x00] session.transmit(Data(command)) { response, error in print("Response: \(String(describing: response))") print("Error: \(String(describing: error))") } } } } TokenKit (macOS/iOS) - Utilized TKTokenWatcher to identify available tokens on macOS (not available on iOS). watcher.setInsertionHandler { tokenID in print("Token detected: \(tokenID)") } CryptoKit / Security Framework - Attempted to retrieve SecCertificate using SecItemCopyMatching queries, which succeeded on macOS but failed on iOS. let query: [CFString: Any] = [ kSecClass: kSecClassCertificate, kSecReturnRef: true, kSecMatchLimit: kSecMatchLimitAll ] var items: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &items) print("Status: \(status)") // macOS succeeds, iOS fails ExternalAccessory Framework (EAAccessory) * Investigated using EAAccessory and EASession for external token communication, but it did not function as expected. This functionality is critical for my project. Has anyone successfully implemented smartcard-based signing on iOS? Any guidance, sample code, or references to relevant Apple documentation would be greatly appreciated.

On iOS 26.1, this throws on the 2020 iPad Pro (4th gen) but works fine on an M4 iPad Pro or iPhone 15 Pro: guard let device = AVCaptureDevice.default(.builtInLiDARDepthCamera, for: .video, position: .back) else { throw ConfigurationError.lidarDeviceUnavailable } It's just the standard code from Apple's own sample code so obviously used to work: https://developer.apple.com/documentation/AVFoundation/capturing-depth-using-the-lidar-camera Does it fail because Apple have silently dumped support for the older LiDAR sensor used prior to the M4 iPad Pro, or is there another reason? What about the 5th and 6th gen iPad Pro, does it still work on those?

I am developing an IOS App that allow users to scan rooms, view the scans on device, and add notes. I need to preserve actual geometry (odd angles, chamfers, fixtures), not simplified RoomPlan boxes. Are there any easy ways to incorporate high quality texture mapping or PBR? Where is the documentation for scene reconstruction?

Hi, we've observed a weird behavior for a small amount of our user that we keep receiving the same token from APNs despite it's shown as Unregistered. When we try to send push to the token, we got an Unregistered error so we remove that token from our server. However, later we would receive an add token request from the client with the same token we just removed, and when we try to send to the token it returns Unregistered again so we remove the token again. This happened 3 times for a user in an hour. The identifierForVendor remains the same for all the requests. We also owns the client and I've checked client code that it's sending the token it received from didRegisterForRemoteNotificationsWithDeviceToken to the server.

Starting with iOS 18, UITabBarController no longer updates tab bar item titles when localized strings are changed or reassigned at runtime. This behavior worked correctly in iOS 17 and earlier, but in iOS 18 the tab bar titles remain unchanged until the app restarts or the view controller hierarchy is reset. This regression appears to be caused by internal UITabBarController optimizations introduced in iOS 18. Steps to Reproduce Create a UITabBarController with two or more tabs, each having a UITabBarItem with a title. Localize the tab titles using NSLocalizedString(): tabBar.items?[0].title = NSLocalizedString("home_tab", comment: "") tabBar.items?[1].title = NSLocalizedString("settings_tab", comment: "") Run the app. Change the app’s language at runtime (without restarting), or manually reassign the localized titles again: tabBar.items?[0].title = NSLocalizedString("home_tab", comment: "") tabBar.items?[1].title = NSLocalizedString("settings_tab", comment: "") Observe that the tab bar titles do not update visually.

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

I have the main app that saves preferences to UserDefaults.standard. So I have this one preference that the user is able to toggle - isRawOn UserDefaults.standard.set(self.isRawOn, forKey: "isRawOn") Now, I have LockedCameraCaptureExtension which is required know if that above setting on or off during launch. Also if it's toggled within the extension, the main app should know about it on the next launch. The main app and the extension runs on separate containers and the preferences are not shared due to privacy reasons. Apple mentions of using appContext of CameraCaptureIntent, but not sure how above scenario is possible through that....unless I am missing something. Apple Reference What I have for CameraCaptureIntent: @available(iOS 18, *) struct LaunchMyAppControlIntent: CameraCaptureIntent { typealias AppContext = MyAppContext static let title: LocalizedStringResource = "LaunchMyAppControlIntent" static let description = IntentDescription("Capture photos with MyApp.") @MainActor func perform() async throws -> some IntentResult { .result() } }

My app is a SwiftUI document based app using DocumentGroupLaunchScene. In iOS(iPadOS) 18.4, when it launches, it has duplicate toolbar items, and when I close the current document and open other documents, it adds more duplicates. It also shows a wrong document name, which shows the first opened document name. This issue can be reproduced in the sample code (Building a document-based app with SwiftUI). I have submitted Feedback (FB17025216), but not sure if this is a known bug or if I'm missing anything.

iPhone7 : iOS 14.0 Beta 5 Xcode-beta Mac OS : 10.15.5 (19F101) crash info : ** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[PHPhotoLibrary presentLimitedLibraryPickerFromViewController:]: unrecognized selector sent to instance xxxxxx' terminating with uncaught exception of type NSException my code: (void)viewDidAppear:(BOOL)animated {   [super viewDidAppear:animated];   if (@available(iOS 14, *)) {     [[PHPhotoLibrary sharedPhotoLibrary] presentLimitedLibraryPickerFromViewController:self];   } }

On iOS 18.0+ simulators, tap any share link button from any app, select "Save to Files", the "Save" button is disabled. In all previous simulator versions this works. This behavior even happens with default Apple apps like Photos. Simulator: Version 16.0 (1037) XCode: Version 16.1 beta (16B5001e) macOS: 14.6.1 (23G93)

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

iPhone12 ， iOS26 NFCTagReaderSession cannot read NFCTagTypeISO7816Compatible anymore

When an iOS 26.0 device is prepared in supervised mode, wifi connection screen is showing when the device is restarted. This wifi connect appears always on restart. I have tried using Apple Configurator GUI and Command line (cfgutil) command. In both cases, The behavior Wifi screen is showing up on restart for supervised mode. Cfgutil command: cfgutil -C {Certificate} -K {Key} prepare --supervised --name {NAME} --host-cert {Certificate} --skip-all Note: In non-supervised mode and other iOS, the wifi screen is not showing. Apple Configurator version: 2.18 iOS version: 26.0 Device model: iPhone 11 and above. Anyone else facing this issue? Any help is super appreciated.

I’m developing an app that includes a navigation bar with a centered title and a single right bar button item. I’ve noticed that when both the navigation bar title and the right bar button item’s title are relatively long, the navigation bar title becomes hidden. This issue only occurs on iOS 26. When running the same code on iOS 18, the layout behaves as expected, with both elements visible. Has anyone else experienced this behavior on iOS 26? Is this a known layout change or a possible bug?

I've got a large and complex app which has several dependencies upon 3rd party libraries (installed as pods). The app is structured according to Model-View-Controller design and there is a requirement to implement the Model part as an .xcframework so it can be included and used in the original app along with a few new apps. However, Apple documentation states that umbrella frameworks are not supported (Technical Note TN2435). The Model code has several dependencies which would be totally unfeasible to replace or remove, for example it uses RealmSwift for database storage. Obviously it would be impossible to write one's own database storage scheme in place of using Realm. However, if my framework uses Realm as a dependency, then its now become an umbrella framework. So therefore not supported according to Apple documentation. So what are options/solutions?

Good day, I've uploaded a build to TestFlight, but received an automated response with the following error: ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it. Our project started in Objective-C and have mixed swift class and pods. The last uploaded build without any automated response was Nov 8, 2023. I'm using XCode Version 26.0.1 (17A400). I've tried every way i found in internet and i'm not able to find any solution for this. ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES use_frameworks! :linkage => :dynamic (in pods) We would appreciate any assistance in clarifying why this issue is occurring and how we should proceed to address it. Your guidance would mean a lot. Thank you.

In the Keynote/Numbers/Pages apps for iPhone, there is a Help menu item for presenting a Help modal view. The view has a button for showing the hierarchical table of contents, and a field for searching the Help pages. How is such a Help modal view built through SwiftUI ? In which format is the Help content stored ?

Hi, We began to get this new crash in codes that exist years ago from our recent released version, it crashed after a view removed itself from superview. We tried to look at the assembly code of NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex, find out that d0 <= 0 would branch to NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1. We believe that it's related with Autolayout, but setting a negative value for width or height constraints can't reproduce this crash. Here is the crash log Exception Type: NSInternalInconsistencyException Invalid parameter not satisfying: placeValue > 0 Exception Codes: fault addr: (null) Crashed Thread: 0 0 CoreFoundation ___exceptionPreprocess + 164 1 libobjc.A.dylib _objc_exception_throw + 88 2 Foundation -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 CoreAutoLayout NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1 + 100 4 CoreAutoLayout _NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex + 848 5 CoreAutoLayout _NSISSparseVectorAddVectorTimesScalar + 72 6 CoreAutoLayout -[NSISObjectiveLinearExpression replaceVar:withExpression:processVarNewToReceiver:processVarDroppedFromReceiver:] + 200 7 CoreAutoLayout ____substituteOutAllOccurencesOfBodyVar_block_invoke + 504 8 CoreAutoLayout __substituteOutAllOccurencesOfBodyVar + 340 9 CoreAutoLayout __pivotToMakeColNewHeadOfRow + 960 10 CoreAutoLayout -[NSISEngine removeConstraintWithMarker:] + 748 11 CoreAutoLayout -[NSLayoutConstraint _removeFromEngine:] + 140 12 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke + 164 13 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 14 UIKitCore -[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:] + 212 15 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke_2 + 148 16 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke + 544 17 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 18 UIKitCore -[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:] + 212 19 UIKitCore ___45-[UIView(Hierarchy) _postMovedFromSuperview:]_block_invoke + 84 20 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 21 UIKitCore -[UIView _postMovedFromSuperview:] + 512 22 UIKitCore ___UIViewWasRemovedFromSuperview + 136 23 UIKitCore -[UIView(Hierarchy) removeFromSuperview] + 244 Assembly of NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex CoreAutoLayout`NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex: -> 0x1ec1a2124 <+0>: pacibsp 0x1ec1a2128 <+4>: stp d11, d10, [sp, #-0x60]! 0x1ec1a212c <+8>: stp d9, d8, [sp, #0x10] 0x1ec1a2130 <+12>: stp x24, x23, [sp, #0x20] 0x1ec1a2134 <+16>: stp x22, x21, [sp, #0x30] 0x1ec1a2138 <+20>: stp x20, x19, [sp, #0x40] 0x1ec1a213c <+24>: stp x29, x30, [sp, #0x50] 0x1ec1a2140 <+28>: add x29, sp, #0x50 0x1ec1a2144 <+32>: mov x19, x1 0x1ec1a2148 <+36>: fmov d9, d2 0x1ec1a214c <+40>: fmov d10, d1 0x1ec1a2150 <+44>: fmov d8, d0 0x1ec1a2154 <+48>: mov x20, x0 0x1ec1a2158 <+52>: fcmp d0, #0.0 0x1ec1a215c <+56>: b.le 0x1ec1a2470 ; <+844> 0x1ec1a2160 <+60>: fcmp d10, #0.0 0x1ec1a2164 <+64>: adrp x8, 112778 .... 0x1ec1a2468 <+836>: ldp d11, d10, [sp], #0x60 0x1ec1a246c <+840>: retab 0x1ec1a2470 <+844>: bl 0x1ec1cac18 ; NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1 0x1ec1a2474 <+848>: b 0x1ec1a2160 ; <+60>