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.

DJI's DNG files display abnormally in the Apple Photos app on iOS devices, with dark areas showing as very black, but the same files appear normal in Photoshop. I'm curious about what causes this issue.

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?

My MacBook Pro M5 running MacOS Tahoe 26.3 beta fails to detect two identical ASUS ROG Swift OLED PG32UCDM monitors simultaneously. Only one display is recognized at a time. One potential root cause might be that both monitors report identical binary EDID serial numbers (0x01010101), and the MacBook Pro M5 appears to use this value exclusively for display identity rather than combining it with other more detailed information (e.g., port, or alphanumeric serial number). I've verified that the monitor EDID binary serial numbers are in fact identical -- however the alphanumerical serial numbers are not identical. NOTE: This behavior is specific to the MacBook Pro M5 — when connecting both monitors via usb-c to a Mac Mini M4 Pro running the same MacOS Tahoe 26.3 beta, the monitors work fine. The OS detects both and assigns different names to them (PG32UCDM (1) and PG32UCDM (2)). NOTE: I could be wrong about this root cause, I don't have a way to disprove it, though the fact the monitors work fine on a Mac Mini is suspicious. What I have tried: Connecting the two monitors using different monitor ports (one on DisplayPort, another on HDMI, etc.), and different MacBook ports (one on HDMI, another on USB-C, etc.) Bumping down the resolution on the monitors to "1920x1080 (low resolution)" and 30Hz to rule out bandwidth issues. Connecting one, or both, monitors to CalDigit TS5 Plus dock. Neither alternate configuration yields the device recognizing both screens. Using BetterDisplay to import a manually-edited EDID for the screen, with a different binary EDID value, manufacturer name, etc. I've also verified that if I plug in my Apple Studio Display as one of the monitors, then the MacBook recognizes both one of the PG32UCDM monitors and the Studio Display at the same time. The issue seems to occur only when both monitors plugged into it are the same PG32UCDM model. When I have both monitors plugged into my MacBook, each time I disconnect the cable to whichever monitor is currently recognized, it immediately recognizes the other monitor. Plugging the cable for the disconnected monitor back in has no effect. I'm at a loss. Has anyone run into this issue and found a successful workaround that is not one of the approaches I've described above?

Hi everyone, I'm developing a standalone Matter controller app on iOS 18+ using Apple's Matter.framework directly — without integrating with Apple Home or HomeKit. We manage our own Matter fabric and handle the full commissioning flow ourselves. Current setup: BLE-based Matter device discovery and commissioning via Matter.framework Own fabric management (not adding devices to Apple Home) During development, we rely on the "Bluetooth Central Matter Client Developer Mode" profile to enable BLE access The challenge: As we approach our App Store release, we need end users to be able to commission Matter devices without installing any developer profiles. I'm trying to figure out the correct entitlement path for a non-HomeKit Matter controller app in production. Questions: Which entitlements are required for a third-party Matter controller app using Matter.framework directly (not via HomeKit) to work in production? Is there a formal entitlement request process for something like com.apple.developer.matter.allow-setup-payload? If so, where do we initiate it? Are there additional program memberships or certifications required beyond the standard Apple Developer Program membership? We've gone through the Matter framework documentation and relevant WWDC sessions but haven't found a clear answer specifically for non-HomeKit standalone Matter controller apps. Would appreciate any input from Apple staff or developers who've shipped a similar app. Happy to provide more details if needed. Tagging for visibility: @Apple or relevant team — this involves a non-HomeKit Matter.framework usage pattern and entitlement approval process.

After hardware and mobile phone hid mode pairing, the first connection is successful, after a while disconnect and reconnect,APP monitoring Bluetooth error NSLocalizedDescription = "Peer removed pairing information"; Failed to connect Hardware engineers detect the pairing information and find that the local pairing information of the iPhone has changed, which is a non-mandatory phenomenon

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

