Logins and onboarding
OTP, social login, guest to registered upgrades, KYC steps and first launch tutorials validated on every device.
✨ Introducing Playground. Try Panto QA in your browser, no device or install needed. Try now →
Autonomous QA For Mobile Games Across 150+ Real Devices
Unity, Unreal and Canvas games render to a single surface with no element IDs, so Appium has nothing to target and regression stays manual on a handful of phones. Panto's agents see your game the way a player does and test every flow on real hardware. No scripting. No maintenance.
Works with UnityWorks with Unreal EngineWorks with Cocos & CanvasWorks with WebGL & hybrid
Already running in production for real money gaming companies across India and the US.
Trusted by brands, across the globe
The problem
Players don't file bug reports. They uninstall.
Gaming users are the least forgiving audience in mobile. Crash on them once and the data says they rarely give you a third chance.
<1%
Day 30 retention
Even among the top 25% of gaming studios, fewer than 1% of downloads are still playing at day 30. The single biggest driver of uninstalls is app crashes.
0
Stable locators in your game
Unity, Unreal and Canvas render everything to one GPU surface. No element IDs, no accessibility tree, nothing for Appium or Espresso scripts to hold on to.
~5devices
Covered by manual QA
Because automation fails, most studios regression test by hand on whatever phones are on the desk, while players run the game on hundreds of device and OS combinations.
Why game QA stays manualScripts need selectors.
Scripts need selectors.
Games don't have any.
Traditional automation was built for native UI trees. A game is pixels and physics, and every build shifts them, so scripted automation breaks before it ever pays off. Panto takes a different route.
- ✕Appium can't see inside the engine. The whole game is one canvas element to it, so taps, waits and asserts have nothing to target.
- ✕Coordinate scripts die on the next build. A moved button, a new popup or a different screen size and the entire suite needs rework.
- ✕Manual QA can't reach real coverage. Logins, matches, payments and reward flows across 150+ devices is thousands of runs per release.
- ✓Panto's agents are vision based. They read the rendered screen like a player, adapt when the UI changes, and never need a locator, a script or maintenance.
panto · run #482 · release 3.19.0
You ask
“Log in with OTP, dismiss any popups, play one match to the end, add ₹500 cash via UPI, then buy the daily bundle from the reward store.”
PASSLogin with OTP148 / 152 devices
PASSDismiss interstitial and rating popup152 / 152 devices
PASSFull match, start to result screen146 / 152 devices
FAILAdd cash ₹500 via UPI intentPixel 10 Pro XL · A14
ROOT CAUSEPayment SDK freeze after webview handofffix suggested
The difference
Manual QA. Traditional automation. Panto.
The same release, tested three ways. Only one of them runs inside a game engine and tells you what to fix.
Measured on
Manual QA
Testers on desk phones
Traditional Automation
Appium, Maestro, XCUITest
Panto
Vision-based agents
Runs on Unity, Unreal, Canvas
The one that decides everything
●
Yes, but only by hand
×
No. There are no locators to target
✓
Yes. Reads rendered screens without IDs
Time to first test running
Speed
●
2 to 3 days writing and assigning cases
×
4 to 8 weeks of framework setup and scripting
✓
Under an hour. Upload build and describe flow
Devices per regression cycle
Coverage
×
3 to 6 phones that happen to be in office
●
10 to 20, mainly scripted paths
✓
150+ real Android and iOS devices every run
Full regression turnaround
Efficiency
×
3 to 5 days and it blocks release
●
8 to 14 hours when scripts still hold
✓
Runs in parallel. Around 23 minute average
Maintenance per release
Cost that compounds
×
Cases rewritten by hand every sprint
×
30 to 40 percent of QA time repairing scripts
✓
None. Agent adapts to UI changes automatically
Add cash and payment flows
Revenue critical
●
Tested manually on a few devices by miss
×
Rarely automated. SDK handoffs required
✓
UPI, card, wallet and 3DS handoffs covered
Random popups and interstitials
Reliability
✓
Handled by a human tap-through
×
Unexpected dialogs fail run and trigger noise
✓
Dismissed automatically, execution continues
Answer when something fails
Accuracy
×
A screenshot, a Jira ticket and a guess
●
A stack trace without device context
✓
Root cause, exact device and what to fix
FPS, memory, CPU, battery
Quality signals
×
Not possible by hand
×
Not captured by functional scripts
✓
Tracked on every run and trended per release
How cost scales
Unit economics
×
Linear with testers and devices
×
High setup plus permanent upkeep
✓
Scales with runs, not with headcount
Traditional figures reflect typical mobile QA workflows. Panto figures are from live customer runs.
What it tests
Any flow a real player runs. Including the money.
Describe the flow in plain language and the agent runs it end to end on 150+ real Android and iOS devices across OS versions, every release.
Full gameplay loops
Start a match, play to the end, reach result screen. The agent handles game state changes, not just menus.
Random popups and interstitials
Rating prompts, promos, permission dialogs and ads appear unexpectedly. The agent dismisses them and keeps going.
Add cash and deposits
Wallet top-ups and deposit flows through UPI, cards and net banking, tested through the real payment SDK handoff.
Reward store transactions
Bundle purchases, coin redemptions and in-game store flows checked for both success and failure states.
Card and PayPal payments
End-to-end card and PayPal checkouts, including 3DS and webview handoffs where SDKs most often freeze.
One report. Every device. Both platforms.
Pulled from a run across 150+ real Android and iOS devices, with the root cause already worked out, not just a pass or fail.
Cross-device
Tested on the phones your users actually carry
Not one emulator. These are 8 of the 150+ real device and OS combinations we run every release, so a Pixel-only crash never reaches a release looking like a clean pass.
Pass rate by device × OS
| Device | OS | Tests run | Pass rate | Status |
|---|---|---|---|---|
| Pixel 9 | Android 14 | 788 | 34% | Problem |
| Pixel 9 | Android 15 | 312 | 82% | Stable |
| OnePlus 11 | Android 13 | 768 | 45% | Watch |
| Galaxy S23 Ultra | Android 13 | 665 | 46% | Watch |
| Galaxy S24 | Android 14 | 230 | 51% | Watch |
| Pixel 10 Pro XL | Android 14 | 662 | 44% | Problem |
| iPhone 16 Pro | iOS 18 | 91 | 79% | Stable |
| iPhone 17 Pro | iOS 26 | 60 | 73% | New device |
iOS vs Android
Catches the bugs that only show up on one platform
163 errors this week, every one of them on Android. The same flows pass on iOS, which points straight at an SDK or OS issue instead of a code review.
Platform split
Android
43%
4,205 tests · 163 errors
iOS
59%
151 tests · 12 errors
Worst combo
Pixel 9 · A14
34% pass
Best combo
iPhone 16 · iOS 18
79% pass
Pass and fail
A number for every release decision, not just a percentage
Stability score, pass rate, and bugs caught update after every run, so "are we ready to ship" has an answer before someone has to ask.
Stability score
0
▲ +11 vs prev week
Pass rate
0%
▼ -4% vs prev week
Bugs detected
0
0 in production
AI-authored flows
0
▲ +14 vs prev week
Consistently failing
0
5+ consecutive runs
Flaky flows
0
Pass-fail pattern
Resolved this week
0
Within 48h SLA
Avg detection time
0 min
▼ -41 min vs prev week
App health
Watches the app, not just the test script
Memory, startup time, and frame rate get tracked across every run, so a slow leak shows up days before a user ever files a complaint.
↑ Memory regression across the last 5 runs
242MB to 302MB, a 25% increase, while FPS and crash rate stay flat.
Aggregated across all devices this period
Cold startup
0ms
▲ +13%
Hot startup
0ms
Stable
Max memory
0MB
▲ +24%
Avg memory
0MB
▲ +18%
Max CPU
0%
▼ -2%
Avg FPS
0FPS
Stable
Freeze frames
0%
▲ +0.4%
Janky frames
0%
Normal
Battery / session
0%
Stable
Network DL
0KB
Normal
App crashes
0
None
ANR events
0
None
Memory trend
R1
R2
R3
R4
R5
CPU trend
R1R5
Cold startup time
R1
R2
R3
R4
R5
Built for real money gaming
Already testing real money games in India and the US
When cash moves through your app, a broken deposit flow is not a bug, it is lost revenue and lost trust. Panto runs QA in production for real money gaming companies where payments, wallets and compliance flows have to work on every device, every release.
Payment handoffs, end to end
UPI intents, card checkouts, 3DS and PayPal, tested through the real SDK handoff where freezes usually happen.
Wallet and reward integrity
Add cash, withdrawals, bonus credits and reward store purchases verified for both success and failure paths.
Confidence on real hardware
Every flow on 150+ real Android and iOS devices, so device-specific payment failures never ship.
Most of mobile gaming QA is still manual. Yours does not have to be.
Ask the agent to test your game and watch it run on 150+ real devices in your first session. No scripts, no SDK integration, no maintenance.
Book a demo to see Panto QA in action.
Questions gaming teams ask us
Yes. Panto's agents are vision based. They read the rendered screen the way a player does, so they do not depend on element IDs, accessibility trees or locators at all. That is exactly why they work where Appium, Espresso and XCUITest cannot, on Unity, Unreal, Cocos, Canvas and WebGL games.
No. You describe the flow in plain language, for example 'log in, play one match to the end, add cash and buy the daily bundle', and the agent runs it. When your UI changes in the next build, the agent adapts. There is no script suite to repair, ever.
Those tools need something stable to target: a selector or a fixed screen position. Game engines give them neither, and every build shifts pixels. Panto understands what is on screen semantically, so a moved button, a new popup or a different device resolution does not break the run.
Yes. Panto already runs QA for real money gaming companies across India and the US. It tests logins, add cash and deposits, reward store transactions, and credit card, PayPal and UPI payments end to end, including WebView and 3DS handoffs where SDKs most often freeze.