Hi I don’t know if I come to correct place but fingers crossed we can get somewhere I am currently receiving some software bugs on my new device model iPhone 17 pro recently brought also I have been on social media and I have noticed a few people have mentioned the same thing about the same situation as I thought it was a bit normal to have them type of issues so i thought I’d look into it and see if this problem could be resolved a manner

When using AccessorySetupKit to remove accessories, a pop-up window appears when calling removeAccessory. However, the text in the pop-up window does not change according to my iPhone's language settings and remains only in English. Has anyone encountered this issue? Does Apple have any plans to address this compatibility issue?

Reported by one of my users: iPad Pro M2, iPadOS 26.6 Pencil stops hovering after start drawing for several minutes. When the issue happens, UIBarbuttonItem reacts to pencil hovering in a specific UI but had no reaction to hovering in another status in the same app. Can be recovered by "transfer or reset iPads -> reset all settings", but will happen again in several minutes. Can't be reproduced on my iPad Pro M4 iPadOS 27.0 beta4. Is this a known issue? Feedback: https://feedbackassistant.apple.com/feedback/24306250 Similar reports: https://forums.macrumors.com/threads/pencil-hover-not-working-unless-i-tap-the-screen-first.2367801/

After the app completes BLE pairing with the peripheral, the Bluetooth connection works as expected. However, once the peripheral is power‑cycled, the app can no longer establish a BLE connection with it. Normal functionality can only be restored by forgetting the peripheral and re‑pairing.

Heating issues on MacOS 27 Beta on normal browser surfing.

Hello Apple Engineering Team, I'm submitting a detailed technical report regarding a USB-PD charging regression affecting the iPad Pro 12.9" (M2) in iPadOS 27 Public Beta 2. This appears to be a recurring firmware-level issue across multiple beta cycles. TECHNICAL SPECIFICATION: • Device: iPad Pro 12.9" (A2766 / M2 SoC) • Storage Configuration: 512GB NAND • Current Build: iPadOS 27 PB2 (24A5390f) • Feedback ID: FB24178289 PHENOMENOLOGY: USB-C port fails to negotiate Power Delivery after beta installation Device draws minimal standby current (charging icon appears but doesn't stabilize) Flashing red battery icon persists through extended cold charging (>10 hours) Force restart does not clear the USB controller state Battery management subsystem appears functional but USB-PD handshake blocked ISOLATION TESTING: • Hardware elimination: 16 USB-C ports across 7 chargers tested (UGREEN, Anker certified) • Cable verification: 60W and 100W USB-C cables confirmed working on companion devices • Cross-platform validation: iPhone 12 and iPhone 14 Plus on identical iOS 27 beta charge without issue • Network connectivity: WiFi/BT functional when device can boot (pre-brick state) • Conclusion: Fault localized to M2 power management firmware, not peripherals or general OS stack RECURSION HISTORY: • iPadOS 18 Beta 2: Similar USB-C charging failures on M2 devices (public reports on r/iPadOS) • iPadOS 26 Beta 9: USB-C completely disabled for charging/connecting (Facebook iOS Beta community) • iPadOS 27 Public Beta 2: Recurrence of identical symptom set POWER MANAGEMENT SUBSYSTEM ANALYSIS: The M2 architecture implements USB-C PD negotiation at the S0ix power state transition layer. The fact that minimal standby current flows but full PD handshakes fail suggests a firmware-state corruption in the power delivery controller that survives normal reboot sequences but may require full power-cycle or firmware rewrite to restore. REQUESTED ACTION ITEMS: Firmware diagnostics on affected M2 power management subsystem DFU-mode USB controller reinitialization protocol verification Engineering acknowledgment of Feedback ID FB24178289 Prioritized investigation of recurring M2 USB-PD regressions across beta cycles Interim recovery guidance for affected users pending permanent fix USER IMPACT CONTEXT: This failure renders the device nonfunctional for users reliant on specific hardware configurations. In this case: religious observance apps requiring 512GB local storage + academic workload starting August 26. No alternative device available for equivalent functionality. I am available for additional diagnostic cooperation or test build evaluation as needed. Respectfully, Jason Bulnes Feedback ID: FB24178289

