[iOS] Include the springboard hierarchy even if the app is in foreground, otherwise the runner can not access push notifications delivered when the app is in foreground

[SiarheiBarysenka]

Proposed changes

Add the SpringBoard hierarchy even when the app is running in the foreground.

Explanation

After bumping Maestro from 1.39.12 to 2.5.1, we noticed that one of our tests, which validates interaction with a push notification while the app is running in the foreground, started failing because it could no longer assert that the push notification body was visible.

We pinpointed the regression to this PR: #2402 . In that PR, the SpringBoard hierarchy was no longer included when the app was running in the foreground, causing the issue described above.

Testing

Validated that our test now passes again after rebuilding Maestro with the proposed change included.

Issues fixed

• iOS push notifications are not accessible to the Maestro driver when the app is running in the foreground.

[SiarheiBarysenka]

Hello @amanjeetsingh150 – I'd appreciate if you can take a look at this PR. Thanks!

[SiarheiBarysenka]

Will rebuild the drivers with Xcode 26.2 and update the PR...

[SiarheiBarysenka]

My macOS version is different to the one used by the runner at "Check Drivers Up-to-Date" step (https://github.com/actions/runner-images/blob/macos-26-arm64/20260427.0026/images/macos/macos-26-arm64-Readme.md), so I assume this is why this step still fails even after rebuilding with Xcode 26.2.

[Fishbowler]

Don't worry about the drivers, we need to fix our CI around that.

Things to consider:

• there were reasons for the original PR. Does this reintroduce the problem?
• Is there an e2e test that can be written for this?

[SiarheiBarysenka]

Hi @Fishbowler , thanks!

The original PR doesn't clearly list the issues it aimed to address, besides perhaps "slower viewHierarchy operations due to querying an extra process" – but I guess the correctness of the hierarchy is more important than the speed?

As of E2E test, I'm happy to write it to replicate the case we have in our tests, namely, emulating the push notification when the app is in the foreground and tapping on it. However, I don't think Maestro supports emulating push notifications out of the box to write such test in your repo? We have an infra built around Maestro to support such use cases, which allows the access to the command line to send the xcrun simctl push when the test is running to emulate the push. Might be a bit of an overkill to replicate this infra in Maestro repo only to write such test? Although, it would be a nice capability to add the command line access as a first-citizen API in Maestro, separately from this.

[Fishbowler]

How about a button in demo_app that raises its own PN?

[SiarheiBarysenka]

@Fishbowler Perhaps that would work, I can try scheduling a local notification (https://developer.apple.com/documentation/usernotifications/scheduling-a-notification-locally-from-your-app). Will look into adding such test.

[SiarheiBarysenka]

@Fishbowler Added the test. Verified that the test fails on the current main, and passes on the revision with proposed changes.

[SiarheiBarysenka]

@Fishbowler Ready for review. iOS and Android tests pass.

[SiarheiBarysenka]

@Fishbowler Btw, the tests for the demo_app are not running at all for iOS: https://github.com/mobile-dev-inc/Maestro/blob/main/e2e/run_tests#L154

I wonder how do you folks validate those flows still work on iOS on PRs?

EDIT: OK, I see there's a draft PR to enable these tests #3253

[SiarheiBarysenka]

Without changes in this file, the Android build fails with

Execution failed for task ':app:checkReleaseAarMetadata'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckAarMetadataWorkAction
   > An issue was found when checking AAR metadata:

       1.  Dependency ':flutter_local_notifications' requires core library desugaring to be enabled
           for :app.

[SiarheiBarysenka]

Hello @Fishbowler could you please let me know if there’s anything else we'll wait for before merging this fix, besides the review? For example, a CI fix for "Check Drivers" step and/or the merge of #3253 to enable the tests? Just trying to understand the timeline of getting this change in. Thanks!

[SiarheiBarysenka]

Hello @Fishbowler may I ask when are you planning to merge #3294 to unblock the CI?

Also, are there any particular comments on the current PR, or anything else that would prevent merging it after rebasing once #3294 is merged? It's been open for quite long.

Thanks!

[Fishbowler]

Argh. That e2e test failure is coming from the homescreen of the demo_app getting too busy. Will look at that.

[Fishbowler]

I've done a quick comparison locally on maestro hierarchy with the demo_app in the foreground.
What's in main gives 1673 lines of output, whilst this branch expands that to 3915 lines of output.
I'm concerned that this branch could introduce a performance regression if enabled all the time. WDYT?

[SiarheiBarysenka]

@Fishbowler Is there any way you'd recommend to introduce a flag whether to include the full hierarchy when evaluating a particular assertion?

I.e. something like

- assertVisible:
    id: some-id
    includeFullHierarchy: true

With the default is false, to make this change non-breaking.

Would that be good API you think?

[amanjeetsingh150]

Hey @SiarheiBarysenka, I think the flag is not needed from what I got from your description this looks like a regression and maestro should be able to surface hierarchy of such notifications by default.

With E2E you added if it fails on main and passes on your branch that should be good.

[Fishbowler]

What about running some tests first to see if my concern is warranted?
You could benchmark the iOS Wikipedia tests before and after?

[SiarheiBarysenka]

@Fishbowler Do we currently store any view hierarchy artefacts on CI for the passed tests? I don't seem to be seeing them, but maybe I don't have enough permissions.

Indirectly, I'm comparing the run-time of wikipedia tests on this PR and another recent PR #3373 , and there doesn't seem to be any noticeable difference in run time (assuming that inclusion of the springboard hierarchy in this PR would increase view hierarchy traversal time in a test). This PR even runs faster (green box for this PR vs. red box for the reference PR):

This might not be the precise measurement though. Let me know if there are artefacts on CI we can download and check, otherwise will do the local tests.

[Fishbowler]

@SiarheiBarysenka I see artifacts on the Summary page

I think a few benchmarks on your local machine would be a better measure. No GitHub free infra variability.

With an iOS Simulator running, I think. it should be as simple as:

cd e2e
./download_apps ios
./install_apps ios
./run_tests ios

[SiarheiBarysenka]

Thx @Fishbowler ! Will post the results of the measurements once I have them.

[SiarheiBarysenka]

@Fishbowler

There's no difference in performance before vs. after the fix on ./run_tests ios suite:

Before Fix	After Fix
2/2 Flows Passed in 1m	2/2 Flows Passed in 59s

I run it multiple times and it's +/- 1s to the numbers reported above for both Before / After.
The measurements are from the MacBook Pro (16-inch, 2021), M1 Pro, 32 GB, macOS Tahoe 26.5.1, iPhone 16e Simulator, iOS 26.3.

Full logs of one of the run:

log-with-fix.log
log-without-fix.log