Janic Duplessis
@janicd.bsky.social
Software and coffee @th3rdwave.coffee
Try it out if you’re using Maestro with a large RN app on iOS. Curious to hear if it speeds things up for you too.
June 13, 2025 at 6:55 PM
Try it out if you’re using Maestro with a large RN app on iOS. Curious to hear if it speeds things up for you too.
The fix? Only generate recursive accessibility labels for views with accessible={true}, the ones that are used for accessibility features like VoiceOver.
Here’s the PR: github.com/facebook/rea...
Here’s the PR: github.com/facebook/rea...
Only generate recursive accessibility label for accessible elements by janicduplessis · Pull Request #51988 · facebook/react-native
Summary:
When trying to implement e2e tests using maestro in a large app I ran into major performance issues. I tracked it down to the generation of recursive accessibility labels.
The maestro iOS ...
github.com
June 13, 2025 at 6:55 PM
The fix? Only generate recursive accessibility labels for views with accessible={true}, the ones that are used for accessibility features like VoiceOver.
Here’s the PR: github.com/facebook/rea...
Here’s the PR: github.com/facebook/rea...
RN apps often have deep, complex hierarchies, which makes this way worse. The new architecture helps (thanks to view flattening), but the root issue is still there.
Maestro suggests migrating to the new arch, but the real bottleneck is this accessibility label generation logic.
Maestro suggests migrating to the new arch, but the real bottleneck is this accessibility label generation logic.
June 13, 2025 at 6:55 PM
RN apps often have deep, complex hierarchies, which makes this way worse. The new architecture helps (thanks to view flattening), but the root issue is still there.
Maestro suggests migrating to the new arch, but the real bottleneck is this accessibility label generation logic.
Maestro suggests migrating to the new arch, but the real bottleneck is this accessibility label generation logic.
The problem? Maestro queries the whole view hierarchy accessibility labels, which are generated recursively.
When it queries the root view of your app, RN will recurse through every single view and concatenate every bit of text. This then repeats for each view.
In our case it would take 30 secs 🐢
When it queries the root view of your app, RN will recurse through every single view and concatenate every bit of text. This then repeats for each view.
In our case it would take 30 secs 🐢
June 13, 2025 at 6:55 PM
The problem? Maestro queries the whole view hierarchy accessibility labels, which are generated recursively.
When it queries the root view of your app, RN will recurse through every single view and concatenate every bit of text. This then repeats for each view.
In our case it would take 30 secs 🐢
When it queries the root view of your app, RN will recurse through every single view and concatenate every bit of text. This then repeats for each view.
In our case it would take 30 secs 🐢
Maestro constantly inspects the view hierarchy using Apple’s snapshotting APIs to get things like position, text, accessibility labels...
RN has a feature that generates accessibility labels by recursively combining text from children, useful when you don’t pass it as a prop.
RN has a feature that generates accessibility labels by recursively combining text from children, useful when you don’t pass it as a prop.
June 13, 2025 at 6:55 PM
Maestro constantly inspects the view hierarchy using Apple’s snapshotting APIs to get things like position, text, accessibility labels...
RN has a feature that generates accessibility labels by recursively combining text from children, useful when you don’t pass it as a prop.
RN has a feature that generates accessibility labels by recursively combining text from children, useful when you don’t pass it as a prop.