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.

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.

I'm encountering a bug developing a (Thunderbolt) PCIDriverKit dext. The system runs well for a while, and then the hardware instance is shut down by the OS (Sonoma 14.7.6) for some unknown reason, but the dext is not, so hardware reads return 0xFFFFFFFF (device disconnected). There is no crash report, or diagnostic report. I don't see anything related in a sysdiagnose capture. The only hint I can find is the kernel logs indicate: 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompletionTimeoutInterrupt Completion timeout detected at address 0xe00510020 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompleterAbortInterrupt Completer Abort received (pri_status = 0x00100407, sec_status = 0x200000f0): 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompleterAbortInterrupt * Received Master Abort on a link side of the Root Complex That address (0xe00510020) looks like it's our PCI device (at a BAR0, offset 0x0020) read. What does this error explicitly mean? Did the device take too long to respond to the read request? After the event, every device on that Thunderbolt bus is disconnected, and a reboot seems to be required. Hardware is a 14" 2023 MacBook Pro M3.

Hi everyone, We're working on a custom USB-C accessory based on an MCU (ARM Cortex-R8, running RT-Thread RTOS) with a Synopsys DWC3 USB Device controller. Our goal is to stream real-time sensor data (~10 Mbps) from the accessory to an iPhone via USB-C. We're planning to configure our MCU as a USB NCM device (following USB-IF NCM v1.0 spec), so the iPhone sees it as a standard Ethernet adapter. We would then run a lightweight TCP/IP stack (lwIP) on the MCU side and communicate with our iOS app via standard BSD Sockets / Network.framework over the virtual network — no gateway, just direct IP-to-IP communication within the local network that the NCM device presents. Questions: Feasibility confirmation: Based on our description, do you see any issues with this approach on iPhones including iPhone 16 and newer models? Our USB controller supports High-Speed (480 Mbps), so NCM throughput should not be a bottleneck. No-gateway concern: We don't plan to implement a DHCP server or gateway on the MCU. We'd use static IP configuration (or Link-Local addressing) for direct socket communication. Is there anything in iOS's network stack that would prevent this — for example, requiring a DHCP-assigned address or a default gateway before allowing socket traffic on the USB Ethernet interface? MFi and long-term viability: We understand this approach doesn't require MFi certification, since NCM is a standard USB-IF class and iOS has built-in Ethernet support. However, we want to make sure this doesn't go against the spirit of the MFi program or Apple's accessory policies. Is there any risk that Apple might restrict or block non-MFi NCM accessories in a future iOS update? We'd rather invest our effort in the right approach from the start. App Store review: Would an iOS app that communicates with our accessory exclusively via standard socket APIs (Network.framework / BSD Sockets) over the USB Ethernet interface face any App Store review issues — assuming it doesn't use any private APIs and doesn't declare MFi support? Any guidance would be greatly appreciated. We want to make sure we're building on a solid foundation.

Hello, My name is Jisoo Kim, and I am a product designer currently developing a tray and case accessory for the Apple Magic Keyboard and Magic Trackpad. I have reviewed the Apple Accessory Design Guidelines, however I was unable to find specific guidance covering accessories of this type. As a designer and an engineer who values complementing Apple's devices without interfering with their functionality, I want to ensure our development aligns with Apple's standards. Given the absence of specific guidelines for this product category, I have two questions: Would it be appropriate to reference guidelines from other similar Apple accessory categories as a basis for our design decisions? Are there any additional considerations or requirements we should be aware of when developing this type of accessory? Any guidance you could provide would be greatly appreciated.

