I'd really rather just remove the timeout altogether.

This should never take more than 60s, but really we should just use the whole test timeout to find out exactly what's wrong. I just don't want to keep incremently moving this up all week as it continues to flake :)

I'd really rather just remove the timeout altogether.

You mean make make the wait [NSDate distantFuture].timeIntervalSinceNow? That could hit a different timeout and cause flakes.

The latter wouldn't be hard to implement, just pop an event on the main queue. Run the main event queue for a couple of milliseconds then check if your event has been executed yet.

I think that's essentially what -waitForExistenceWithTimeout is doing--it's spinning the runloop until the element is rendered, and it stops spinning as soon as it does.

The bots are slow - sometimes.

The bot that failed this actually passed it again on a retry with the 1s timeout. I'm just going with a generous value that should avoid the need to revisit this - really we try to avoid timeouts in general except for the main test/bot timeout.

It's not a huge deal but I don't think my point was conveyed. Let me try saying it another way. When making a game you have 2 different ways to progress time for an event. You can base it off of the clock or you can base it off the update rate.

void Update() {
  _progress += 1;
}

void Update() {
  _progress += _rate * (Time.current - Time.lastFrameTime);
}

Tying your event to the real clock means that a drop in framerate will make sure your event still lasts the same amount of real time. Tying your event to the update event means that even when the framerate drops your event will progress with the same steps with time dilation.

We are effectively performing our wait like an event based on real time, that's how Apple has implemented it. In our case, with bots that are sometimes slow, time dilation is a good thing. The proposed wait mechanism would be more like basing our wait on the update calls and would experience time dilation with a slow execution.

Not a huge deal, I just want to make sure my point was communicated and understood.

How would we achieve what you're suggesting with an XCUITest?

My first 2 thoughts were tying the duration of the waiting to the framerate of the device (which should slow down on slow devices) or basing the waiting on flushing the whole event loop, which would also slow down on slow devices.