[KazuCocoa]

After an iOS app resumes, the next element tap can return successfully without reaching the app. This reproduces with both backgroundApp and standalone activateApp, on Duo / iOS 27.1 and iPhone 17e / iOS 26.5 and 27.0 simulators under Xcode 27.1.

Wait for SpringBoard to become idle, including animations, before returning from background/resume. For standalone activation, apply the wait only when the application was previously backgrounded or suspended. Use the existing animationCoolOffTimeout; zero disables the wait. The wait happens before the next command resolves element frames. The exact XCTest-internal cause and affected version range remain unknown.

The regression verifies that the first Alerts tap opens its page. Both command paths cover background intervals of 0/2 seconds and Duo hinge angles of 0/90/180 degrees. Hinge positioning and restoration use bounded angle readback, and the original display selection is restored.

Validation:

• Corrected standalone-activation regression: reuse one FBSession for the entire matrix, verify background/suspended state immediately before every activation, and kill the session in @finally. All six Duo scenarios (0/90/180 degrees × 0/2 seconds) and both iPhone 17e scenarios passed; both xcodebuild commands exited successfully.
• The earlier standalone 0/6 versus 6/6 comparison is withdrawn: per-iteration session creation could terminate the backgrounded app and accidentally test launch instead of resume.
• BackgroundApp regression passed all six Duo scenarios and both ordinary iPhone scenarios; reverting its production fix reproduced failure on both devices.
• Additional activation-state probes: stopped/foreground activation succeeded with timeouts 0 and 2. Background-resume taps failed with timeout 0 on ordinary iPhone simulators running iOS 26.5 and 27.0; timeout 2 delivered all probed taps. Duo delivered all eight diagnostic cases. Even after 15 seconds the app reported background rather than suspended, so actual suspended-state coverage remains unverified.
• Simulator build-for-testing and diff checks pass. Physical-device behavior remains untested.

The change remains iOS-only. On tvOS, Remote Home backgrounding works without this extra wait; the separate PineBoard activation failure is addressed by #83. On watchOS, app-only waiting delivered 0/3 taps and reactivation delivered 2/3. System-plus-app waiting delivered 4/4 with a zero-second background interval, but only 1/4 after two seconds. A one-second sleep helped in limited probes, but no reliable watchOS readiness condition has been established.

Refs appium/appium#22857. Independent of the Home and rotation PRs; their changes are not included here.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no new actionable issue was found.

Summary

Adds an iOS SpringBoard wait after an app resumes, using animationCoolOffTimeout.

• iOS app resumes wait for SpringBoard to settle before activation returns.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Background app command] --> B[Activate with system wait enabled]
  C[Activation callers] --> D{Previously backgrounded or suspended?}
  D -->|Yes| B
  D -->|No| E[Activate without extra wait]
  B --> F{Running on iOS?}
  F -->|Yes| G[Wait for SpringBoard using animationCoolOffTimeout]
  F -->|No| H[Return]
  G --> H
  E --> H

Loading

_{Reviews (8) · Last reviewed commit: "refactor(webdriveragent): centralize app..." · Reviewed by Greptile}

[mykola-mokhnach]

should we skip this test in CI?