"Why is it called 2.0? "Isn't this just another release?"

Not exactly.

But to understand why Maestro 2.0 is such a major thing, we need to go back to the beginning.

The Journey So Far: Why Maestro Exists

When Maestro first launched, the mobile testing landscape was broken. Teams were trapped between two bad options: clunky UI automation tools that required endless maintenance, or writing brittle code-based tests that broke with every UI change.

The problem was clear: Mobile teams needed a testing solution that was both powerful enough for complex scenarios and simple enough that anyone could write and maintain their tests. They needed something that could adapt to fast-moving projects instead of slowing them down.

Maestro's mission was born from this frustration: Create a testing framework that feels natural to write, runs reliably across devices, and actually helps teams ship better apps faster.

And it worked. Maestro was adopted by thousands of teams because it solved real problems:

• No more flaky tests that pass one day and fail the next
• No more complex setup that takes weeks to configure
• No more "it works on my machine" scenarios across different devices and environments

But as Maestro grew, so did the ambitions of the teams using it. In addition to mobile apps, they wanted to test web applications. They required more advanced capabilities, and more modern tooling.

The foundation that got us here wasn't going to take us where we needed to go.

Therefore, we focused on updating the foundation that prevented us from moving forward, which now enables us to build features that were not possible before.

Maestro 2.0: A New Era Begins

Consider this release as Maestro getting ready for the next step.

⚠️ Action required

Before you upgrade:

• Maestro 2.0.0 requires Java 17+ (older versions will not work).
• If you rely on Rhino-only scripts, either update them or temporarily set jsEngine: rhino .

Java 17: A Modern Foundation

“Why is updating Java such a big deal? Up until now, I've been managing Maestro well!”

Java 17 removes the technical barriers that were holding Maestro back. This modern foundation unlocks features that older Java versions simply can't support.

It's more like upgrading your foundation so we can build you a better home for you.

⚠️ Heads-up: Before using Maestro 2.0.0, update to Java 17+ if you're using Java 16 or below.

Default JavaScript Engine is now GraalJS

"Wait… JavaScript engine? I didn't even know Maestro had one!"

Sure, it does. Up until now, Rhino, a JavaScript engine that stopped evolving years ago, was in charge of it. Teams constantly hit walls: modern JavaScript syntax didn't work and debugging was a nightmare.

The adoption of GraalJS was made possible by Java 17, and it is now the default engine in Maestro 2.0.0.

The problems Rhino created:

• Syntax limitations: No modern JavaScript features (No ?? operator, arrow functions, and more)
• Inconsistent behavior: Different results across environments
• Debugging nightmares: Cryptic error messages that wasted hours

GraalJS changes everything:

• It's modern. Finally use the JavaScript you know and love
• It's consistent. Predictable behavior across all environments
• It's debuggable. Clear error messages that actually help you fix issues

Here's what's now possible:

# Modern JavaScript that actually works
- inputText: ${user?.name ?? 'Anonymous'}
- assertVisible: ${items.filter(item => item.active).length > 0 ? 'Active Items' : 'No Items'}

If you need the old engine for legacy scripts, you can still switch back:

appId: com.example.app
jsEngine: rhino

📚 Curious about the differences? Read the GraalJS behavior guide →

Meet Maestro Studio Desktop 🖥️

"Why is it so difficult to create tests? Why do I have to keep switching between the emulator, studio web and code editor?"

This highlighted a bigger issue: Writing Maestro tests had an unnecessary learning curve, and the constant context switching between tools made building, maintaining, and debugging tests frustrating and inefficient.

Write, maintain, and debug your tests at a single using Maestro Studio Desktop, where test development becomes intuitive. Test generation is no longer a technical challenge. Maestro Studio Desktop makes it a simple, visually appealing & intuitive process that team members with and without technical expertise can use efficiently.

The Desktop app is currently in beta. If you are looking to simplify your testing workflow, do give it a try! We'll love to get your feedbacks and improve Studio Desktop. Download Maestro Studio Desktop - Beta →

First step into WEB TESTING 🎉

Web testing support has been our most requested feature, with users asking: "When will Maestro support web testing?"

The wait is over. We're excited to introduce web testing capabilities as our first step into expanding beyond mobile.

What's new:

1. Run Multiple Web Flows with one command

“Mobile flows could always run together… but web?”

