I'm trying to work out why Channel Sounding won't start on my device, and I'd be grateful for any pointers on what condition I haven't satisfied. What I see On an iPhone 17 Pro Max running iOS 27.0 beta (24A5390f), queried after the central manager reaches .poweredOn as the documentation requires: if #available(iOS 27.0, *) { print(CBCentralManager.supports(.channelSounding)) // false print(NISession.deviceCapabilities.supportsBluetoothChannelSounding) // true } No accessory or connection is involved — both are local queries. Because supports(.channelSounding) is false, the Core Bluetooth path fails with CBError code 13 ("Channel Sounding is not supported by the local or remote device"). I also tried calling startChannelSoundingSession(:) anyway, past my own capability check, against a connected peer; the same code 13 comes back from peripheral(:didCompleteChannelSoundingSession:), so it isn't merely an advisory check. The Nearby Interaction path gets further — its capability check passes, so session.run(_:) is called with NINearbyAccessoryConfiguration(bluetoothChannelSoundingIdentifier:previousBluetoothIdentifier:) against a paired, connected reflector — and then invalidates with NIErrorCodeSessionFailed (-5887). Same result with isCameraAssistanceEnabled set to both true and false. Apple's own "Measuring Distance Between Devices Using Channel Sounding" sample behaves identically on this device, so it isn't my code. What I've ruled out Querying before .poweredOn — the value is read in centralManagerDidUpdateState when the state is .poweredOn. Hardware — this is an iPhone 17 Pro Max, and Nearby Interaction's own capability check reports the hardware as capable. The Language & Region setting — changing it makes no difference. Beta staleness — updated across two betas, no change. The reflector — it implements the Ranging Service GATT server and the reflector role, and ranges successfully against another unit of its own model. What I'm unsure about The header comment for CBCentralManagerFeatureChannelSounding reads: The hardware and region supports channel sounding That's the only mention of "region" I can find in any Channel Sounding documentation — WWDC26 session 369 lists the N1 chip and the accessory-side requirements, but nothing about region, and there's no API to query that condition. My device is a South Korea market unit operating in South Korea, so I'm wondering whether that's what I'm hitting, but I have no way to confirm it. I'd also be glad to be told I'm simply wrong about something more mundane. Questions What conditions cause supports(.channelSounding) to return false on a device that has the N1 chip? Is region genuinely one of them, and if so, is it determined by the market the device was sold in, its current location, or something else? Should NISession.deviceCapabilities.supportsBluetoothChannelSounding be expected to agree with the Core Bluetooth check, or does it intentionally report hardware capability only? If the latter, is there a supported way to check Channel Sounding availability before running a session? For anyone with Channel Sounding working: which path are you using — Core Bluetooth's startChannelSoundingSession(_:), or NISession with NINearbyAccessoryConfiguration? And does supports(.channelSounding) return true for you? Question 3 is mostly to help me tell whether this is specific to my device. Thanks — happy to share more logs or a minimal reproducer if it's useful.

