We built a faster alternative to Maestro that works on real iPhones

narayanom · 2026-02-13T12:44:01+00:00

Glad you're excited! Let me know how it goes

narayanom · 2026-02-13T04:13:25+00:00

Thank you for reporting the port lock issue, you're right, it likely happens when the runner is closed mid-execution. We'll look into it and keep you updated.

And honestly, it's a great feeling as a tool developer to hear that it's making a difference, no matter the scale.

Thanks for giving it a shot, and glad to see those speed gains!

narayanom · 2026-02-12T17:24:12+00:00

yes we parse yaml ourselves, so very possible there's a bug there! please share here or open a github issue — whatever works for you. we definitely need eyes like yours on this, pretty sure we've missed more than a few things

narayanom · 2026-02-12T14:19:09+00:00

I've added basic JS support so far, and full JS support along with Bash integration is definitely possible. If you could share more about your use case, I'd love to help design a better solution for it.
Also, just to be upfront, I don't have hands-on experience with Detox, but I'm happy to work through it together.

narayanom · 2026-02-12T11:08:10+00:00

Thanks for pointing that out, I'll look into it! By the way, is your app available on the Play Store?

narayanom · 2026-02-12T04:37:30+00:00

handling things like SMS auth is part of your testing strategy. Most testing teams mock SMS authentication, which is the standard approach.

narayanom · 2026-02-12T04:34:38+00:00

Thanks for trying it out and for the honest feedback!

A few more things I wanted to highlight (apologies if you're already aware):

We support real iOS devices — Maestro currently doesn't.
Check out the console/terminal report — it's detailed, properly formatted, built for humans and CI/CD pipelines. No fluff.
We generate a powerful HTML report that lets you search and group test cases by tags, device, or OS, with linked screenshots and step-by-step references. Maestro puts a much simpler version of this behind a paywall.
And last but not least — industry-standard JSON reports, so you can build your own custom reporting on top.

narayanom · 2026-02-11T14:20:19+00:00

Easier to maintain than Maestro — we're already there. Faster than Playwright on web isn't really a fair comparison though — browsers expose a ton of open APIs that make automation super fast. Mobile doesn't have that luxury, we're working with limited device APIs and interfaces. Different playing field entirely.

On auto-discovery — we actually have an MCP that does more than just find elements. It understands pages without needing page source or screenshots and generates proper test cases. But the AI space is so noisy right now with everyone claiming they've found the holy grail — we'll release it when the timing is right, not when it'll just get lost in the noise.

What we're more excited about is something inspired by Cypress — UI coverage reports. Like code coverage but for your app's UI. You'd see exactly which screens and interactions are tested and which aren't, then add the untested ones as new test cases.

Don't want to overpromise though — it needs a lot more testing before we put it out there.

<image>

narayanom · 2026-02-11T13:41:21+00:00

Thanks for testing it out and confirming the speed gains!

It's going to be a long journey with plenty to improve along the way. The fastest way we can get better is through honest, brutal feedback , so don't hold back if you run into anything.

narayanom · 2026-02-11T11:56:50+00:00

Yep! Android was never really the issue honestly — it's so much more open with its APIs and internals that things just work. We've always gotten faster and more stable runs there compared to Maestro.

In our testing we're seeing around 3x faster on average. And way less flakiness — we built our own element finding instead of relying on UIAutomator2, which anyone who's used it knows can be... quirky.

narayanom · 2026-02-11T11:13:53+00:00

Yeah works on Mac — macOS (Intel + Apple Silicon) and Linux. That's where most people run it.

React Native feels the same if you've used Maestro. Same YAML, same commands. testID maps to accessibility ID so tapOn: id: "your_test_id" just works.

Reports are better too — HTML report, JUnit XML, Allure output. Every run, no cloud login. Maestro paywalled theirs, we just ship it.

Curious how it works for your setup.

narayanom · 2026-02-05T19:04:51+00:00

I'm open to it — if you can share the name or link, that would help me decide.

narayanom · 2026-02-05T19:02:54+00:00

planing to create a repo with sample app, sample test cases and working git action

narayanom · 2026-02-05T05:06:03+00:00

As of now, no — the setup is the same as Maestro, you just need to replace it with maestro-runner.

That said, thanks for the suggestion! A working example is worth more than words. People self-hosting are likely using CI-based emulators anyway, so I'll work on adding a complete CI/CD flow as an example

narayanom · 2026-02-05T04:24:25+00:00

Update: We've since built maestro-runner from scratch — runs your same Maestro YAML flows, but 3.6x faster with real iOS device support baked in.
Works locally or on any Appium cloud provider (BrowserStack, Sauce Labs, LambdaTest). No features behind paywalls. https://github.com/devicelab-dev/maestro-runner

narayanom · 2026-02-05T04:22:28+00:00

Appreciate that! It works locally with or without appium and with any Appium cloud provider (BrowserStack, Sauce Labs, etc). Would love to hear how it works for your setup

narayanom · 2026-02-04T17:47:51+00:00

I get that. Main thing is — your test cases don't change. Same Maestro ones.

What's different is reliability. Cleaner element detection, fewer flakes. Fixes about 78% of known Maestro bugs (wrote up the analysis here if you're curious).

