Environment: iPhone 17 / iPhone 17 Pro (Apple N1 chip) iOS 26.x Xcode 26 Framework: Flutter app with native iOS BLE library (CoreBluetooth) We have a production IoT app that communicates with BLE nodes (Nordic, PIC, EnOcean peripherals) using an advertising/scanning-based protocol — not GATT connections. The app broadcasts commands via CBPeripheralManager (advertising service UUIDs) and receives responses by scanning with CBCentralManager (reading manufacturer data and service UUIDs from advertisement packets). This workflow has been reliable across all iPhone models from iPhone 8 through iPhone 16 Pro Max. On iPhone 17 devices, we are experiencing multiple failures in this workflow. Architecture: Sending commands: We use CBPeripheralManager.startAdvertising() with CBAdvertisementDataServiceUUIDsKey to broadcast a UUID-encoded command to nearby nodes. Receiving responses: We use CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) and filter responses in centralManager(_:didDiscover:advertisementData:rssi:) by matching CBAdvertisementDataServiceUUIDsKey or CBAdvertisementDataManufacturerDataKey against expected UUID masks. Communication pattern: Advertise a command → stop advertiser → start scanner → wait for matching response → process result. Typical timeout is 1.5 seconds per exchange. Issues observed on iPhone 17: peripheralManagerDidStartAdvertising behaviour change After calling CBPeripheralManager.startAdvertising(:), the delegate callback peripheralManagerDidStartAdvertising(:error:) either fires with errors that did not occur on previous hardware, or advertising does not appear to reach the peripheral nodes at all. The same advertising payload works immediately when tested on iPhone 15/16. Is the N1 chip's Bluetooth 6 stack handling CBAdvertisementDataServiceUUIDsKey advertising differently? Are there new constraints on advertising payload size or format? Scanner returning fewer/no results with withServices: nil Our scanner uses scanForPeripherals(withServices: nil) because we need to read manufacturer data from advertisement packets and filter using a custom UUID mask. On iPhone 17, we observe significantly fewer didDiscover callbacks compared to iPhone 15/16 in the same physical environment, with the same nodes advertising. We understand that passing service UUIDs in withServices: is recommended, but our protocol requires reading raw manufacturer data bytes that aren't associated with a single service UUID — we use mask-based matching (e.g., filter mask 11110000-0000-0000-0000-000000000000 against scan results). Has the N1 chip changed the rate or filtering behaviour of unfiltered BLE scans? Is there a new throttling mechanism? Background scanning stops immediately When the app moves to background, scanning appears to stop entirely on iPhone 17 — even with bluetooth-central in UIBackgroundModes. On iPhone 16, background scanning continued (at reduced intervals) and delivered results for peripherals advertising filtered service UUIDs. Aggressive session termination on app backgrounding Our advertise-then-scan sequences (typically 1.5s round-trip) are being interrupted when the user briefly switches apps. The CBPeripheralManager stops advertising and the CBCentralManager stops scanning, causing timeout errors. This was not observed on previous iPhone models with the same iOS background mode configuration. Questions for Apple: Are there documented changes to CoreBluetooth behaviour on the N1 Bluetooth 6 chip that affect advertising-based (non-GATT) communication patterns? Has the scan response rate for scanForPeripherals(withServices: nil) been intentionally reduced on iPhone 17? Is CBCentralManagerOptionRestoreIdentifierKey now required for reliable background scanning on iPhone 17, or is this a known regression? Are there new advertising payload constraints (size, format, interval) that we should be aware of for the N1 chip? What we've tried: Added NSBluetoothAlwaysUsageDescription and NSBluetoothWhileInUseUsageDescription to Info.plist Confirmed Bluetooth permissions are granted Tested with identical BLE nodes that work on iPhone 15/16 Verified CBManagerState.poweredOn before all operations Any guidance or known workarounds would be greatly appreciated. Happy to provide sysdiagnose logs or a minimal reproducible sample project.

Right now, I am scanning for specific BLE peripherals with my iPad app, using this: [self.cbCentralManager scanForPeripheralsWithServices:serviceUUIDsToScanFor options:@{CBCentralManagerScanOptionAllowDuplicatesKey:@YES}]; I have the "CBCentralManagerScanOptionAllowDuplicatesKey" set true because I need to be able to detect when a peripheral is no longer advertising, so I capture each "didDiscoverPeripheral" callback and set a 3-second timer that notifies the user that that peripheral is no longer in range if another didDiscoverPeripheral hasn't been received in that time. The peripherals all advertise at 100ms intervals. What's weird is that if I leave the scan on for a long time, the advertising packets slow down, and eventually one of those timers times out, around about one or two minutes for the first instance, and then every 10-20 seconds after that. I've checked with ATS for all the BLE traffic, and there are indeed > 3-second gaps in the advertising packets that the iPad sees, so it's not my code introducing the gap. Is there some reason long-running scans should not be done on iPadOS (both 18 and 26.1 used)? I've tested out switching my scan to "stopScan" and restart it every 10 seconds, and that seems to have resolved the issue, but it's unclear why that would matter (and that does not seem like an appropriate use of the stop and start scans). Thanks!

