Hello, We are testing Wallet passes with iBeacons in iOS 26 Beta. In earlier iOS releases, when a device was in proximity to a registered beacon, the corresponding pass would surface automatically. In iOS 26 Beta, this behavior no longer occurs, even if the pass is already present in Wallet. I have not found documentation of this change in the iOS 26 release notes. Could you please confirm whether this is expected in iOS 26, or if it may be a Beta-specific issue? Any pointers to updated documentation would be appreciated. Thank you.

Hi, I am trying to build a very simple iOS app in Xcode that starts an NFCNDEFReaderSession when I press a button. My goal right now is only to verify that the NFC reading process starts correctly on a real iPhone. I am not trying to publish the app on the App Store. When I try to start the session, I get this error in the console: -[NFCHardwareManager areFeaturesSupported:outError:]:435 XPC Error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.nfcd.service.corenfc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.nfcd.service.corenfc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction.} and then my app reports that NFC is not available on this device. Important details: I added Near Field Communication Tag Reading in Signing & Capabilities. I added the NFC privacy usage description in the target settings. I am using automatic signing. I am not using an Apple Developer Program paid account. I am using a Personal Team / free account. I should also mention that I am not experienced with Swift/iOS development, so I may be missing something basic in the setup. My question is: Is this expected when using a Personal Team / free account, or is there some configuration issue I should still check? I am happy to provide any additional information needed

Is there any information available on how developers can implement the "Firmware Update Readiness" and/or "Firmware Update Status" characteristics in HomeKit? Many consumer devices support this (showing an "update available" icon), however, there appears to be nothing in the documentation about this characteristic, and it is not listed as an option in the HomeKit Accessory Simulator. Thanks in advance!

The app crashes when using EAAccessoryManager.showBluetoothAccessoryPicker(withNameFilter:) to connect to a Bluetooth accessory in a multi-accessory scenario. The crash occurs immediately after selecting an accessory from the picker UI. Steps to Reproduce: Ensure a Bluetooth accessory (Accessory A) is already connected to the iPhone/iPad and is visible in Bluetooth settings. Launch the app. Initiate a connection flow that presents the Bluetooth accessory picker using EAAccessoryManager.showBluetoothAccessoryPicker(withNameFilter:). Ensure another compatible accessory (Accessory B) is available and visible in the picker. Select Accessory B from the picker to connect. After connection, simulate a disconnect of Accessory B (e.g., power cycle or remove battery). Attempt to reconnect Accessory B by triggering the same picker flow again. Select Accessory B from the picker. Result: The accessory connects successfully at the system level. The app crashes immediately after selecting the accessory from the picker (during dismissal). Reproducibility: Occurs consistently under the described multi-accessory scenario. Not observed when only a single accessory is present.

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?

We were using a BLE mouse with HID command in iOS device, mainly iPhone device and we can use the mouse pointer using the assistive touch . But when we updated the iOS version to iOS 26.4.2 , the mouse pointer become very slow and jumpy. So something changed in the latest version that hurt the BLE mouse pointer Please update your feedback or similar issues

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!

Watch is no longer capturing biometric data. No sleep, HR, or SPO2, steps and activity after downloading 26.5 watchOS beta. Reset watch and was not able to resolve the issue.