My company manufactures an Accessory which has been a certified product for a number of years. We are switching manufacturers, and thereby need to re-certify under a new product plan with the new manufacturer. We release over the air updates to our accessory. The question is what do we do about the device's iAP2 IdentificationInformation Message, specifically the ProductPlanUID parameter. Should devices manufactured at our old manufacturer continue to declare our original Product Plan's UID in their identification information, or should they declare the new one?

My company builds an application using the External Accessory framework to communicate with our hardware. We have followed the documentation and example here and use the stream delegate pattern for scheduling the handling of the EASession's InputStream and OutputStream: https://developer.apple.com/library/archive/featuredarticles/ExternalAccessoryPT/Articles/Connecting.html Our application works, however we have had some issues that cause us to doubt our implementation of the Stream handling for our EASession. All the examples I can find for how to set up this RunLoop based implementation for managing and using the streams associated with the EASession seem to use RunLoop.current to schedule the InputStream and OutputStream. What is not clear to me is what thread the processing of these streams is actually getting scheduled upon. We have occasionally observed our app "freezing" when our connected accessory disconnects, which makes me worry that we have our Stream processing on the main thread of the application. We want these streams to be processed on a background thread and never cause problems locking up our main thread or UI. How exactly do we achieve this? If we are indeed supposed to only use RunLoop.current, how can we make sure we're opening the EASession and scheduling its streams on a non-main thread? On what thread will we receive EAAccessoryDidConnect and EAAccessoryDidDisconnect notifications? Is it safe to schedule streams using RunLoop.current from that thread? What about when the app returns from the background, how are we meant to reconnect to an accessory that the iOS device is already connected to? Hopefully someone here can help guide us and shed some light on how to achieve our desired behavior here.