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 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.

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.

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

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 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