Dear Apple： We are developing an app for file sharing between mobile devices. We want to create an iOS app that can continue sharing files with other devices even when it is running in the background. We are using WLAN channels for file sharing. Could you please advise on which background persistence measures we should use to ensure the iOS app can maintain file transfer when it goes to the background? Thank you.

Dear Apple: If a BLE advertisement carries both a 16-bit service UUIDs and a 128-bit service UUIDs along with a local name, the local name will be placed in the scan response, then when the advertisement is turned off, both the 16-bit and 128-bit service UUIDs disappear while the local name persists. Subsequently, when transmitting a new advertisement that includes the 16-bit service UUIDs and local name, the resulting advertisement contains two local names. What methods can be used to avoid having two local names appearing simultaneously?Thanks

Dear Apple: After upgrading to version 26 of the iPhone, when broadcasting using the local name, the iPhone 15 Pro Max was truncated to iPhone 15 Pro Ma with a type of 08 (shortened), but the overall length of the broadcast did not exceed 31 bytes

After upgrading to iOS system 26, the local name broadcast type is 08, but before upgrading, it is 09 and will be included in the scan resp message; In version 26, the scan resp will also include Manufacturer Specific Data. Before the upgrade, the broadcast message may not necessarily include Manufacturer Specific Data; What I want to ask is, are there any restrictions on Bluetooth broadcasting in version 26? Is it necessary to include Manufacturer Specific Data data? If Manufacturer Specific Data data is included, it may cause fields in the local name broadcast to be truncated and use simple names of type 08

When I startAdvertising, my localName is long，Will not be truncated and the type is 0X09; self.advertisementData = @{CBAdvertisementDataLocalNameKey: localDevName, CBAdvertisementDataServiceUUIDsKey: @[[CBUUID UUIDWithString:serviceUUID]] }; [self.peripheralManager startAdvertising:self.advertisementData]; IOS 18.5: The service uuids in ADV_IND occupies 24 bytes, the local name in SCAN_RESP is 20 bytes in size and has not been truncated, and there is no manufacturer specific data in SCAN_RESP;You can view the following image： But in IOS26, why is the local name truncated to only 6 bytes for the same message, and why does SCAN_RESP always contain Manufacturer Specific Data; Why is there such a big difference, and what changes has iOS 26 made for broadcasting? Is it necessary to include Manufacturer Specific Data in the IOS 26 SCAN.RESP message? What documents are available for reference? Is there any way to ensure that the local name is not truncated? Is there a maximum length limit Are there other ways to broadcast longer data? Does anyone know why? thank

Hi, My app clip card launched well on IOS 18, but failed to open saying "this app clip requires IOS 18.1 or later version" on IOS17, But the target minimum deployments is configured as IOS 15.6, and check ed the app clip no using apis above IOS 18.1, anyone knows what steps i should do to figure out the reasons?

Dear Apple: We are developing a file management-related app, and I would like to retrieve the list of files from the "Recents" section under "Favorites" in the Mac sidebar, then display this information in the app's interface for users. Is there an API available to obtain this information?

After Apple-to-Apple pairing is completed, the paired device will be recorded in “Settings → Privacy & Security → Paired Devices”. However, after Android-to-Apple pairing is completed, the device is not saved to this list. Android device can be normally displayed on the Apple official Wi-Fi Aware Sample. However, the indicator is not green. During pairing, the Apple log shows: state: authenticated, and the Android side triggers the callback onPairingSetupSucceeded. During pairing verification, the Apple log shows: state: authenticated, and the Android side triggers the callback onPairingVerificationSucceed. My iPhone is iPhone 13， iOS 26.0 （23A5287g）

Hello, dear Apple engineers. We have recently tried to pair our Android phones and iPhones via BLE SMP, but have encountered a very high probability of pairing failures. Through PacketLogger and Android phone HCI, we have determined that the issue is caused by the iOS side sending an SMP Pairing Failed message during the SMP process. Please help us analyze the reason for this.

Please ask Apple to provide an interface for sending follow-ups like Samsung's WiFi Aware.

Environment: iOS Version: 26.0 Device Model: iPhone 12 Pro Max Peripheral: [Fill in peripheral name/model/firmware version] Steps to Reproduce: Connect to the peripheral using CoreBluetooth. Discover services via discoverServices. Discover characteristics via discoverCharacteristics. Call setNotifyValue:YES for a characteristic that supports notifications (Notify or Indicate). Capture the HCI log during the above process. Expected Result: After calling setNotifyValue:YES, CoreBluetooth should write the appropriate value to the Client Characteristic Configuration descriptor (UUID: 0xFCF8) to enable notifications, and subsequent notifications should be received from the peripheral. Actual Result: After calling setNotifyValue:YES, no subscription action is triggered. HCI logs show that the subscription write to the CCC descriptor (0xFCF8) is missing. The target service and characteristic values have already been discovered prior to calling setNotifyValue:YES. Additional Information: HCI log screenshot attached below highlights the moment after setNotifyValue:YES was invoked, showing no GATT Write Request to the CCC descriptor. Full HCI log file is also attached for reference. 11:29:38:165: Call setNotifyValue: YES