Hello Apple Developer Technical Support, We are investigating an intermittent CoreBluetooth issue in our iOS app. In some low-frequency cases, service discovery succeeds, but characteristic discovery returns an empty characteristic list. Once this happens, the issue does not recover until the iPhone is rebooted. The observed behavior is as follows: The app connects to the BLE peripheral successfully. The app calls discoverServices. peripheral(:didDiscoverServices:) is called with no error, and the expected CBService is present. The app then calls discoverCharacteristics for the target service. peripheral(:didDiscoverCharacteristicsFor:error:) is called with no error, but service.characteristics is empty. After this happens, reconnecting to the same peripheral still returns an empty characteristic list. The issue recovers after rebooting the iPhone. The issue is not consistently reproducible and occurs at a relatively low rate. We would also like to clarify that we cannot currently reproduce this issue reliably in our local environment. In most cases, the issue is reported by users, and we identify the behavior later by reviewing app-side logs. Therefore, when the issue occurs, we are usually unable to collect sysdiagnose, Bluetooth profile logs, PacketLogger traces, or other CoreBluetooth-specific diagnostic information. The information we can currently provide mainly includes app-side CoreBluetooth callback logs, connection and disconnection timestamps, the target service UUID, target characteristic UUIDs, iOS version, iPhone model, peripheral firmware version, and the user-reported occurrence time. We would like to ask: Under what conditions could CoreBluetooth return an empty service.characteristics array after the expected service has already been discovered? Is it possible that iOS/CoreBluetooth caches an abnormal GATT database or peripheral state that persists across reconnects? If this happens, is there any recommended recovery method other than rebooting the iPhone? Are there known cases where a peripheral exposes the service, but iOS fails to discover its characteristics until Bluetooth or the device is restarted? If we cannot reproduce the issue locally and cannot collect sysdiagnose, Bluetooth profile logs, or PacketLogger traces when it occurs, can Apple still help infer possible causes based only on app-side CoreBluetooth logs? If not, is there any lightweight diagnostic method Apple recommends for collecting more useful information from users in the field? From the app side, the service UUID and characteristic UUIDs are fixed, and the issue occurs before notification subscription or application-level authentication. Therefore, we would like to understand whether this behavior could be related to CoreBluetooth state, BLE stack state, GATT cache behavior, or peripheral-side GATT exposure timing. Please let us know what additional information would be useful for further analysis.