What happened
Maestro released CLI 2.12.0 on October 28, 2026. Its headline addition is queue priority for uploads to Maestro Cloud, the hosted execution service for Maestro’s mobile UI-test flows. A team can run maestro cloud --priority high to place an upload ahead of that organization’s normal- and low-priority uploads that are still waiting. The intended use is explicit: high priority for a release candidate or hotfix, low priority for nightly runs that can wait, and normal as the default.
Priority is available from the CLI, GitHub Actions, and Maestro’s MCP tool, run_on_cloud. That last surface matters for teams using an agent or another automation layer to initiate tests: the same job can now carry an urgency signal rather than entering the queue as an undifferentiated run. Priority can also be changed in the Maestro Console while an upload is still running. There are important boundaries. It only reorders an organization’s own queue; it does not put that organization ahead of another customer’s work, and it does not change concurrency limits. Using it requires Maestro CLI 2.12.0 or Maestro Cloud Action 3.1.0.
The release also changes validation behavior that could affect existing flows. Scroll speed must now be between 0 and 100, and invalid points fail a flow rather than receiving a silent default. Literal invalid values are caught at upload before a device boots; variable values are checked at runtime. Maestro says this lets Cloud report test errors without unnecessarily retrying them. Teams upgrading should inspect flows that may have depended on invalid values being tolerated.
On Android, pressKey: Tab now moves focus rather than typing an incorrect character. On Android 12 and later, inputText and eraseText inject key events directly and no longer wait on window animations. Maestro reports that, in one reproduction, entering 21 characters fell from more than 200 seconds to four to 16 seconds. The start-device command now prompts in about five seconds, recognizes installed system images, and reports a failed boot within roughly a minute with a pointer to the emulator log.
For iOS, simulators can start under Xcode 27, which ships without Simulator.app. They boot headlessly, stream to the device viewer, and accept taps and button presses; Xcode 26 and earlier are unchanged. The release also improves crash detection by reading a simulator termination record when no system crash report exists, writing the result to logs/crash-report.txt in the run bundle. Screenshot uploads to Cloud work again after a validation issue introduced in 2.11.0, and screenshot diffs are now stored in the run output and listed in manifest.json.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
This modestly supports Agent-ready software exposes capabilities. Maestro exposes Cloud-run priority as a bounded parameter through its CLI, GitHub Action, console, and MCP tool rather than asking an automation system to infer urgency from free-form instructions. The release does not establish broader interoperability, but it is a practical example of a permissioned, observable execution capability.
Why it matters
Mobile-test queues are usually most painful at the moment a team needs confidence fastest: a release candidate, a hotfix, or a late regression check. Before this change, all queued work within an organization had less explicit scheduling intent. With high, normal, and low priority, teams can reserve urgent attention for tests that gate a release while allowing nightly coverage to wait.
The constraint is as important as the feature. Priority does not create more device capacity, bypass other organizations, or eliminate a team’s concurrency limit. It is scheduling inside an existing allocation. Teams should therefore treat it as a workflow control, not as a substitute for capacity planning. The stricter validation and faster Android text entry also make test results more predictable: invalid inputs fail visibly, while some animation-related input delays are removed.
Limits and uncertainty
The source describes product behavior but provides no queue-wait measurements, capacity figures, pricing changes, or evidence that priority improves overall release throughput. It does not say whether high-priority work can starve a team’s low-priority jobs, how priority interacts with retries, or whether every MCP client exposes the parameter equally. The Android timing figure is a single reproduction, not a general benchmark. Nor does the announcement establish how often existing flows rely on values that the new validation rejects. Teams should test upgrades against their own flows and device mix.
Skill to build now
Classify your mobile UI-test jobs into release-gating, routine pull-request, and nightly categories. Update the Cloud invocation for the first category to use high priority only when a human release decision depends on it; keep broad regression suites at normal or low priority. In the same change, lint or review flow definitions for scroll speeds outside 0 to 100 and invalid point or index values. That turns the new scheduling control into an explicit release policy rather than an emergency flag used by every job.
Reader takeaway
Maestro CLI 2.12.0 is a specialized but concrete workflow release: Cloud uploads can now express urgency within an organization’s queue, including through MCP-driven automation. Mobile teams should upgrade deliberately, use priority for genuinely release-critical tests, and check flows for validation behavior that is now enforced.
Open question
Will Maestro publish data showing how queue priority affects wait times and whether organizations need guardrails to prevent high-priority jobs from becoming the default?