iOS Test execution time skyrocketed

[Markaleth]

Hello,

Recently switched to Appium 1.8.0 from 1.7.2 and i’m seeing a 6x increase in test time on real iOS devices (haven’t checked on sims).

Test code has remained constant throughout the switch with absolutely no changes to code, identifiers, validators or anything else in the test suites or page objects.

Has anyone else been experiencing any significant increase in test times with Appium 1.8.0?

I’m sorry if this is a repost, I haven’t been able to find any other topics pointing to this particular scenario.

Cheers!

[MrZigaS]

I did have the same problem with Appium 1.8.0 when I updated from Java client 4.1.2 to 5.0.4.
I fixed the slowness by updating Java client to 6.0.0-BETA.

[alangithubtrader]

In my general experience, iOS test execution time has been much (3x) slower compared to Android. When will Appium be able to address this? I remember back in the days when Apple still used UIAutomator we could hack the plist file to by pass the 1 second delay and test ran super quick. I wonder if there’s such work around for XCUITest?

[Smitty]

@MrZigaS
You just saved my life over here. We had to move to Appium 1.8.0 after the XCode 9.3 update and my scripts on iOS became glacier-like in speed. I was also running Java Client 5.0.4 but have now updated to 6.0.0-BETA5 (which required an update to selenium-java: 3.9.1). Before this update, one of my scripts running against an iPad Air took 66 minutes to complete. The same script after the update just took 5.5 minutes to run. It is still true that the Androids run faster in all cases but I am super happy that iOS devices take twice as long to complete instead of 20 times as long.

Thanks!

[MrZigaS]

I’m glad I could help and also happy with the speed, but still waiting for official release of the client.

[bennid]

Unsure of the use / need of it, but I saved a bunch of time using the older Java Client (Unsure if 6.0.0-BETA does it) by extending IOSDriver and caching getSession() calls. Looking at the code, the Java Client was putting session details into EVERY Element returned in findElements() (and making a getSession call to the appium server for each), making upwards of 10s of calls for some views. While each call was only 100ms or so, it still grew out of control. Caching the session details (for right or wrong) saved a LOT of these calls.

In your extended driver just put:

@Override
public Response execute(String driverCommand) {
    if (driverCommand.equals(MobileCommand.GET_SESSION)) {
        if (getSessionResponse != null) {
            return getSessionResponse;
        }
        getSessionResponse = super.execute(driverCommand);
        return getSessionResponse;
    }
    return super.execute(driverCommand);
}

[alangithubtrader]

@bennid i never knew you could cache the session details, very interseting. Do you know if there is such caching capability for C# client as well?

[MrZigaS]

Are you using java_client 5.0.4 in this case?
How can you access to GET_SESSION while it’s protected? And what exactly is ‘getSessionResponse’?

[Markaleth]

I’m delighted this post generated such insightful discussions and i appreciate all the input so far.

I’ve tried a Java client update but, as i’m sure you’re all familiar, that comes with it’s own challenges ([cough] yeah Touch actions, i’m looking at you!), especially since version 6.0 seems to bring very significant changes to the library.

I’d be very curious to hear more on “session response” topic @bennid. While Appium 1.8 certainly accentuated the problem, i feel iOS Driver to Appium Server communications has always been (at least as far as i’m concerned) sub-par in terms of session management.

Looking forward to reading more of your experiences and resolutions for this little bump in automation.

Thank you kindly once again for all your replies!

[bennid]

Ah HA! I put the new CacheIOSDriver in the package io.appium.java_client in order to get to GET_SESSION. getSessionResponse is just a private class level variable I’m using for the “caching” (though it never times out… so I use “caching” loosely.

This was with JavaClient 6.0.0-BETA5, but it would surprise me if it changed between 5.0.4 and 6.0.0.

[bennid]

I’ve found it’s more Appium 1.8 that have affected TouchActions than the 6.0.0 client (I do like the Options / builders better than just passing in things… but yes, it was a bit of a change) – though to be fair, having absolute coordinates for both IOS and Android is nice. I also found that creating something of an AppiumHelper as a shim to everything made moving to the newer client easier (so only really changing in one class). I’d love to know from Appium devs if the session details could skew at all, and am I introducing a potential issue by saving it off and re-using it. At the very least it’s speeding up my suite by a few minutes.

Unfortunately I’ve had to back down to appium 1.7.2 due to https://github.com/appium/appium/issues/10703.