Janic Duplessis

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.

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 ...

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...

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.

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 🐢

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.

Sped up iOS e2e test runs with Maestro by ~4x in the Rainbow app 🔥

The improvement was actually in React Native core. Here’s what was happening, and how it was fixed 🧵