Implement hybrid Safari UI deep link dispatch with in-app eDO fallback in EarlGrey.

EarlGrey's openDeepLinkURL:withApplication:error: previously relied on sequential blocking timeouts across hardcoded Safari UI element matchers. This caused cumulative stalls on modern iOS versions where the address bar renders as a tab bar item, as well as unhandled event synthesis crashes when typing before keyboard focus completed. Furthermore, on iOS 17+, certain registered URL schemes (such as otpauth-migration) are natively intercepted by system sheets (e.g. Apple Passwords) when opened via Safari or SpringBoard, preventing the target application from handling the deep link.

Modernize Safari UI automation with adaptive address bar element polling, explicit hasKeyboardFocus validation, and robust in-app fallback dispatch:
- Check hasKeyboardFocus on the Safari address bar input field before typing to avoid event synthesis failures, resetting element references per loop iteration to avoid stale query lookups.
- Dismiss any continuous path tutorial popup dynamically within the focus loop without adding static blocking delays.
- After tapping Safari's Open dialog, verify the target application enters the foreground before returning; fall back to in-app dispatch if another system sheet intercepted the scheme.
- If MobileSafari fails to launch, the address bar is missing, keyboard focus cannot engage, the system Open dialog is delayed, or the target app fails to foreground, terminate Safari and fall back to in-app eDO dispatch.
- In fallback dispatch, check active connected scenes and route via UISceneDelegate (scene:openURLContexts: / scene:continueUserActivity:) when present, falling back to UIApplicationDelegate (application:openURL:options: / continueUserActivity:restorationHandler:) before falling back to system openURL, preventing OS-level scheme interception.
- Implement safe GREYOpenURLContext encapsulating .URL while overriding .options to return nil, and supplying -isEqual: and -hash implementations.
- In fallback dispatch, execute via GREYExecuteSyncBlockInBackgroundQueue and synchronize via GREYCondition on the caller thread to prevent eDO deadlocks on appProxyQueue.
- Use the configured EarlGrey interaction timeout consistently for foreground transitions, UI polling deadlines, and condition synchronization.
- Eliminate unused kWaitForExistenceTimeout constant.

PiperOrigin-RevId: 981970995
1 file changed
tree: 653a5bc349e04332bcbc23e818ef3aa82d8b8344
  1. AppFramework/
  2. CommonLib/
  3. Demo/
  4. docs/
  5. EarlGrey.xcodeproj/
  6. Scripts/
  7. TestLib/
  8. Tests/
  9. third_party/
  10. UILib/
  11. .gitignore
  12. CHANGELOG.md
  13. CONTRIBUTING.md
  14. EarlGreyApp.podspec
  15. EarlGreyTest.podspec
  16. LICENSE
  17. README.md
README.md

Apache License Build Status

Note: EarlGrey 2.0 currently supports Xcode Projects and building from source for both white and black box testing. CocoaPods support is present for black-box testing. Contributions are welcome for CocoaPods white-box testing and other package managers.

To use, please clone the earlgrey2 branch with its submodules:

// Clone EarlGrey 2.0
git clone -b earlgrey2 https://github.com/google/EarlGrey.git

// Download any dependencies
sh Scripts/download_deps.sh

EarlGrey 2.0

EarlGrey 2.0 is a native iOS UI automation test framework that combines EarlGrey with XCUITest, Apple's official UI Testing Framework.

EarlGrey 2.0 allows you to write clear, concise tests in Objective-C / Swift and enables out of process interactions with XCUITest. It has the following chief advantages:

  • Synchronization: From run to run, EarlGrey 2.0 ensures that you will get the same result in your tests, by making sure that the application is idle. It does so by automatically tracking UI changes, network requests and various queues. EarlGrey 2.0 also allows you to manually implement custom timings.
  • White-box: EarlGrey 2.0 allows you to query the application under test from your tests.
  • Native Development: As with EarlGrey 1.0, you can use EarlGrey 2.0 natively with Xcode. You can run tests directly from Xcode or xcodebuild. Please note that EarlGrey 2.0 uses a UI Testing Target and not a Unit Testing Target like EarlGrey 1.0.

EarlGrey 1.0 is a white-box testing tool that allows you to interact with the application under test. Since XCUITest is a black-box testing framework, this is not directly possible with EarlGrey 2.0. To fix this, we use eDistantObject (eDO) to allow these white-box interactions.

Using EarlGrey 2.0

To integrate with EarlGrey 2.0 using Xcode Projects, please take a look at our Setup Guide. For CocoaPods, please look at the CocoaPods Setup Guide.

For a quick sample project, take a look at our FunctionalTests project.

Getting Help

You can use the same channels as with EarlGrey 1.0 for communicating with us. Please use the earlgrey-2 tag to differentiate the projects.

Apple Privacy Description Labels & Analytics

EarlGrey is not intended to be shipped in user facing products so we are not supplying formal Apple Privacy Description Label guidelines. That being said, this product does not collect or transmit any analytics or personal data.

Licensing

All project source code is licensed under the Apache 2.0 license. All image resources are licensed under the Creative Commons Attribution 4.0 International (CC BY 4.0) license. The texts of both licenses are included in the LICENSE file.

EarlGrey 2.0 advantages over XCUITest

  • Automatic synchronization with Animations, Dispatch Queues, and Network Requests as enumerated here.
  • In-built White-Box Testing Support with RMI.
  • Better Support for Flakiness Issues.
  • Better Control of tests. EarlGrey has a much larger set of matchers.
  • EarlGrey performs a pixel-by-pixel check for the visibility of an element.

EarlGrey 2.0 advantages over EarlGrey 1.0

  • Out of Process Testing using XCUITest. So System Alerts, Inter-app interactions etc. are supported
  • Lesser throttling of the application under test's main thread.
  • Better support since accessibility is provided out of the box with XCUITest.

Caveats

  • You cannot directly access the application under test as with EarlGrey 1.0. You need to use eDistantObject (eDO) to do so.
  • XCUITest application launches can add a 6+ second delay. Please use XCUIApplication launch judiciously.