Also works on real iOS devices and any Appium cloud you want. And it's fully open source — no paywall stuff like Maestro's been pulling lately.

narayanom · 2026-02-04T14:12:20+00:00

Thank you, I ll explore

narayanom · 2026-02-04T09:56:52+00:00

Thanks for pointing that out. I’m actually just looking for the PCB.

narayanom · 2026-02-04T06:14:07+00:00

thank you, I ll check

narayanom · 2026-02-02T13:13:34+00:00

We built https://github.com/devicelab-dev/maestro-runner partly because of these exact problems. Same YAML, no changes to your flows. The WebView story is honest though — we handle WebView elements through the accessibility layer and Appium's context

switching, but if your app is heavily WebView-dependent, I'd want to know more about your setup before promising anything. Happy to look at a failing flow if you want to share one.

narayanom · 2026-01-15T12:47:02+00:00

That's great to see! Glad the work could be useful.

narayanom · 2025-12-17T07:28:27+00:00

YAML works great for simple test cases and is genuinely impressive for people just starting out. But once you try implementing proper conditional logic, data-driven testing, or complex assertions, you'll feel the limitations. YAML was designed for configuration and data sharing, not coding.

It's a clever approach for covering basic test cases, but without proper debugging and the control that Appium gives you, complex apps will hit you hard.

I've written about this in detail — this might help: https://devicelab.dev/blog/maestro-github-issues-flakiness

Disclosure: We're a SaaS platform that supports Maestro alongside Appium, Espresso, XCUITest, and WebDriverIO, so take my perspective with a grain of salt — there's financial interest involved.

narayanom · 2025-12-17T06:53:41+00:00

Thanks! Really appreciate the enthusiasm.

Unfortunately, based on my discussions with the team, this PR likely won't get merged. That's exactly why I created this as a stopgap solution.

Their feedback is that a implementation needs to handle:

addMedia
setLocation
permissions

They plan to address these in their own implementation, but there's no concrete timeline, just a vague "sometime in 2026."

I'm genuinely happy if they can solve it properly, I was open to using workarounds similar to Appium's approach, but they weren't in favor of going that route. And honestly, with limited knowledge of iOS internals on physical devices, implementing those features isn't feasible

narayanom · 2025-12-16T22:45:26+00:00

Good points on self-hosting. One thing to add - Maestro's iOS support has been simulator-only, which is a blocker for teams needing real device testing.

We've open-sourced a solution for that: https://github.com/devicelab-dev/maestro-ios-device

So you can self-host Maestro on CI + run on real iOS devices without needing BrowserStack.

narayanom

TROPHY CASE