@DTS Engineer Hi Kevin, Were there any updates from your side from our updated information shared last week or the bug in general? We are extremely concerned because over half a million of our products have been sold to 100,000s customers (all schools and universities), and this issue has now affected thousands of our customers. We always recommend the use of our product with an iOS device, so this issue now reflects extremely negatively on both of our companies. Given that all of them are in an educational environment, they all depend on our tools daily. Here is just a sliver of feedback we get daily from our extremely disappointed customers, copy and pasted and attached for your reference: Customer Feedback: “Our Apple IPADS have updated to IOS 18 and we are currently unable to use the (your) device. Will there be an update to the Swivl app to connect? Do I need to purchase a new device, if so, how long will this be supported for? “We have recently purchased a Swivl CX-3 and wanted to use it with our iPad mini 2 (6th gen) running iOS 18.1. Unfortunately, the Swivl Capture App running version 10.5.2 does not always want to connect to the Swivl Robot. It is impossible for us to use the robot reliably in a school setting because of this issue. I hope to hear from you soon about this issue.” Please let us know what we can do to help Apple debug this issue!

@DTS Engineer Hi Kevin, We found some new information that may be helpful for you to diagnose the problem. We bought a different MFi accessory from another company (Lets call it Accessory B for reference) that we thought could potentially use iAP. This was proved correct after using ATS to analyze the traffic. Here are the findings Accessory B uses "iAP2 EA Session" where as our accessory uses "EA Native Transport" We cannot reproduce the connection issue with Accessory B on iOS18. i.e. even after multiple disconnects/reconnects it is able to open the session. So it looks like this issue only affects the "EA Native Transport" option but not the "iAP2 EA Session". I am not sure if this helpful but we thought it was worth sharing. Again please let us know if you need additional information to debug the issue. Thanks, Amith

@DTS Engineer Hi Kevin, Thank you for the response, I understand what you meant by testing with different accessories now. Please find the results below. Reproduce the issue with Accessory 1 Test with accessory 2. Does Accessory 2 immediately fail or does it work once and THEN fail (just like Accessory 1)? Accessory 2 fails immediately. Does not work even once. Perform stage 1 with Accessory 1 (do the "working" test, but to NOT generate the actual failure). Test with Accessory 2. Does Accessory 2 work once then fail, or does it fail immediately? Accessory 2 fails immediately. Does not work even once. Let me know if you need additional information! Thanks, Amith

Hi Kevin, Thank you for the response. I am not the original post creator but as I mentioned our accessory also has the same exact problem. We actually submitted a bug via Feedback Assistant on Oct 11 (FB15464483 (EASession fails intermittently with no error)). We have also filed for a code level support for the same issue (Case-ID: 9616754) but so far we have not received any response in either of these places. I have updated the bug on Feedback Assistant with the logs you requested along with the timestamps. I am attaching the timestamps below for reference as well Apple device booted to homescreen - 8:48:30 Accessory plugged in for the first time - 8:51:00 Click "Allow" on App launch dialog - 8:52:00 Verified accessory is connected via the app - 8:52:08 Disconnect accessory by unplugging the lightning connector from iOS device - 8:55:02 Reconnect accessory with app still open - 8:56:00 Issue reproduced - 8:56:08 Sysdiagnose triggered - 8:59:00 It's not clear from your description which of these (or both) are failing, so please do the same test cycle and test both: Opening your app again and trying to reconnect. Force quitting your app and relaunching it. Actually neither of these actions trigger the bug in question. It is only when you reconnect the accessory physically by disconnecting and reconnecting the lightning (or USB-C) connector from the iOS device that it fails to establish connection. The bug is also reproduced if we just turn off the accessory and turn it back on but the mechanism is probably the same in both cases. Assuming you have access to multiple examples (copies? instances?) of the same accessory, see if using on of the other accessories work. This can help differentiate between a failure that's tied to the system tracking an individual device and a broader failure. Yes we have tested this on multiple units (>10) and the bug is reproduced on all of them. So it is not a failure that is tied to a particular unit. Try connecting to the same accessory with a different app. You can either use a simple test project, or change the bundle ID of your actually application. As part of the code level support we created a completely new test project that does just basic connection and communication with the accessory and the issue was reproduced there as well. Test with other unrelated accessories and apps to see if the issue is effecting the entire "stack" or just your app. Putting that test another way, does the succes of your accessory/app break create an immediate failure in the other accessory/app. We will check if we have any other accessories that connect via Lightning/USB-C but this may take some time. However the fact that this happens only on iOS18 and not on any lower version (iOS17 and below) is a strong indication that it is related to our accessory itself. Please let me know if you need more information to debug the issue. This is affecting all our customers who are running iOS18 and it would be great to find a solution soon! Thanks, Amith

We have the exact same issue with our accessory. This only happens on devices running iOS18 and rebooting the iOS device allows the accessory to connect. We have also filed a bug on feedback assistant for this issue but so far there has been no response.