iOS tests suddenly became noticeably slower

Our iOS tests have suddenly become noticeably slower. I’m not sure on the exact date it happened but I noticed during a run i did on November 5th. The last time I can confirm it working normally was from a run on September 24th.
For reference, we have a booking flow in our app which consists of (for a new user):

  1. Select who the booking is for (User/Child)
  2. Select with/without insurance
  3. Select location
  4. Select appointment
  5. Enter first/last name
  6. Enter DoB
  7. Select Gender
  8. Enter reason for visit
  9. Enter Email Address
  10. Enter Phone Number
  11. Enter Password
  12. Review Booking & Book

Between completing step 4 and arriving at step 12 we used to average around 1 to 1.5 minutes, now it’s taking up to 4 minutes to do the same steps. I haven’t been able to see any code changes in our framework that would cause this.

While trying to identify the cause of this I have tried the following:

  1. Appium server versions 1.22.0, 1.20.2 and 1.19.1
  2. appium-xcuitest-driver 3.53.1 and 3.56.3
  3. Appium-python-client 2.0.0.rc6, 2.0.0a0, 1.3.0 and 1.1.0
  4. Selenium 4.0.0.a7, 4.0.0 and 3.141.0
  5. iOS 15.1 and 14.7.1
  6. Xcode 13 and 13.1
  7. Use a version of our framework from 2 months ago
  8. Use an older version of our app from 2 months ago

So far nothing has made any difference.

From looking at the logs I can see that the slowness is occurring when appium is trying interact with an element. Here is a log from the execution of a single test case, but all tests appear to be impacted -

If you look at lines 1703 to 1737 you can see that it finds the element with accessibility id booking.last_name very quickly, but when it tries to interact with it there is a long delay.
On line 1728 you can see it send a .setValue() request for the element, but on line 1733 you see it doesn’t receive a response until ~20 seconds later.

This slowness doesn’t seem to exist throughout the entire test though, it only appears to start after a specific point.
If you look between lines 1129 and 1162 you can see that it finds and clicks the button identified by {"using":"xpath","value":"//XCUIElementTypeStaticText[@name='Me']"} in under 2 seconds.

If you then look between lines 1187 and 1223, you can see that from 1187 and 1215 it takes under 2 seconds to find and trigger the click action for the booking.continu_without_insurance_button. On line 1216 you can see a message stating that the connection has been closed, this is where the slowness begins. Between triggering the click action and trying to find the next element there is a gap of ~20 seconds.

I’m assuming it’s an apple issue but I’m hoping someone has had a similar issue or might have an idea of what’s causing this. It’s currently having a large impact on our tests and i’m not sure what to try next since i’ve been unable to do anything that makes a difference. Any help is greatly appreciated.

we do not see slowness with 15.1. we skipped 15.0 due to ‘send_key’ problem.

PS try reduce motion in Accessibility settings

Thanks for the link. I had seen this before while looking for a solution, but the issue I have is that i’m running on iOS 15.1, we even checked 14.7.1 using someone else’s setup and have the issue there too.
We’re also not just experiencing the slowness with send_keys, but also with clicking.
This started happening for us sometime in the last month, but i’ve been unable to pinpoint the cause, other than where the issue seems to begin in the logs.

Thanks for the response.
I also skipped 15.0 and went straight to 15.1.
I tried the reduce motion setting but it doesn’t seem to have made any noticeable difference unfortunately.

write your capabilities to compare…

Capabilities being used are:
“platformName”: “iOS”,
“deviceName”: “iPhone 8”,
“platformVersion”: “15.1”,
“udid”: “3ae86f47e99f50fca4f1e4b60fb154437da5f8e2”,
“automationName”: “XCUITest”,
“isHeadless”: false,
“xcodeOrgId”: “{org_id}”,
“xcodeSigningId”: “iPhone Developer”,
“bundleId”: “{bundle_id}”,
“newCommandTimeout”: 90

do not see anything strange. we have also:

waitForQuiescence = false

PS i see need move to ‘waitForIdleTimeout’ ->


Thank you Aleksei!
Adding the capability for ‘waitForIdleTimeout’ and setting to 0 has removed the delay I was seeing, and we are back to our regular speed. Will try increasing the time if I see any new issues appear, but so far so good.
Appreciate the help greatly!