Run iOS app automation is very slow

I want to click on this element, but the delay time is as high as 57 seconds. I would like to know the reason and what is the solution?

Info

  • python: 3.10
  • appium: 2.10.3
  • xcuitest: 7.17.6
  • webdriveragent: 8.7/9
  • device: iPhone 14 ProMax 17.5.1

[debedf76][HTTP] ← POST /wd/hub/session/debedf76-39c6-4317-9d98-59d98ff2f1f7/element/DF880000-0000-0000-8B02-000000000000/click 200 29643 ms - 65
[debedf76][HTTP] → POST /wd/hub/session/debedf76-39c6-4317-9d98-59d98ff2f1f7/element {“using”:“accessibility id”,“value”:“已收藏!試試將文章加入收藏分類吧!”}
[debedf76][HTTP] ← POST /wd/hub/session/debedf76-39c6-4317-9d98-59d98ff2f1f7/element 200 52271 ms - 137
[debedf76][HTTP] → POST /wd/hub/session/debedf76-39c6-4317-9d98-59d98ff2f1f7/element {“using”:“accessibility id”,“value”:“測試分類”}
[debedf76][HTTP] ← POST /wd/hub/session/debedf76-39c6-4317-9d98-59d98ff2f1f7/element 200 56882 ms - 137

1 Like

What is on screen? If we have many items (e.g. some shopping or country list) this is expected.

Thanks for you provide me with documents.
The following is my environment:

  • appium Client Lib: local
  • appium server: local
  • device: physical mobile phone (connect via USB)
  • snapshotMaxDepth: 24
  • excludedAttributes: [‘visible’, ‘accessible’, ‘type’, ‘enabled’, ‘label’]

Do we have a better way?

There are many items(article、image) in my screen, and they all have depth.
My snapshotMaxDepth setting:24

Do we have a better way?

Unfortunately I don’t know anything more except of what is already described in the above troubleshooting guide,

1 Like

Problem not in depth but number of elements on screen and outside screen that is available in page source. With large items XCUITest becoming slow and nothing we can do. The only tweaks to reduce search time:

  • search always only element NOT element list
  • use id or predicate locators
1 Like

@Lu_Lewis, I encountered the same issue when setting up automation for the iOS platform, interactions with elements were significantly slower compared to those on the Android platform.

I addressed this in two key ways. First, I optimized the Appium capabilities for maximum speed. Second, I reduced the size of the iOS page source.

1. Optimizing Appium Capabilities

I discovered several capabilities in the Appium documentation that helped improve performance. Here’s what I added:

"appium:settings[waitForQuiescence]", false
"appium:isHeadless", true
"appium:settings[reduceMotion]", true
"appium:settings[animationCoolOffTimeout]", 0
"appium:settings[customSnapshotTimeout]", 2
"appium:settings[pageSourceExcludedAttributes]", "visible,enabled,accessible,x,y,width,height,index"

2. Reducing the iOS Page Source Size

This step involves adjustments in the app code. Since my project uses React Native, I divided this part into two sub-parts:

  • First Sub-Part: Minimizing the @name Attribute
    By default, the XCUIElementTypeOther element in the source tree has its @name attribute set to include text from all its children recursively. This means the @name attribute of the first child contains all the text from its child elements, and so on.I realized that I didn’t need this much unnecessary text in the @name attribute, so I modified it. Here’s how you can do it in your index.js.
    P.S In this code, TEST_IDS.GENERAL_COMPONENTS.VIEW_ID is set to '_viewId'.After making this change, your source tree will become much lighter, leading to faster element searches.
View.defaultProps = View.defaultProps || {};
View.defaultProps.testID = TEST_IDS.GENERAL_COMPONENTS.VIEW_ID;
View.defaultProps.accessibilityLabel = TEST_IDS.GENERAL_COMPONENTS.VIEW_ID;
  • Second Sub-Part: Checking for Extraneous Elements
    Use the Xcode debugger to ensure that only the elements belonging to the current screen are present in the source. For example, if you are on Screen1 and see that elements from Screen2 are also rendered in the source (even though they aren’t visible), it indicates that these elements from Screen2 are being rendered unnecessarily. If you find this issue, you should either adjust the rendering logic yourself or, if you don’t have access to the code, create a ticket for your developers. You might be surprised at how many incorrect renderings you can find in your app, all of which unnecessarily inflate the source tree.

As a result of those manipulations I was able to achieve almost the same test on IOS and Android platforms, Android still is a little faster but not significantly. Hope this will help you.

cc @mykola-mokhnach @Aleksei

1 Like

use same except pageSourceExcludedAttributes - will try it …

waitForQuiescence, reduceMotion , animationCoolOffTimeout are mostly stability improvement parameters.

pageSourceExcludedAttributes gave me zero speedup :frowning:

While if I need iterate items helps @CacheLookup pageObject attribute to avoid unnecessary searches.