EASession(accessory:forProtocol:) always returns nil — MFI accessory iAP2 Platform: iOS 17+ | Hardware: Custom MFI-certified accessory (USB-C, iAP2) | Language: Swift Problem We have a custom MFI-certified accessory communicating over USB-C using ExternalAccessory. The app calls EASession(accessory:forProtocol:) after receiving EAAccessoryDidConnect but it always returns nil. We never get past session creation. What we have verified We captured a sysdiagnose on-device and analysed the accessoryd-packets log. The full iAP2 handshake completes successfully at the OS level: USB attach succeeds MFI auth certificate is present and Apple-issued Auth challenge and response complete successfully IdentificationInformation is accepted by iOS — protocol string and Team ID are correct EAAccessoryDidConnect fires as expected iOS sends StartExternalAccessoryProtocolSession — the OS-level session is established So the hardware, MFI auth, protocol string, and Team ID are all correct. Despite this, EASession(accessory:forProtocol:) returns nil in the app. We also confirmed: Protocol string in UISupportedExternalAccessoryProtocols in Info.plist matches the accessory exactly Protocol string in code matches Info.plist App entitlements are correctly configured EAAccessoryManager.shared().registerForLocalNotifications() is called before connection Current connection code @objc private func accessoryDidConnect(_ notification: Notification) { guard let accessory = notification.userInfo?[EAAccessoryKey] as? EAAccessory else { return } DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { self.tryConnectToAccessory() } } private func tryConnectToAccessory() { DispatchQueue.main.asyncAfter(deadline: .now() + 3.0) { for accessory in EAAccessoryManager.shared().connectedAccessories { let session = EASession(accessory: accessory, forProtocol: "") // session is always nil here } } } Questions The packet log shows a ~4 second gap between EAAccessoryDidConnect firing and iOS internally completing session readiness (StartExternalAccessoryProtocolSession). Is there a reliable way to know when iOS Is it actually ready to grant an EASession, rather than using a fixed delay? Is there a delegate callback or notification that fires when the accessory protocol session is ready to be opened, rather than relying on EAAccessoryDidConnect + an arbitrary delay? Are there any known conditions on iOS 17+ under which EASession returns nil even though the iAP2 handshake completed successfully at the OS level? Is retrying EASession after a nil result a supported pattern, or does a nil result mean the session will never succeed for that connection? Any guidance appreciated.

In an application we are developing, we would like to show a (non-interactable) textfield when a hardware keyboard is connected to the iPad. Therefore my question: Using SwiftUI, is it possible to detect the presence of a hardware keyboard and store that state inside a boolean like isHardwareKeyboardConnected?

Hi, We are currently in the process of getting an custom iAP2 device communicating via USB-C. We have been using the 'EADemo' app as a test app to ensure full function before certification. Currently, the device completes the authentication and identification successfully. The device appears within the 'EADemo' app, and we are able to select it and see the available protocol. Selecting the protocol sends the EAStartSession command to the accessory and we ACK it. This is where the issues begin. Attempting to send either a string or hex packet results in nothing being sent. The app does not appear to attempt to send a packet when these are pressed. The 'EADemo' app also does not increment its receive counter when the accessory sends an EA packet, but we do receive the ACK from the device. This indicates the device is receiving the packet, but not processing it in app. Sending the EASessionStatus from the accessory with a status of okay does not change the behavior. Sending the EASessionStatus packet from the accessory with a status of closed results in the device sending an EAStopSession packet. The issue does not appear to be with the accessory or the underlying transport layer. Previous attempts to contact MFi support resulted in them referring me to developer support. Are there any known issues within the 'EADemo' app that we should know about/and or need to fix? Does Apple have any other EA example application? Are there any other publicly avalilbe EA examples that Apple would recommend us trying? Thanks, Mike

Hello dear Apple Platform Engineers, I'm working on an iOS App that connects to a Bluetooth Low Energy Peripheral in the foreground. Whenever the App moves into Background, we want to continue syncing data & therefore implemented State Restoration to be informed about Discovery, Connect, Disconnect or Characteristic changes in the Background in order to wake the App up whenever it was "Terminated due to memory issue". I consulted https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW1 for this & assigned: CBCentralManagerOptionRestoreIdentifierKey Reinstantiate the dedicated CentralManager & implemented the centralManager(_ central: CBCentralManager, willRestoreState dict: [String : Any]) Delegate Additionally, I assigned the following keys on connect(_ peripheral: CBPeripheral, options: [String : Any]? = nil) CBConnectPeripheralOptionNotifyOnConnectionKey CBConnectPeripheralOptionNotifyOnDisconnectionKey CBConnectPeripheralOptionNotifyOnNotificationKey However, from my experience the App gets woken up, but neither the willRestoreState nor the didDiscover, didConnect or didDisconnectPeripheral is called even though launchOptions?[UIApplication.LaunchOptionsKey.bluetoothCentrals] as? [String] is not empty. What might I be missing when trying to make this approach work? Thanks a lot for any insights & support!

After update to ipad OS 26.4 or latest 26.3., we’ve been experiencing issues with focusing. We have an app that scans 1x1 cm QR or DataMatrix codes from a distance of 10–20 cm, and users across different devices (ipad 9 and 10) are reporting problems. I didn’t find anything related to the camera in the version changelog, but users from various places are reporting problem with camera.

Hi, We are facing the issue of commissioning our Matter device to google home through iOS device will be 100% failed. Here is our test summary regarding the issue: TestCase1 [OK]: Commissioning our Matter 1.4.0 device to Google Nest Hub 2 by Android device (see log DoorWindow_2.0.1_Google_Success.txt ) TestCase2 [NG]: Commissioning Matter 1.4.0 device to Google Nest Hub 2 by iPhone13 or iPhone16 (see log DoorWindow_2.0.1_Google_by_iOS_NG.txt ) TestCase3 [OK]: Commissioning our Matter 1.3.0 device to Google Nest Hub 2 by iPhone13 In TestCase2, we noticed that device was first commissioned to iOS(Apple keychain) then iOS opened a commissioning window again to commission it in Google’s ecosystem, and the device was failed at above step 2, so we also tried: Commissioning the device to Apple Home works as expected, next share the device to Google Home app on iOS, this also fails. Commissioning the device to Apple Home works as expected, next share the device to Google Home app on Android, this works as expected and device pops up in Google home of iOS as well. Could you help check what's the issue of TestCase2? Append the environment of our testing: NestHub 2 version Google Home app version

Hi, we have developed an application that streams data from two BLE peripherals at a rate of 14.5kbps per peripheral. Until now, our devices streamed in near real time with no lag on all Apple devices with Bluetooth 5.0 or greater. Since the release of the iPhone 17 series and the iPad A16, we have reports from users of the data being streamed at significantly lower rates than expected. Any help here would be greatly appreciated as our customers are being affected by this change.

目前这个findmy 设备是已经通过MFI认证，不过后续想的在”Find My “应用上像 AirTag 一样支持UWB测距功能。 寻找了相关资料，在这篇文章《Nearby-Interaction-Accessory-Protocol-Specification-Release-R4》中找到了UWB的相关功能，但是需要我们自己开发第三方应用。 所以需要怎么做才可以做到像airtag 一样在“Find My”应用上显示距离和方向

The FindMy device is currently MFI certified, but we plan to support UWB ranging functionality in the Find My app, similar to AirTag. After searching for relevant information, I found the relevant UWB functions in this article "Nearby-Interaction-Accessory-Protocol-Specification-Release-R4", but we need to develop third-party applications ourselves. So how can we make it display distance and direction in the "Find My" app like AirTag does?

Hello Apple Developer Technical Support Team, I’m working on an iOS banking/security SDK and we’re trying to match an Android feature that reads payment cards via NFC (EMV). On Android, this is implemented using an NFC scanning screen (e.g., “NfcScanActivity”) that can read EMV data from contactless credit/debit cards. Could you please clarify the current iOS capabilities and App Store policy around this? On iOS, is it currently possible for a third-party App Store app to read contactless credit/debit cards using Core NFC (i.e., accessing EMV application data/AIDs from payment cards)? If this is possible, what are the supported APIs/frameworks and any entitlement requirements (if applicable)? If this is not possible for App Store apps, could you recommend the closest acceptable alternatives for achieving a similar user outcome? For example: Using Apple Pay / PassKit flows for payment-related experiences Card scanning alternatives (camera-based OCR) for capturing card details (if allowed) Using an external certified card reader accessory (MFi) and required approach/entitlements Any other Apple-recommended approach for “card verification / identification” without reading EMV NFC data Our goal is not to bypass security restrictions, but to provide a compliant solution on iOS comparable to Android’s NFC-based card reading, or to adopt an Apple-approved alternative if direct EMV reading is not supported. If helpful, I can share a brief technical summary of the Android behavior and the exact data we need to obtain (e.g., whether it’s card presence verification vs. reading specific EMV tags). Thank you for your guidance. Best regards, Anis

On the iPad Pro 12.9-inch (3rd generation) cellular model, when you touch the screen with four fingers and then move your fingers, the touch is no longer detected. The same operation with one to three fingers works normally. This phenomenon does not occur when accessibility is turned on. Is this a beta-specific issue that will be fixed in the official release?

Hello, I would like to discuss the behavior of the expiration of NFCPresentmentIntentAssertion (test in iOS 18.5). In the documentation we have : The intent assertion expires if any of the following occur: The intent assertion object deinitializes Your app goes into the background 15 seconds elapse BUT; in fact ; only the 1st rule is applied. The expiration seems to be random after the usage of CardSession and that's difficult to give to the user a good experience. Has someone faced the same kind of issue; or can give an explanation? Regards, François

Hello Apple Developer Technical Support Team, I’m working on an iOS banking/security SDK and we’re trying to match an Android feature that reads payment cards via NFC (EMV). On Android, this is implemented using an NFC scanning screen (e.g., “NfcScanActivity”) that can read EMV data from contactless credit/debit cards. Could you please clarify the current iOS capabilities and App Store policy around this? On iOS, is it currently possible for a third-party App Store app to read contactless credit/debit cards using Core NFC (i.e., accessing EMV application data/AIDs from payment cards)? If this is possible, what are the supported APIs/frameworks and any entitlement requirements (if applicable)? If this is not possible for App Store apps, could you recommend the closest acceptable alternatives for achieving a similar user outcome? For example: Using Apple Pay / PassKit flows for payment-related experiences Card scanning alternatives (camera-based OCR) for capturing card details (if allowed) Using an external certified card reader accessory (MFi) and required approach/entitlements Any other Apple-recommended approach for “card verification / identification” without reading EMV NFC data Our goal is not to bypass security restrictions, but to provide a compliant solution on iOS comparable to Android’s NFC-based card reading, or to adopt an Apple-approved alternative if direct EMV reading is not supported. If helpful, I can share a brief technical summary of the Android behavior and the exact data we need to obtain (e.g., whether it’s card presence verification vs. reading specific EMV tags). Thank you for your guidance. Best regards, Imran