Update It got FIXED!!! There was a mistake on the firmware side. SYN Type: Must be 2 to align with the session's purpose. Earlier, it was going with the buffer instead of EA. Native Transport instead of EA Session.

Hi, Thank you for the suggestions. I have tested the communication using the EADemo sample app as suggested, but unfortunately, I had no luck. The app is unable to establish a stable session with the accessory, which mirrors the issues we are seeing with our own application. To move this forward, I have filed an official bug report via Feedback Assistant and attached a full sysdiagnose captured during a failed communication attempt: Feedback ID: FB22116486 Current Project Status: Certification: The accessory is currently in an early development state, so we have not opted for MFi certification yet. We are using development identifiers/chips for testing the iAP2 protocol. Prior Success: We have not yet been able to successfully maintain a functional data session between the ExternalAccessory framework and this specific hardware revision. Technical Observations from Firmware Logs: Based on our local logs, the hardware side appears to be performing correctly: Link Synchronization: The iAP2 link completes the handshake successfully (Link params: 4096 65535) and reaches the iAP2LinkConnectedCB state. Authentication: The MFi authentication challenge/response is successful (Auth passed). Identification: The device identifies correctly as "ECG One" (Tricog Health India Private Limited), and the identification request is accepted by iOS. Data Session: We see the start of an EA session (ID 30) and the firmware begins transmitting data (ASCII "hello\n"). While the iAP2 link layer is receiving ACKs from iOS at the transport level, the data never surfaces in the app layer (either in EADemo or our custom app). Since a functional, authenticated link is failing to communicate even with the standard EADemo app, I am hoping the logs in FB22116486 will help identify if there is a protocol violation in our identification sequence or a configuration issue in our project's UISupportedExternalAccessoryProtocols. Any further insights into why the session would "black-hole" data despite a successful handshake would be greatly appreciated. FB22116486

Hi Kevin, Thank you for the troubleshooting steps. To clarify the current state of the environment: Testing Environment: I am testing exclusively on a physical iOS device (iPhone [Model] running iOS [Version]); I am not using the simulator for these tests. Framework: The implementation is already built using UIKit. I am managing the accessory lifecycle within a standard UIViewController and AppDelegate structure. Integration Status: Despite being in a pure UIKit environment, I am still facing the issue where [mention the specific symptom, e.g., the accessory is not appearing in the picker / the session fails to open]. Since I have already ruled out SwiftUI lifecycle interference and simulator limitations, are there specific logging categories in Console.app or internal ExternalAccessory states you recommend I monitor to diagnose why the connection is failing?