Having Fun with Appetize.io
We pointed our AI agent at Appetize.io to see if it could test a native mobile app. Spoiler: it worked.
We had a question: Certyn's agent lives in a browser. It can emulate mobile viewports and test responsive web apps all day. But what about native mobile apps — the ones that only run on actual iOS and Android devices?
Turns out, you don't need a physical device. You just need a browser that shows one.
The Idea
Services like Appetize.io let you stream real iOS and Android devices directly in the browser. You upload your app, pick a device, and get an interactive emulator right in a webpage.
Our agent already knows how to use a browser. And a streamed device inside a browser is still just... a browser. So what happens if we point the agent at it?
The Experiment
We uploaded a sample app to Appetize.io, grabbed the embed URL, and wrote a simple test case:
"Open https://appetize.io/embed/demo123?device=iphone15pro&osVersion=17.0 — once the device loads, open the app, navigate to the settings screen, toggle dark mode, and verify the theme changes."
That's it. No special tools, no SDK integration, no custom agent image. Just a URL and an instruction.
What Happened
The agent opened the URL. Appetize loaded an iPhone 15 Pro in the browser. The agent looked at the screen, saw the device, and started tapping. It navigated through the app, found the settings screen, toggled the switch, and confirmed the theme changed.
It treated the emulated phone exactly like it treats any other webpage element — something on screen that it can see and interact with.
Why This Is Interesting
The agent doesn't know it's looking at a phone. It just sees pixels and uses computer_use to click, swipe, and type. This means anything you can stream into a browser becomes testable:
- iOS apps via Appetize.io
- Android apps via Appetize.io, BrowserStack, or LambdaTest
- Real device clouds like Samsung Remote Test Lab
- Theoretically, anything with a web-based remote viewer
No new tools needed. No code changes. The existing agent handles it.
The Rough Edges
It's not perfect — this was an experiment, not a polished feature.
- Latency — there's a delay between the agent's click and the device responding. The agent sometimes clicks twice because it thinks the first tap didn't register.
- Orientation — the agent occasionally gets confused by the device frame around the actual screen content.
- Gestures — simple taps work great. Complex gestures like pinch-to-zoom or multi-finger swipes are harder for the agent to pull off.
- Setup time — if the agent has to log in to Appetize and navigate to the right app, that eats into test time. Passing a direct embed URL is much better.
What We Learned
The biggest takeaway: our agent architecture is more flexible than we originally designed it to be. Computer use is screen-based, not browser-based. Anything that shows up on screen is fair game.
For now, this is an experiment. We're not shipping "native app testing" as a feature tomorrow. But it showed us a clear path to Phase 2 — pick a device cloud provider, integrate their API to auto-provision sessions, and hand the URL to the agent.
The agent already knows what to do with it.
Try It Yourself
If you have an Appetize.io account:
- Upload your app and grab the embed URL
- Create a test case in Certyn with that URL as the starting point
- Describe what you want to test in plain language
- Watch the agent interact with your native app
We'd love to hear what happens. Some apps will work flawlessly, others might trip the agent up — and that feedback helps us figure out what to build next.