Hello Apple Developer Community, I am reaching out to see if anyone has experienced a similar administrative roadblock with the Apple MFi Portal (WPC Certification Program) and how it was successfully resolved, given that our official support channel tickets have been stalled for over two months. Background & Timeline of Events May 29 : Applied to join the WPC Certification Program. June 3 : Received an email stating the enrollment form was declined. June 17 : Replied via email providing additional clarification and context, as email was the only available communication channel. (with no alternative contact options accessible on the portal). Note: Due to an inactive or incorrect contact email provided in their system, my initial message was misdirected, causing two-weeks delay. June 25 : The WPC Cert team replied stating that we could enroll in the program. However, the portal status remained "Enrollment form declined" with no interactive options available. June 25 : Requested that they either approve our previous application or reset the account status so we could submit a fresh form. July 14 : Followed up due to a lack of response. July 16 : Support advised that we need to "create and fill out a new application." July 20 : Asked for instructions on how to create a new application or requested an account reset to enable a new submission. July 29 : Followed up once again to check on the progress. Present : No reply received, even after two weeks of waiting. The core Technical & Administrative Issue Portal UI Block : The portal page (https://mfi.apple.com/wpc-login) remains locked on the "Enrollment form declined" status screen. There are no buttons, menus, or interactive elements to reapply, submit a new form, or update the existing application. Troubleshooting Steps Taken: Cleared browser caches and tested using Safari's Private Browsing mode. Installed alternative browsers and attempted access via Incognito mode. The screen layout remains identical with no mechanism to clear the status or start fresh. Support Feedback Limitation : Support simply advised to "create and fill out a new application.", but provided no technical path or portal interface to actually do so under our current account. Help / Advice Requested Since our support ticket has been unresponsive for over two months despite multiple follow-ups: Has anyone encountered a UI lock like this on the MFi portal after a declined status? Is there a specific backend account reset procedure or alternate escalation path to clear an existing profile's status without forcing the creation of a new account? Any guidance, insights, or advice on how to escalate this efficiently would be greatly appreciated. Thank you for your time!

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

We have been using this path to detect whether Full Disk Access is granted: ~/Library/Application Support/com.apple.TCC/TCC.db Since macOS [27], reading this path fails with access denied even when Full Disk Access has been granted to the app, so the check now reports a false negative. Questions: Is there an API an app can use to detect whether Full Disk Access has been granted to it? 2. If not, is there another supported method to detect it? 3. If this path is no longer usable, which path can we probe to reliably determine that Full Disk Access is granted?

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.

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 trying to explore accessory setup kit and migrate an existing CoreBluetooth-paired BLE device into AccessorySetupKit using ASMigrationDisplayItem. The regular ASPickerDisplayItem discovery picker works perfectly on the same device/session/Info.plist. But ASMigrationDisplayItem consistently fails. Code let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: "0xFDEE") let migrationItem = ASMigrationDisplayItem( name: "HUAWEI FreeClip 2", productImage: productImage, descriptor: descriptor ) migrationItem.peripheralIdentifier = peripheralIdentifier // peripheralIdentifier is a valid CBPeripheral.identifier UUID // CBCentralManager is suspended before this call (suspendForASK) session?.showPicker(for: [migrationItem]) { error in // Completion is either called with error 500, or NEVER called (silent no-op) } Test Results (8 rounds) # Approach Result 1 suspendForASK → immediate showPicker Silent no-op 2 suspendForASK → 0.6s delay → showPicker Silent no-op 3 .activated event → showPicker (no CBManager exists yet) Silent no-op 4 viewDidAppear → 0.5s delay → showPicker Silent no-op 5 User taps alert button (explicit gesture context) → showPicker Silent no-op 6 Clear pickerDisplaySettings before migration showPicker Error 500 (pickerAlreadyActive) 7 invalidate() → activate() → immediate showPicker (fresh session) Silent no-op 8 invalidate() → activate() → wait for .activated → showPicker Silent no-op Round 6 logs (Error 500): [ASK] Starting migration for peripheral: D0F13212-**** Picker already activated ← System message [ASK] Migration picker failed: ASErrorDomain error 500. Round 8 logs (Silent no-op, cleanest test): XPC connection invalid ← System message [ASK] Session invalidated: no error [ASK] Session activated ← New session .activated [ASK] Executing pending migration showPicker after .activated // → NO pickerDidPresent, NO migrationComplete, NO completion callback, NO error, NO UI Ruled Out Info.plist — regular ASPickerDisplayItem works with identical config Session state — .activated confirmed, session non-nil CBManager conflict — suspended before migration; round 3 ran before any CBManager existed User gesture — round 5 inside button tap handler (same context as working picker) Timing — delayed to viewDidAppear, waited for .activated event peripheralIdentifier — valid UUID, device is actively connected via CoreBluetooth Questions Is ASMigrationDisplayItem fully functional on iOS 26.x? Across 8 different invocation patterns, it either returns error 500 or silently no-ops — no UI ever appears. What causes the residual "Picker already activated" state (error 500), and how do we properly reset it? The XPC connection invalid system message appears consistently. Does this indicate the daemon is rejecting the migration request? Are there prerequisites we're missing? E.g., must the device be disconnected from CB? Must NSBluetoothAlwaysUsageDescription be removed? Is there a different descriptor requirement for migration vs discovery?

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

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?

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.