How to automate apps with no API | ft. Mobilerun AI | Payload Website Template — mobilerun

Every developer hits this wall eventually. You need to pull payouts out of a banking app, post to a creator account, verify an SMS code on a virtual phone, or stitch a mobile workflow into a backend pipeline and the moment you go looking for the API, you find one of three things: there isn't one, there is one but it's locked behind a partnership form, or there is one but it's missing the exact thing you need.<br>For a long time, the answer was "tough luck, scrape the UI." That answer is finally changing, and the reason is that AI agents have gotten good enough to drive a phone the same way you would. This post is about how that actually works in practice with Mobilerun ai.<br>Why so many apps don't have APIs<br>It's worth being honest about why this gap exists. Most consumer apps, banking, social, messaging, dating, creator tools, super-apps in non-Western markets don't ship public APIs because their business model wants you to use the app.<br>APIs introduce surface area they don't want: scraping, abuse, churn from third-party clients, regulatory headaches. Even when an API exists (Instagram Graph, WhatsApp Business, the various fintech sandboxes), it's almost always a narrow slice of what the app itself can do.<br>So if your job involves automating real-world consumer mobile flows, you're not waiting for an API. You need a different abstraction.<br>The old workaround, and why it kept breaking<br>The classic answer was UI automation frameworks: Appium, Espresso, XCUITest, Selenium-for-mobile. The problem is they're brittle in exactly the way that matters. You write a script that taps //XCUIElementTypeButton[@name="Send"], the app ships a redesign, the selector moves, and your pipeline silently dies.<br>You spend more time fixing selectors than shipping features. You add retries, then sleeps, then "wait for element," then a custom DOM diff tool, and eventually you realize you've built a small, sad browser inside your test harness.<br>The deeper issue is that these tools require you to describe the UI structurally, but apps don't actually have stable structure. They have intent. A human looking at a banking app doesn't think “tap the third button in the second tab" they think "open Payouts." Until recently, no tool could close that gap.<br>What changed: agents that see screens like humans<br>LLMs with vision finally made it cheap to do what humans do: look at a screen, decide what to tap, do it, look at the result, repeat. Combine vision with the accessibility tree the OS already exposes, and you have a model that can both see the pixels and read the semantic structure which is more robust. Add a planner that breaks "post this clip to an app and respond to comments" into the dozen taps and swipes it actually requires, and you have a real mobile agent.<br>That's the category Mobilerun lives in.<br>Enter MobileRun<br>Mobilerun is an open-source framework that lets you point an LLM at a real Android or iOS device and tell it what to do.<br>It reads the screen via accessibility plus vision model, plans multi-step workflows, and drives the device with taps, swipes, and text input. There's a CLI for one-off tasks, a Python SDK for embedding it into your own code, and a hosted cloud if you'd rather not babysit physical phones.<br>A few things make mobilerun interesting if you're a developer evaluating this space:<br>Mobilerun is LLM-agnostic. You can plug in Anthropic, OpenAI, Gemini, Ollama, or DeepSeek depending on what tradeoffs you want on latency, cost, and on-prem requirements. The agent loop is the same; the brain is yours to choose.<br>Mobilerun works on real devices, not just emulators. That matters more than it sounds. Many apps such as banking, dating, healthcare, anything with high security can sniff for emulator signals, missing SIMs, or suspicious network properties and quietly degrade.<br>Running on a real device with a real SIM and a real residential network means the app behaves the way it would in a user's hand. Mobilerun provides exactly that: persistent, dedicated mobile devices with eSIMs and locality, so the automation runs reliably.<br>What this looks like in code<br>Install:<br>1pip install mobilerun<br>Copy

Set up a device (real phone over USB, or a cloud device) and pick a model, and then run a one-liner command.<br>1open settings and turn on dark mode<br>Copy

That's the whole loop. The agent decides what to tap, retries when something fails, and gives you back a typed result. To scale from one phone to a hundred, you swap your local driver for the cloud config.<br>Where this actually pays off<br>A few workflows where this approach beats either an API integration or traditional UI tests:<br>1. End-to-end testing of your own app where flows change weekly and you're tired of fixing selectors. Describe the test in English, let the agent figure out the taps.<br>2. Account workflows automation at scale: scheduling posts, replying in DMs, managing creator inboxes across dozens of accounts....