Hi everyone, I am seeking clarification regarding the communication capabilities between an ESP32 microcontroller and Apple's latest devices, specifically the iPhone 16 Pro Max and iPad Pro, both equipped with USB-C ports. Background: MFi Certification: Historically, establishing communication between external devices and iOS devices required MFi (Made for iPhone/iPad) certification. But I remember this being necessary in the Lightning Cable to USB era. With the introduction of USB-C ports in recent iPhone and iPad models, there is an indication that MFi certification may no longer be necessary for certain peripherals. Perhaps I'm not confident on the terminology here: https://mfi.apple.com/en/who-should-join Project Requirements: I am working on a sensor research project that necessitates the collection of low-latency time-series data from an ESP32 microcontroller, which features a USB-C port. The data needs to be transmitted to an iPhone 16 Pro Max or iPad Pro. Bluetooth communication has proven insufficient due to its limited data transfer rates (~1.2 Mbps with L2CAP). While NEHotspot could be an alternative, it restricts the iPad's internet connectivity. Therefore, establishing a direct USB-C connection between the ESP32 and the iOS device appears to be the most viable solution. Questions: MFi Certification Necessity: Is MFi certification still required for an ESP32 microcontroller to communicate with iPhone 16 Pro Max or iPad Pro via USB-C? USB-C Communication Support: Do the iPhone 16 Pro Max and iPad Pro natively support serial communication over USB-C with microcontrollers like the ESP32? If not, are there recommended protocols or interfaces to facilitate this communication? App Development Considerations: Would developing a custom iOS application be necessary to handle data transmission from the ESP32 over USB-C? If so, are there specific APIs or frameworks provided by Apple to support this functionality? Data Transfer Rates: Considering the need for high-speed data transfer, are there any limitations or considerations regarding the data transfer rates achievable through a USB-C connection between the ESP32 and iOS devices? Thank you!

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?

We are conducting iBeacon compliance testing for our device and would like to clarify two test items from the iBeacon test specification: Regarding Tx power stability verification over time and across different battery capacities: Could you please specify the required test duration and the exact test procedure? Specifically, how long should the Tx power be monitored to verify stability within the 2dB standard deviation requirement, and what battery capacity levels (e.g., 100%, 50%, 20%, low battery threshold) should be tested? Regarding device interoperability with iOS CoreLocation APIs for beacon-based region monitoring and ranging: Could you please provide guidance on the test methodology? Specifically, what test cases, expected behaviors, and pass/fail criteria should we follow to verify correct interoperability with region monitoring (didEnter/didExit) and ranging (didRangeBeacons) APIs? Any official test guidelines or reference documents would be greatly appreciated.

I’m seeing a Bluetooth call audio routing issue on a new iPhone 17 Pro running iOS 26.5.1, build 23F81. Bluetooth media audio works normally. Music and video audio stay on Bluetooth headphones without issues. The problem appears only when the device switches into call audio / HFP mode. Tested with multiple earbuds: Samsung, OPPO, Huawei and CMF Buds Pro 2. The behavior is similar with all of them. There are no other Bluetooth devices connected. Call Audio Routing is already set to Bluetooth Headset in Accessibility settings. The issue affects cellular calls, FaceTime Audio, Telegram and Signal. In some cases the earbuds seem to switch into call mode, but the call audio route falls back to the iPhone receiver or speaker instead of staying on the Bluetooth headset. After the call ends, Bluetooth media audio returns normally. I captured a sysdiagnose right after reproducing the issue. Relevant observations from the logs: Device: iPhone18,2 iOS: 26.5.1 Build: 23F81 Sysdiagnose time: 2026-06-03 11:22:03 +0300 In Bluetooth/CoreCapture/bluetooth_status.txt, Bluetooth was ON 3 paired devices were present 1 device was connected Connected device at the time: CMF Buds Pro 2 So the headset was not simply disconnected from the phone. In the powerlog, before the call the audio route was HeadphonesBT for media playback. Around the FaceTime Audio test, HeadsetBT / PhoneCall appeared, but then the route moved to ReceiverAndMicrophone / Speaker instead of staying on HeadsetBT. During a later cellular call, the active PhoneCall route was also ReceiverAndMicrophone rather than HeadsetBT. After the call ended, the route returned to HeadphonesBT for media playback. This looks like the Bluetooth connection remains alive, but call audio / HFP routing fails. The same sysdiagnose also contains CentauriFirmwareEvent entries under crashes_and_spins from the previous day. They show: subsystem = BT host-reason = firmware crash BTMAIN panic faulting_task = link_manager_thread LMAC_5G watchdog expired SCAN watchdog expired These firmware crash events do not happen at the exact same timestamp as the call test, so I’m not claiming that every call directly crashes Bluetooth firmware. But the sysdiagnose shows both incorrect Bluetooth call audio routing and separate BT firmware crash events. Has anyone seen similar behavior on iPhone 17 / iOS 26 with Bluetooth HFP call audio? Could this be a known iOS 26 / Apple N1 / Bluetooth firmware issue, or does it look more like a hardware defect of this particular device?

