I'm experiencing intermittent failures when executing APDU (Application Protocol Data Unit) commands through Core Bluetooth to communicate with external secure elements. The communication flow involves establishing a BLE connection, discovering services and characteristics, and then sending structured APDU commands for card management operations. While the initial connection and characteristic discovery work reliably, I'm encountering inconsistent behavior during APDU command execution where commands either timeout, return unexpected response codes, or fail to complete the expected transaction sequences. The issue appears to be more prevalent when sending multiple APDU commands in rapid succession or when the commands involve cryptographic operations. I've implemented proper error handling and retry mechanisms, but the failures seem to occur at the Core Bluetooth level rather than in my application logic. The peripheral device responds correctly to the same commands when tested with other platforms, suggesting the issue might be related to iOS-specific BLE behavior or timing constraints. I'm using standard Core Bluetooth APIs (CBPeripheral, CBCharacteristic) with proper delegate implementations and have verified that the peripheral remains connected throughout the operation. Has anyone encountered similar issues with APDU command execution over BLE on iOS, and are there any known workarounds or best practices for ensuring reliable command delivery and response handling?

We are developing an iOS application that requires NFC-based communication using ISO 7816 / ISO 14443 standards for secure element interaction as part of a card provisioning workflow. We would like clarification on the following points: Is it possible to provision a payment card or securely add a card to an NFC-enabled device using direct ISO 7816 APDU communication via NFCTagReaderSession? If not, is Apple Pay In-App Provisioning (PassKit framework) the only supported approach for enabling contactless payment functionality on iPhone? What specific entitlements are required if the use case involves secure element communication for token provisioning (not bypassing Apple Pay)? We have already requested the relevant NFC entitlements through our Apple Developer account and are awaiting a response. Any guidance on the correct architecture and approval requirements would be greatly appreciated. Thank you in advance for your support.