I recently came across a Youtube video (not linking it because I didn’t think it was particularly good) where a key point the presenter was trying to make was that using .firstMatch was far more efficient than using .element when attempting to locate an element because it stops at the first element found as opposed to continuing to check for others (.element will fail if there is more than one). I, however,  prefer the .element approach because it implicitly ensures there aren’t more elements on the screen than I expect. Not to say .firstMatch doesn’t have its uses, but when I’m expecting to find a single element I also don’t mind ensuring it’s the only one.

Anyway, I fired up Xcode, repeated  (24 times – removing two outliers on each end) a basic test on a basic calculator app that asserted .exists on a particular piece of text, and found there to be no appreciable difference. On average, .firstMatch took 5.82 seconds, and .element 5.86. I’m assuming this to be well within the margin of error for a computer doing countless other things in the background, and therefore unless you’re sending your automation into deep space (efficiency really matters) you may want to go with the property that does some extra checking.

Interestingly, even Apple in their documentation supports this person’s claim. I’d love to see their data.

It is worth noting my test application was small and fairly simple. It’s possible this difference may be more noticeable with a more complex app? I likely won’t bother to test because we’re talking at most a couple of seconds over your typical full suite of tests and I’d argue that kind of gain isn’t worth a pull request.