I downloaded "Dockkit ADK 1.0" and trying to compile, and some openssl include .h files are missing, for example in HAPBoringSSL.c, the below files can't found: #include <openssl/bn.h> #include <openssl/evp.h> #include <openssl/hkdf.h> #include <openssl/hmac.h> #include <openssl/rand.h> where can I get these .h files? I'm worrying about the version conformance if I fetch these files from internet.

I'm looking for technical documentation on Apple's IEEE 754 implementation on the M1 - M4 chips. Specifically, I'd like to know how NaN payloads are handled in arithmetic operations. Does anyone know where this information is available? Thank you!

Dear Sir, I have some questions of IC firmware development of Find My. Any rule request that item must include dual bank feature in IC? I am using Nordic SDK_Connect SDK, Apple has own SDK? If yes, can I download it to use? In Find-My, Apple has service UUID in bluetooth IC? Thank you. Best regards, Sam Ng

Hey everyone, how’s it going? I’d like to know if, by enrolling in Apple’s MFi program, I’ll gain access to develop my own tags and my own app to track them using Apple’s Find network. I also read that there’s an estimated cost of $4 per device—does that apply to each device produced, or only at the time of registering the device, with no fee for additional units?

How to remove Matter accessory connection artefacts? This appears after connecting and then removing a Matter test accessory. Please see attached screenshot:

when I go to software and update it says can’t check for updateS.

I updated my iPhone to 26 and I just went to to to see if my iPhone was up to date I went and see but a came across this

Will UVC native support come for the Iphone as well? So, using external cameras with the ipad is greatly beneficial, but for the iphone, it can make it a production powerhouse! So, have there been discussions around bringing UVC support for the Iphone as well? and if so, what were your conclusions?

Hi everyone, while testing HKWorkoutSession with HKLiveWorkoutBuilder on iOS 26 Beta (cycling workout), I noticed the following behavior: – Starting a cycling HKWorkoutSession automatically connects to my Bluetooth heart rate monitor and records HR into HealthKit ✅ – However, my Bluetooth cycling power meter and cadence sensor (standard BLE Cycling Power & CSC services) are not connected automatically, and no data is recorded into HealthKit ❌ On Apple Watch, when starting a cycling workout, these sensors do connect automatically and their data is written to HealthKit — which is exactly what I would expect on iOS as well. Question: Is this by design, or is support for power and cadence sensors planned for iOS in the same way as on watchOS? Or do we, as developers, need to implement the BLE Cycling Power and CSC profiles ourselves (via CoreBluetooth) if we want these metrics? Environment: – iOS 26 Beta – HKWorkoutSession & HKLiveWorkoutBuilder (cycling) – Bluetooth HRM connects automatically – BLE power & cadence sensors do not This feature would make it much easier to develop cycling apps with full HealthKit integration, and also create a more consistent user experience compared to watchOS. Thanks for any insights!