Now, yes. With Maestro 2.0, you can run your entire web workspace in a single command:

# You can now run entire web workspaces
maestro test workspace_containing_multiple_web_flows

2. Clearer Web Flow Configuration:

“Why is Maestro thinking my web test belongs to some random app?”

That’s what can happen when you define a web flow using appId, sometimes it guesses wrong.Web flows now explicitly require to use url instead of the confusing appId field.

url: https://maestro.mobile.dev
---
- launchApp
- assertVisible: "Welcome to Maestro"

⚠️ Still using appId in your web flows? Time to switch to url

Web testing in Maestro is currently at its early stages. While the core functionality works, we're still optimizing and expanding capabilities. We will be learning from early adopters and continuously improving the experience.

If you're interested in web testing, we'd love your feedback and continue to improve Maestro for web Testing as well.

New Command: setOrientation

"Ever had to rotate your device mid-test just to see if the UI breaks?"

This seemingly simple problem highlighted a bigger issue: Maestro couldn't adapt to how real users actually interact with apps. Users rotate their devices constantly, but tests were locked to a single orientation.

You now get complete orientation control within your tests

appId: com.example.maestro.orientation
---
- launchApp
- setOrientation: LANDSCAPE_LEFT
- assertVisible: "Landscape Layout"
- setOrientation: PORTRAIT  
- assertVisible: "Portrait Layout"

Supports:

• PORTRAIT
• UPSIDE_DOWN
• LANDSCAPE_LEFT
• LANDSCAPE_RIGHT

Example:

appId: com.example.maestro.orientation
---
- launchApp
- setOrientation: LANDSCAPE_LEFT

Now you can catch those orientation dependent layout issues before your users do. Documentation for setOrientation →

MCP: AI That Actually Helps

MCP brings AI-powered testing that could understand your app, understand your test scenarios, look at the screens and accordingly generate meaningful test.

The change in 2.0:

• Better flow path handling: LLMs are now able to resolve paths in flow files with greater accuracy.
• Optimized view hierarchy: Reduce output size by more than 50% without losing clarity
• Better environment and hooks support: run_flow and run_flow_files now handle environment variables and hooks just like your regular flows.

With these changes, MCP runs are cleaner, faster, and far more predictable. How to set it up →

Own your Artifacts

"Where did that screenshot go? Wait… where are the logs?!"

When tests failed in CI, teams often spent extra minutes searching for the right screenshot or log file after a failed test. While not a critical blocker, it was still a distraction.

The solution: Complete control over your test output. Pick where screenshots, logs and AI reports go with testOutputDir or --test-output-dir. How to set it up →

# In config.yaml
testOutputDir: your_maestro_output_directory

# Or via CLI
maestro test workspace --test-output-dir=your_maestro_output_directory

Other Notables

A couple of smaller changes that still make a big difference:

• DataFaker is now available in JavaScript to generate random data for use in tests Doc →
• Fix CLI Cloud upload output
• Allowed Keep-Alive from Server to support for persistent connections.
• Environment variables are now isolated between peer runFlow commands.
• Fixed maestro cloud command when uploading files that have external dependencias (subflows, scripts and media)
• Fix disconnect in local iOS test executions when flow contains a large element tree

🚀 Quick upgrade checklist

1. Check Java version

   java -version
   

2. Install or switch to Java 17

3. Update Maestro to 2.0.0

4. If you used Rhino-specific JS, either update scripts or set jsEngine: rhino temporarily

Why Maestro 2.0 Matters

Recently, a Maestro team informed us of their "JavaScript incident." After months of successfully running tests, they made the decision to update their test logic using some ES2020 features. Suddenly, half their flows were failing with cryptic Rhino errors. After hours of debugging, they discovered that the engine was the problem, not their reasoning.

That's exactly the kind of friction we are expecting to eliminate. You shouldn't have to think about whether your testing framework can handle modern JavaScript. You shouldn't waste time hunting for screenshots when a test fails. You shouldn't need separate tools for web and mobile testing.

Maestro 2.0 is the beginning for fixing such issues. The JavaScript engine that couldn't keep up? Replaced. The Java runtime hitting feature limits? Upgraded. The AI tools giving inconsistent results? Improved.

Sometimes the most important releases are the ones that simply remove the friction you didn't realize was there.

👉 Read the full changelog →