I recently updated my iPhone SE (2020) to the iOS 27 beta, and initially the experience was excellent. The phone felt noticeably faster and more responsive, and I was genuinely impressed with the update. However, after about a day of usage, I started experiencing a charging-related issue. One night, I left my phone connected to the charger before going to sleep when the battery was at 55%. The next morning, I found that the battery had dropped to 42% instead of charging. I checked all connections and confirmed that the charger, cable, and power source were properly connected. When I disconnected and reconnected the charger, the charging lightning bolt icon would briefly appear, then turn grey after about two seconds, and finally disappear completely a couple of seconds later. The phone would not charge. Assuming it might be a faulty charger or cable, I tested with: A different Apple charger A different Lightning cable The same issue persisted. Next, I connected the phone to my Mac. Surprisingly, it started charging, and Finder recognized the device normally. Over the next few days, the behavior became inconsistent: Sometimes the phone would charge. Sometimes it would not charge at all. Connecting to the Mac worked most of the time, but occasionally even that failed. I also noticed another unusual behavior: If I unplugged the Lightning cable from the iPhone and plugged it back in, the charging symbol would briefly appear. However, if I left the cable connected to the iPhone and unplugged/replugged only the USB end from the power adapter, there would be no response whatsoever—no charging sound, no charging icon, nothing. I cleaned the charging port, cable connectors, and charger contacts, but the issue remained. At that point, I realized the problem started immediately after installing the iOS 27 beta. To verify whether it was software-related, I restored the device back to iOS 26.5. After downgrading, the charging issue completely disappeared, and the phone began charging normally again with the same charger and cable. Based on my testing, this appears to be a software-related issue introduced in the iOS 27 beta rather than a hardware problem. I am posting this in case other iPhone SE (2020) users are experiencing similar charging behavior after updating to the beta. Device: iPhone SE (2020) Issue: Intermittent charging failure after updating to iOS 27 beta Status: Resolved after restoring to iOS 26.5

Is there any UIRequiredDeviceCapabilities string that can be used to restrict an app to Apple TV 4K (2nd generation) or later hardware? I can’t find one. I’m working on a tvOS app that uses Continuity Camera. That feature only works on Apple TV 4K (2nd gen) and Apple TV 4K (3rd gen) hardware. There seems be no way to warn App Store customers that the app will not work on Apple TV 4K (1st gen). In the App Store or TestFlight, a user with a 1st gen device incorrectly sees a compatibility note that the app “Works on this Apple TV”. Setting a minimum OS version is not currently a helpful path for me — even tvOS 26.5 is compatible with 1st generation hardware. I can’t think of a good way to prevent users with an incompatible Apple TV 4K from installing an app that won’t work on their 1st generation devices. Any ideas? Am I missing something?

On Apple Watch (reported several times, but also on a powerful Ultra3), the CMAltimeter occasionally stops delivering updates for a while (a couple of minutes) then resumes. This makes for a terrible user experience. What could cause this? Is there a way to (best case) prevent this, or (workaround) detect it? This is production critical, any help would be greatly appreciated. Thanks a lot!