Hi everyone, I am trying to wake up/relaunch an app that was force-quit by the user via a BLE advertisement packet. According to TN3115 ("App Force Quit by the user" section), an app generally cannot be woken up after a user force-quit. However, Note 5 states that starting in iOS 26, an app authorized via AccessorySetupKit can indeed be relaunched. Environment iOS Version: iOS 26.5 (Note: revised to standard versioning) Xcode Version: Xcode 26.3 Implementation Details 1. Info.plist Configuration <key>NSBluetoothAlwaysUsageDescription</key> <string>We need Bluetooth to discover and connect to your accessory.</string> <key>UIBackgroundModes</key> <array> <string>bluetooth-central</string> </array> <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> <key>NSAccessorySetupBluetoothServices</key> <array> <string>0000XXXX-0000-1000-8000-00805F9B34FB</string> </array> <key>NSAccessorySetupBluetoothNames</key> <array> <string>MyDeviceName</string> </array> 2. Workflow & Code Steps Initialize ASAccessorySession and call activate(). Pair/authorize the BLE peripheral using ASPickerDisplayItem. Initialize CBCentralManager with state restoration: let options: [String: Any] = [ CBCentralManagerOptionRestoreIdentifierKey: restoreIdentifier, CBCentralManagerOptionShowPowerAlertKey: true ] centralManager = CBCentralManager(delegate: self, queue: nil, options: options) Start scanning: let scanOptions = [CBCentralManagerScanOptionAllowDuplicatesKey: true] centralManager?.scanForPeripherals(withServices: serviceUUIDs, options: scanOptions) Handle state restoration: func centralManager(_ central: CBCentralManager, willRestoreState dict: [String : Any]) { if let services = dict[CBCentralManagerRestoredStateScanServicesKey] as? [CBUUID], let options = dict[CBCentralManagerRestoredStateScanOptionsKey] as? [String : Any] { central.scanForPeripherals(withServices: services, options: options) } } Receive discovery callback: func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) { if peripheral.name == "MyDeviceName" { // Send a local notification } } Current Behavior Foreground: Local notification triggers as expected. Background: Local notification triggers as expected. Force Quit by User: No notification is received / App is not relaunched. Issue The app fails to relaunch when force-quit by the user, which seems to contradict the behavior described in TN3115 Note 5. Is there a specific configuration, entitlement, or additional CBCentralManager setup required to allow BLE advertisements to relaunch the app after a user force-quit via AccessorySetupKit? Any guidance would be greatly appreciated!

I recently noticed a UX inconsistency while using the battery charge limit feature on my MacBook with a MagSafe charger. With the optimized charging feature, users can set a custom maximum charging limit (for example, 95%) to improve battery health. However, the MagSafe LED indicator continues to show the charging state (amber) even after the device reaches this user-defined limit. Previously, the LED would turn green when charging reached 100%, clearly indicating a “fully charged” state. But now, when charging stops at a user-defined limit, there is no clear visual feedback that charging has effectively completed based on the user’s preference. This creates confusion, as the LED suggests that charging is still ongoing even though the system has stopped charging at the configured limit. A possible approach to improve this could be to treat the user-defined limit as an effective “fully charged” state during charging. For example: if is_charging: if battery_percentage < user_defined_limit: LED = AMBER else: LED = GREEN This would align the physical LED indicator with the system’s charging behavior and improve clarity for users without requiring hardware changes. Has anyone else observed this behavior, or is there any existing workaround?

I’m debugging a custom BLE HID device on iPhone. It is a composite HID mouse + keyboard dongle. Setup: Hardware: Seeed XIAO nRF52840 Firmware: Adafruit Bluefruit Arduino / BLEHidAdafruit BLE HID report map: stock Adafruit composite HID with keyboard, consumer, and mouse reports GAP/advertising appearance: HID_MOUSE iOS adopts the device as an AssistiveTouch pointer Mouse movement and clicks work correctly Keyboard symptom: Lowercase/unshifted characters type correctly. Shifted characters lose the Shift modifier during text input: - A -> a - T -> t - DoorDash -> doordash - ! -> 1 - @ -> 2 - # -> 3 - { -> [ - } -> ] Confirmed: The iOS app sends the exact intended string to the dongle. Firmware receives the exact string. Firmware computes and sends the expected HID modifier/keycode: A sends modifier 0x02 + HID_KEY_A ! sends modifier 0x02 + HID_KEY_1 A lone isolated "A" still lands as "a", so this does not appear to be a timing or repeated-key issue. Cmd+Space works from the same HID keyboard report path and opens Spotlight. Full Keyboard Access is off. Turning AssistiveTouch off does not fix it. The iPhone never shows "Hardware Keyboard" settings for this device, even when searching Settings. Question: Is there a documented distinction on iOS between accepting BLE HID keyboard reports for global shortcuts, such as Cmd+Space, and admitting the same device as a full Hardware Keyboard for text composition? In particular: Does the absence of Hardware Keyboard settings mean iOS has not classified the device as a real external keyboard? Can a composite BLE HID device advertised as HID_MOUSE be accepted for pointer input but have Shift ignored for text input? Does iOS require a different GAP appearance, HID report-map structure, report ordering, or separate keyboard identity for Shift/modifier text composition to work? Is there a recommended way to build a BLE HID device that preserves AssistiveTouch pointer behavior while also being treated as a full external keyboard?

Body: Hello, I am experiencing a persistent and frustrating audio dropout issue after updating my Apple TV to tvOS 27.0 Beta(Build: 24J5325d).[Hardware Setup] Source: Apple TV 4K running tvOS 27.0 (24J5325d) Display: Sony BRAVIA XR-65X90L (Connected via HDMI 4) Audio System: Sony HT-S2000 Soundbar + SA-RS3S Rear Speakers + SA-SW3 Subwoofer (Connected to TV HDMI 3 eARC port) [The Problem] While watching content randomly across various apps (including YouTube, Infuse, and Apple TV app), the audio suddenly cuts out completely. The Sony TV then displays a system error message: "TV speakers activated due to audio system communication failure." This issue is intermittent, occurring once every few days. Once it happens, the eARC handshake appears completely locked up. The only way to temporarily restore the audio system connection is to perform a full system reboot of the Sony TV or toggle the Apple TV audio input source. [StepsTried/Troubleshooting] 1.Format Isolation: If I force the Apple TV audio output format to "Change Format -> Dolby Digital 5.1" instead of the default uncompressed LPCM, the connection becomes significantly more stable and the dropouts cease. 2.Cable & TV Check: All HDMI cables are Ultra High Speed (HDMI 2.1) compliant. TV settings such as "RS232C control" have been disabled, but the issue persists on the default Auto/LPCM audio output mode. [Expected Behavior] The multi-channel audio stream (LPCM/Atmos) sent from Apple TV should pass through the eARC chain smoothly without causing HDMI-CEC/eARC packet collision or freezing the display's audio daemon mid-playback. It seems like the LPCM audio stream packaging or the CEC heartbeat signals in this specific tvOS 27.0 beta build occasionally send corrupted or unexpected data packets, triggering an aggressive eARC protection/fai-safe mechanism on the Sony TV side. Is anyone else experiencing similar eARC dropouts with Sony sound systems on this beta? Any insights from the engineering team regarding HDMI/CEC driver changes in this build would be highly appreciated. Thank you!

Basic Information:tvOS Build: tvOS 18 Developer Beta (Build 24J5325d)Apple TV Model: Apple TV 4KConnected TV Model: Sony XR-65X90L (Firmware up to date)Connection Setup: Apple TV connected directly to Sony TV via High-Speed HDMI cable.Summary:After updating to tvOS build 24J5325d, the HDMI-CEC (Bravia Sync) feature broken specifically for powering off the television. When putting the Apple TV to sleep (either via the Control Center or by holding the Power button on the Siri Remote), the connected Sony XR-65X90L TV remains powered on. Steps to Reproduce: Turn on both Apple TV and Sony XR-65X90L TV.Ensure HDMI-CEC is fully enabled on both devices (Control TVs and Receivers is ON on Apple TV; BRAVIA Sync Settings are fully enabled on the Sony TV).Press and hold the Power button on the Siri Remote, or open the Control Center and select "Sleep".The Apple TV goes into sleep mode, but the Sony TV stays turned on. Expected Results: The Sony XR-65X90L TV should automatically power off or enter standby mode via HDMI-CEC when the Apple TV goes to sleep. Actual Results: The Apple TV sleeps, but the Sony TV remains completely powered on, requiring the use of the original Sony remote to manually turn it off. Attempted Troubleshooting (Issue Persists): Hard reset performed on both devices (completely disconnected from AC power and HDMI cables for 60 seconds).Toggled HDMI-CEC settings OFF and ON again on both the Apple TV and Sony TV.Rescanned HDMI devices within the BRAVIA Sync settings menu on the Sony TV.

Hi Apple Team, We recently migrated our BLE accessory from a legacy CoreBluetooth pairing flow to Accessory Setup Kit (ASK) and are very happy with the simplified system-managed pairing experience. However, we've encountered a user experience challenge during first-time pairing and would appreciate your guidance on the recommended approach. Our BLE accessory requires users to perform a few important actions before the pairing can complete successfully. For example: Turn on the product to make the accessory discoverable. Complete the authentication/confirmation code displayed on both the iPhone and the accessory. With our previous CoreBluetooth implementation, we had full control over the pairing flow and could display step-by-step instructions before and during pairing. This helped users successfully complete these device-specific actions. After migrating to Accessory Setup Kit, the pairing experience is managed entirely by the system. While this provides a much cleaner and more consistent user experience, it also means we cannot present contextual guidance or instructions while the pairing flow is in progress. As a result, we're seeing a noticeable increase in first-time pairing failures because users are not aware of these required actions at the appropriate time. We understand that these requirements are specific to our accessory rather than a limitation of ASK. Our question is: what is the recommended approach for handling accessories that require user interaction during the system-managed pairing flow? Specifically: Are there any Apple-recommended UX patterns or best practices for this scenario? Is the expectation that all necessary guidance should be presented before invoking the ASK pairing sheet? Are there any upcoming enhancements to Accessory Setup Kit that would provide developers with more flexibility to improve the first-time pairing experience? We'd appreciate any guidance or recommendations from the ASK team. Understanding the intended design pattern will help us build the best possible onboarding experience for our users. Thank you!

We use BLE devices connected to an iPhone, but after updating iOS to version 26.4 from version26.2, the following issue occurred: The device operates normally immediately after pairing. However, after disconnecting and reconnecting, the connection drops approximately 30 seconds later. The details of the error passed to func centralManager(_ central: CBCentralManager, didDisconnectPeripheral peripheral: CBPeripheral, error: Error?) at that time are as follows: Error Domain=CBErrorDomain Code=7 "The specified device has disconnected from us." What could be the possible cause of this?

I'm encountering a strange behavior with one of my home's on Home app while I'm off network. When I launch the app it indicates that the hub is not responding and all of my devices are unavailable. However, on the menu bar at the bottom if I switch to "Automation" and back to "Home" the pop-up goes away and my devices are accessible again (sometimes this take a few attempts). Siri is also able to consistently control my devices without an issue. The same behavior occurs with Home app on other devices (e.g. Mac) and with other members that have access to the household. 3rd party HomeKit app like "Controller" does not have an issue. This issue began with iOS 26 and I haven't had much luck resolving the issue. I already tried rebooting everything, including removing and re-adding an Apple TV (home hub). I have other homes shared with me in Home App with similar network/environment that are still working. The home I'm having issues has the most number of devices though (over 100+).

I am currently developing an app for MacOS that needs to control HomeKit devices like lights. However, it seems like MacOS is supported on the official documentation, but not when I try to create an app ID on developer.apple.com. On the link https://developer.apple.com/apple-home/, MacOS is clearly showed as supported for MacOS. But when I try to create an app ID, it shows that it is only compatible for iOS, VisionOS and WatchOS. Could this be clarified? Best regards, orangeidle25

Summary: EASession initialization consistently returns nil on iOS 27 when connecting to a MFi-certified USB accessory. The same code and accessory work correctly on iOS 26. Apple's official EADemo sample code also fails on iOS 27. Steps to Reproduce: Connect MFi-certified USB accessory to iOS 27 device via Lightning/USB-C Observe that EAAccessory is detected: connected=YES, connectionID=34951162 Confirm protocol string is in accessory.protocolStrings Call [[EASession alloc] initWithAccessory:accessory forProtocol:@"*******"] EASession returns nil Expected Results: EASession should be created successfully, allowing input/output stream configuration. This works correctly on iOS 26 with identical code and accessory. Actual Results: EASession returns nil. System log shows: "[#ExternalAccessory] ERROR - .../EASession.m:-[EASession dealloc] - 212 unable to close session for _accessory=0x1513d3bb0 and sessionID=65536" Note: sessionID=65536 indicates EASession was partially created but immediately deallocated. Configuration: Device: 所有机型 iOS Version: 27.0 beta Xcode Version: 26.3 (17C529) Build SDK: iOS 26 SDK Accessory PPID: cfc Accessory Firmware: L.B.1 Accessory Hardware: 1.0.1 App: Both our production app and Apple's official EADemo sample code Info.plist Configuration: UISupportedExternalAccessoryProtocols includes "*****" UIBackgroundModes includes "external-accessory" Device Settings: Settings > Privacy & Security > Security > Wired Accessories: "Automatically Allow When Unlocked" Additional Notes: EAAccessory object is properly created and accessible Accessory protocol string matches exactly All MFi certificates present (certSerial: 16 bytes, certData: 608 bytes) Issue reproduced with Apple's official EADemo sample code, confirming this is not an application-level bug Issue does NOT occur on iOS 26 with same device and accessory Regression: iOS 26: Works correctly iOS 27: Fails consistently

I'm building an access-control feature. My iOS app acts as a BLE peripheral, and a fixed door reader acts as the central. The app produces an encrypted token; the reader receives that token, validates it, and unlocks the door. The reader is a custom, non-iOS BLE device (embedded module), not an Apple device. I need this to keep working while the app is in the background, and ideally after it has been terminated. I've enabled the bluetooth-peripheral background mode (UIBackgroundModes). What I understand so far (please correct me) From the startAdvertising(_:) documentation and prior forum threads, when a CBPeripheralManager advertises while the app is in the background: CBAdvertisementDataLocalNameKey is not advertised, and the advertised service UUIDs are moved to a special "overflow" area that "can be discovered only by an iOS device that is explicitly scanning for them." That seems to imply a non-iOS central cannot discover my peripheral by service UUID once the app is backgrounded. This is exactly my concern. Questions Background discovery — Given the overflow-area behavior, is there any supported way for a non-iOS central to discover an iOS peripheral that is advertising while the app is backgrounded? Or is discovery by a non-Apple scanner fundamentally blocked in that state? Advertisement payload — My token could be delivered two ways: (a) embedded directly in the advertisement (e.g. CBAdvertisementDataManufacturerDataKey / service data), or (b) via a GATT characteristic after connection. In the background, is manufacturer data / service data included in the advertisement at all, or is it dropped like the local name? Characteristic read while backgrounded — If a connection does succeed, can the reader still read or subscribe to a GATT characteristic served by my app while the app is in the background? Any limits on value size or notifications in that state? Terminated state — With State Preservation and Restoration (CBManagerOptionRestoreIdentifierKey + peripheralManager(_:willRestoreState:)), will the system keep advertising and relaunch my app into the background when the reader connects, even after the app was terminated by the system? Does the same overflow-area limitation apply to restored advertising? Force-quit — My understanding is that if the user force-quits the app (swipe up in the App Switcher), the system will not relaunch it or preserve its Bluetooth state. Is that correct, and is there any supported exception? Recommended design — Given the goal (a non-iOS reader must reliably receive an encrypted token from a backgrounded/terminated iOS app), is the peripheral role even the recommended approach? Or should I invert the roles (reader = peripheral, app = central), which seems better suited to background operation? Thanks in advance.

I have purchased an universal, non-official Apple TV remote, with a little more buttons than on the official one (i.e. the CH-/CH+) buttons. I wanted to use the GCMicroGamepad property from the underlying GCController (from GameController framework), in order to use these buttons, but although I've linked this remote to my Apple TV device (in Settings > Remotes and Devices > Learn Remote), my app doesn't recognize it (it's not being listed in GCController.controllers()). So my question is, is there something specific I can do so I can use this remote as a GCController? Or maybe is there something specific to hardware that I have to know for this to work? Thank you.

Hello, I am developing a cross-platform mobile app that communicates with an external accessory over a serial (UART) link. HARDWARE : The accessory is an optical reading probe that connects to the phone via USB. Inside the cable there is a standard FTDI USB-to-serial chip (similar to common FTDI/CP210x USB-serial adapters). WHAT WORKS On Android, our app: Detects the USB device Opens the serial port Reads and writes raw bytes successfully This wired FTDI path is fully implemented and working. WHAT DOES NOT WORK On iPhone, using the same wired FTDI USB accessory: We connect via Lightning or USB-C adapter The app never sees the FTDI device We cannot find a public iOS API to open a generic USB-serial port MY QUESTION : Is there any supported way for a third-party iOS app to communicate with a generic FTDI USB-serial device over a wired USB connection? Specifically, am I missing: A public Apple framework for USB serial? An Info.plist key or entitlement? A system driver on iOS similar to macOS AppleUSBFTDI (TN2315)? Or is wired USB-serial on iPhone only possible with MFi-certified accessories (External Accessory framework) or another transport such as Bluetooth LE? WHAT I HAVE ALREADY CHECKED External Accessory: seems to require MFi hardware and a registered protocol string. Our FTDI probe is not MFi. TN2315 (AppleUSBFTDI): appears to be macOS only, not iOS. Physical USB connection: cable fits, but no serial API is exposed to the app. ENVIRONMENT Platform: iOS (iPhone) Language: C# / .NET-iOS Need: transparent byte-level serial read/write SUMMARY: Android USB-serial works with our FTDI wired accessory. iOS does not. Am I missing something on iOS, or is generic FTDI USB-serial simply not supported for third-party iPhone apps? Thank you for any guidance.

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.