Hello, The application I'm working on must report new hardware connections. To retrieve connected displays information and monitor new connections, I'm using the "Core Graphics" framework (see recommendation https://developer.apple.com/forums/thread/779945). The monitoring logic relies on a callback function which invokes when the local display configuration changes(kCGDisplayAddFlag/kCGDisplayRemoveFlag). #import <Cocoa/Cocoa.h> static void displayChanged(CGDirectDisplayID displayID, CGDisplayChangeSummaryFlags flags, void *userInfo) { uint32_t vendor = CGDisplayVendorNumber(displayID); if (flags & kCGDisplayAddFlag) { if (vendor == kDisplayVendorIDUnknown) { NSLog(@"I/O Kit cannot identify the monitor. kDisplayVendorIDUnknown. displayId = %u", displayID); return; } NSLog(@"%u connected. vendor(%u)", displayID, vendor); } if (flags & kCGDisplayRemoveFlag) { NSLog(@"%u disconnected", displayID); } } int main(int argc, const char * argv[]) { @autoreleasepool { CGDisplayRegisterReconfigurationCallback(displayChanged, NULL); NSApplicationLoad(); CFRunLoopRun(); } return 0; } The test environment is a Mac mini with an external display connected via HDMI. Everything works correctly until the system enters sleep mode. Upon wakeup, the app reports two displays: the first with vendor ID kDisplayVendorIDUnknown and the second with the expected vendor ID. Why does Core Graphics report two connections during wakeup? Is there any way to avoid this? Thank you in advance.

Dear Apple Developer / MFi Program Support, I am exploring technical possibilities for screen sharing and remote interaction between iOS devices and external hardware (e.g., embedded systems, in-vehicle systems) for a prototype we are currently developing. I have reviewed the public iOS developer documentation, but I would appreciate your guidance and clarification on the following advanced use cases, particularly in the context of MFi or enterprise-level integrations: Full-Screen Sharing of iOS Device Is it possible to mirror or stream the entire iOS screen, even when the app is running in the background or not in the foreground? Does ReplayKit or any other framework under the MFi or enterprise entitlements allow full-device screen capture outside the app context? Remote Touch Injection and Control Is there any officially supported mechanism, under MFi or otherwise, that allows external systems to remotely control an iOS device’s touch interface (e.g., simulate gestures, taps, swipes)? Are any of the following permitted under special entitlements: Access to IOHIDEventSystem or similar private APIs for input injection? Communication over USB or network to relay control commands that simulate direct user interaction? Hardware-Level Integration and Entitlements Does the MFi Program allow: Use of private frameworks or entitlements to build low-level integrations for iOS device control or mirroring? Communication over USB/Lightning/USB-C to enable bi-directional interaction (streaming out, commands in)? What are the specific APIs or entitlements available under MFi that enable these use cases? Can you provide references to documentation, SDKs, or prerequisites for companies seeking such capabilities? Eligibility and Certification Process What are the criteria to be approved for the MFi program with access to such advanced capabilities? Can PoC or early-stage research prototypes be eligible, or is MFi access restricted to commercial production intent? How long does it typically take to gain access to these entitlements (assuming NDA and certification requirements are met)? Alternative Pathways If MFi access is not feasible in the short term, is there any Apple-supported alternative path (e.g., test device provisioning, enterprise signing, custom profiles) that permits more advanced capabilities for prototyping purposes? We are not looking to publish this as a general App Store app at this stage, but rather to demonstrate feasibility as part of an innovation prototype that may lead to further OEM-level engagement in the future. Thank you for your support and guidance. Best regards,

I am working on an app that requires the usage of CoreBluetooth – using both its CBPeripheralManager and CBCentralManager classes. Our app works with other phones and hardware peripherals to exchange data – so we wanted to explore adding AccessorySetupKit to streamline the hardware connection process. AccessorySetupKit has been integrated (while CBPeripheralManager is turned off) and works great, but even with ASK added to our app's plist file and not in use, CBPeripheralManager fails with error: Cannot create a CBPeripheralManager while using AccessorySetupKit framework. Is there any workaround or suggested path forward here? We'd still really like to use ASK while keeping our existing functionality, but are not seeing a clear way to do so.

I am developing an app that communicates with external BLE device over GATT. The device has a secure-read characteristic exposing some of it's data and requires pairing/bonding in order to communicate with it. I was able to pair and connect with the device using AccessorySetupKit and .bluetoothPairingLE option: let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: serviceUUID) descriptor.supportedOptions = [.bluetoothPairingLE] let picketItem = ASPickerDisplayItem(name: name, productImage: image, descriptor: descriptor) In this case when setting up accessory, I was prompted to compare passkeys and after confirming I can read the characteristic etc. Then I tried adding .confirmAuthorization to picker item and problems started: let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: serviceUUID) descriptor.supportedOptions = [.bluetoothPairingLE] let picketItem = ASPickerDisplayItem(name: name, productImage: image, desc pickerItem.setupOptions = [.confirmAuthorization] When setting up, I can see a passkey to be confirmed, but when confirmed the setup ui get's suck in loading state. Under the hood in logs, I can see that my app has connected to peripheral and was able to read the characteristic. I am unsure why the ui is stuck in loading state in this case. What is the difference when using .confirmAuthorization option and what should be the proper flow of events to setup accessory and then access protoected characteristic?

I have some logic which requires NFC support on the device. This is what I'm using to make sure that it's available: isNFCMissing = !NFCNDEFReaderSession.readingAvailable && !NFCTagReaderSession.readingAvailable && !NFCVASReaderSession.readingAvailable Is it possible for isNFCMissing to be true even if the device has an NFC chip. The minimum iOS version for the application is 16 which is only supported on devices with an NFC chip to begin with.

as i want to tract activity of iphone user using core motion framework , guide me through .

Hi everyone, I am developing a .NET MAUI Mac Catalyst app (sandboxed) that communicates with a custom vendor-specific HID USB device. Within the Catalyst app, I am using a native iOS library (built with Objective-C and IOKit) and calling into it via P/Invoke from C#. The HID communication layer relies on IOHIDManager and IOUSBInterface APIs. The device is correctly detected and opened using IOHIDManager APIs. However, IOHIDDeviceRegisterInputReportCallback never triggers — I don’t receive any input reports. To investigate, I also tried using low-level IOKit USB APIs via P/Invoke from my Catalyst app, calling into a native iOS library. When attempting to open the USB interface using IOUSBInterfaceOpen() or IOUSBInterfaceOpenSeize(), both calls fail with: kIOReturnNotPermitted (0xe00002e2). — indicating an access denied error, even though the device enumerates and opens successfully. Interestingly, when I call IOHIDDeviceSetReport(), it returns status = 0, meaning I can successfully send feature reports to the device. Only input reports (via the InputReportCallback) fail to arrive. I’ve confirmed this is not a device issue — the same hardware and protocol work perfectly under Windows using the HIDSharp library, where both input and output reports function correctly. What I’ve verified •Disabling sandboxing doesn’t change the behavior. •The device uses a vendor-specific usage page (not a standard HID like keyboard/mouse). •Enumeration, open, and SetReport all succeed — only reading input reports fails. •Tried polling queues, in queues Input_Misc element failed to add to the queues. •Tried getting report in a loop but no use.

Problem Description: Since Our USB hubs are capable of sending Vendor Defined Messages (VDMs) over a USB Type-C cable connection, they can programmatically place iOS, iPadOS, and macOS devices into DFU mode—without requiring any physical button interaction. Recently, we identified an issue when invoking DFU mode on an iPhone 15 using this method. Upon entering DFU mode, the device enumerates with USB Product ID 0x1881 (“Debug USB” – KIS interface). At that point, the deviceinterfaced daemon (launched by launchd) immediately detects the device and claims exclusive access to the USB interface. As a result, when our API Service attempts to communicate with the device through standard IOKit methods, it fails with the following error: 0xe00002c5 ((iokit/common) exclusive access and device already open) This prevents our libraries from reading the iBoot string (USB serial number string) that Apple devices normally expose in standard or recovery modes—information that includes ECID, CPID, CPRV, CPFM, BDID, and SCEP. This creates a significant barrier, as our API service becomes unable to perform subsequent device restoration operations as we missed the critical information. Request for Guidance: I’ve included the following context for your analysis and review. Using the launchctl unload command can temporarily stop it; however, I’d like to know if there’s an API-level mechanism to programmatically prevent deviceinterfaced from claiming access from within our API Service. Could you please advise on the following points? 1.  Managing deviceinterfaced Access • What is the proper way to stop or prevent deviceinterfaced from claiming exclusive access in this case, so that the API Service can read device information and starts restoring the device from that point? • Is there a recommended method or entitlement that allows third-party services to communicate with Apple devices while they are in Debug USB (KIS) mode? 2.  Guidelines and API Access • Are there any Apple-supported APIs or developer guidelines that would permit controlled access to the iBoot interface without conflicting with deviceinterfaced?

I have an iOS/iPadOS app and 'm trying to communicate with usb smart card reader using CryptoTokenKit on all platforms (ios/ipados/macos). Minimal Repro Code import CryptoTokenKit import SwiftUI struct ContentView: View { @State var status = "" var body: some View { VStack { Text("Status: \(status)") } .padding() .onAppear { let manager = TKSmartCardSlotManager.default if manager != nil { status = "Initialized" } else { status = "Unsupported" } } } } And my entitlement file has only one key: com.apple.security.smartcard = YES Behavior • iPadOS (on device): status = "Initialized" ✅ • macOS (native macOS app, with the required CryptoTokenKit entitlement): status = "Initialized" ✅ • macOS (Designed for iPad, regardless of CryptoTokenKit entitlement): status = "Unsupported" → TKSmartCardSlotManager.default is nil ❌ Expectation Given that the same iPadOS build initializes TKSmartCardSlotManager, I expected the iPad app running in Designed for iPad mode on Apple silicon Mac to behave the same (or to have a documented limitation). Questions Is CryptoTokenKit (and specifically TKSmartCardSlotManager) supported for iPad apps running on Mac in Designed for iPad mode? If support exists, what entitlements / capabilities are required for USB smart-card access in this configuration? If not supported, is Mac Catalyst the correct/only path on macOS to access USB smart-card readers via CryptoTokenKit? Are there recommended alternatives for iPad apps on Mac (Designed for iPad) to communicate with USB smart-card readers (e.g., ExternalAccessory, DriverKit, etc.), or is this scenario intentionally unsupported? Thanks!