DEV Community: Priya Negi

How to scrape data from an app without getting banned

Priya Negi — Tue, 28 Jul 2026 12:14:07 +0000

Best Practices for Scraping

We wrote a few lines of Python, sent some requests, and our scraping pipeline seemed to work flawlessly. But once we started scraping at scale, things changed quickly. Suddenly we were getting errors, running into CAPTCHAs, or receiving empty pages instead of the data we needed. That's when we realised scraping is a lot harder than it looks. So, after loads of hardship and failures, we want to share our playbook on the best practices for scraping.

Essential fundamentals

Most bans happen because people ignore the basics. Before reaching for exotic tools, get these right.

Check robots.txt and the Terms of Service

Nearly every site publishes a robots.txt at its root (e.g. example.com/robots.txt) telling automated clients which paths are off-limits. Ignoring it won't just get you blocked faster; depending on the jurisdiction and the data, it can carry legal risk. If a site offers an official API, use it. An API is a sanctioned, structured door into the data, and it will always be more stable than scraping the HTML that surrounds it.

Slow down

The single most common reason people get flagged is hammering a server with requests far faster than any human could browse. Add delays between requests, and make them variable rather than a fixed one-second tick, since perfectly regular timing is itself a bot signal. Something in the range of a few seconds, randomized, is a reasonable starting point for polite scraping.

Handle errors gracefully

When you get a 429 Too Many Requests or a 403, do not immediately retry in a tight loop. That's the fastest way to escalate a soft throttle into a hard ban. Back off, wait, and reduce your rate. Respect the signal the server is sending you.

Rotate your identity where appropriate

This means rotating IP addresses (via proxies) and varying your User-Agent and headers so you don't look like a single machine making thousands of identical requests. Residential and mobile proxies are harder to flag than datacenter IPs, which most anti-bot systems keep on known blocklists.

These fundamentals will carry you a long way on lightly-defended sites. The trouble is that a growing share of the web is not lightly defended.

Why browser-based scrapers get blocked

Here's the part that trips up most people. You can follow every rule above, rotate perfect residential proxies, set a flawless Chrome User-Agent, and still get blocked before your scraper receives a single line of HTML. To understand why, you have to understand that modern anti-bot systems (Cloudflare, DataDome, Akamai, Kasada, PerimeterX/HUMAN) don't rely on any one signal. They combine several layers, and a scraper has to pass all of them simultaneously.

Layer 1: TLS and network fingerprinting

Before a website even sees your request, it can already learn a lot about the software making it. When your scraper connects, it goes through a security step called a TLS handshake. During this process, it sends technical details that act like a fingerprint.

The problem is that common scraping tools like Python's requests or Node's axios have fingerprints that don't look like real browsers. Websites compare this fingerprint with the browser you're claiming to be. So if your request says it's coming from Chrome, but the fingerprint clearly looks like a Python script, that's a strong sign you're a bot and your request may be blocked before the page even loads.

Layer 2: Browser and device fingerprinting

Even if your request gets past the first checks, websites have another way to detect bots. They run JavaScript in your browser to collect information about your device and browser. This includes things like your screen size, graphics card, installed fonts, browser settings, and many other small details that together create a unique browser fingerprint.

Headless browsers, which are commonly used for scraping, often stand out because they don't behave exactly like a real browser. For example, they may reveal that they're running in headless mode or expose properties that websites use to identify automation. While there are tools that try to hide these signs, modern anti-bot systems look at dozens of signals together. Fixing one or two isn't usually enough, because real browsers have consistent, natural-looking fingerprints that are hard to fake completely.

Layer 3: Behavioral analysis

Even if your browser looks real, it also has to behave like a real person. Websites don't just look at what browser you're using, they also watch how you interact with the page. They can track things like how you move your mouse, how you scroll, how fast you type, where you click, and how long you stay on a page.

Bots often behave differently from people. They move the mouse in perfectly straight lines, click almost instantly, and type at a perfectly consistent speed. Real users are much less predictable, they pause, make mistakes, scroll at different speeds, and interact naturally. Modern anti-bot systems use machine learning to spot these patterns, so even if one signal looks normal, several suspicious signals together can reveal that it's a bot.

This is why building a reliable browser-based scraper is so difficult. You have to make your browser look real, behave like a real person, and constantly keep up with new detection techniques. That means managing browser fingerprints, proxies, and human-like behaviour all while websites keep improving their defences. It quickly becomes an ongoing battle that's both complex and expensive.

The alternative: scraping through the mobile app layer

Here's a shift in perspective that a lot of scrapers miss. Almost all the detection machinery above was built to catch browser automation on the web. But an enormous amount of the world's data now lives in mobile apps, often data that isn't even exposed on the website. And the detection story on mobile is very different.

This is where Mobilerun comes into the picture. Instead of driving a headless browser, Mobilerun runs an AI agent on real Android and iOS devices in the cloud. The agent sees the screen, reads the app's UI accessibility tree, and interacts the way a person would: tapping, swiping, scrolling, and typing. It extracts structured data directly from the app.

Why this avoids so much of the detection problem

The reason browser scrapers get caught is that they present a synthetic environment and detection systems are purpose-built to spot exactly those artifacts. Mobilerun changes the situation on several fronts:

It's a real device, not an emulator or headless browser.

Real phones don't have many of the giveaways that browser-based bots do. There's no navigator.webdriver flag, no headless browser identifier, and no browser fingerprint that doesn't match the device. Everything from the hardware and operating system to the sensors and installed apps is exactly what you'd expect from a real person's phone.

That's a big advantage because anti-bot systems are looking for consistency. Real devices naturally provide it, while emulators and virtual devices often expose artificial hardware details or other subtle signs that they're not genuine. A physical phone simply behaves like a normal phone, making it much harder to distinguish from a real user.

Real sensor and network characteristics.

Physical phones produce noisy accelerometer and gyroscope data, and carrier-network and latency patterns that are genuinely hard to fake. Some platforms cross-check sensor telemetry against UI gestures specifically to catch synthetic control; on a real device driven through the OS, that telemetry is authentic.

Human-like interaction by construction.

Because the agent acts through the device's normal input layer, its behavior sits much closer to a real user's than a script firing thousands of identical HTTP requests ever could.

By starting from a genuine device and a genuine interaction model, you're no longer fighting the entire browser-detection stack, you've largely stepped around it.

Essentially, the mobile approach shines anywhere the valuable data lives inside an app, or where the mobile app is simply less defended than the hardened website. Common examples:

Pricing and availability from travel, food-delivery, ride-hailing, or grocery apps whose sites are heavily protected but whose apps are the primary interface.
Listings data from marketplaces and real-estate apps.
Social and review data from platforms where much of the activity is mobile-first.
Any app with no public API at all, which is the majority of them, where the UI is the only way in.

Putting it together

If you're scraping a simple website, keep it simple: respect robots.txt, use the official API if one exists, limit how fast you send requests, vary your timing, and handle errors gracefully. That's enough for many websites.

If you're scraping a site with strong anti-bot protection, it's much harder. Modern websites check your network fingerprint, browser fingerprint, and behaviour to detect bots. Getting past all of that with headless browsers takes constant effort.

If the data is available in a mobile app, using a real phone can be a much easier approach. Platforms like Mobilerun let you automate real Android or iOS devices, so you avoid many of the browser-specific detection techniques. You're not pretending to be a real user, you're using a real device.

Doubao vs Mobilerun: Which is better?

Priya Negi — Mon, 20 Jul 2026 06:02:11 +0000

The race to build AI agents that can operate smartphones is accelerating. Instead of relying on APIs or app integrations, these agents interact with mobile apps the same way humans do like reading the screen, tapping buttons, typing text, and navigating multi-step workflows.

Two products taking very different approaches are ByteDance's Doubao AI Phone and Mobilerun, the mobile AI agent infrastructure developed by Droidrun.
While both aim to solve the same problem, they are designed for different audiences.

Doubao packages AI into a dedicated smartphone with a tightly integrated experience. Mobilerun provides the infrastructure that lets developers connect AI models to Android or iOS devices, whether those devices are physical phones or cloud phones.

We spent time testing both approaches across a series of real-world tasks to understand where each performs well and where each still struggles.

Two Different Answers to the Same Problem

Doubao and Mobilerun are both trying to answer a simple question: can an AI agent operate the apps on a phone the way a person does like reading the screen, tapping, typing, moving through multi-step tasks instead of relying on api endpoints which are not always available.
The difference lies in how they approach the problem:

Doubao solves it through the operating system. The AI is deeply integrated into a dedicated smartphone designed around an agent-first experience.

Mobilerun solves it through infrastructure. Rather than shipping a phone, it provides a platform that allows developers to connect AI models like Claude, Hermes, or OpenClaw to Android or iOS devices and automate mobile workflows.

Quick Feature Comparison

Feature	Doubao AI Phone	Mobilerun
Product Type	AI-powered smartphone	Mobile AI agent infrastructure
Hardware Required	Dedicated Doubao phone	Existing Android, iPhone, or cloud phone
Cloud Phone Support	No	Yes
Agent Support	Doubao ecosystem	OpenAI, Anthropic, Gemini, Ollama, DeepSeek, Hermes, OpenClaw, and others
Target Audience	Consumers	Developers & businesses
Human-in-the-loop	Yes	Yes
Cross-application Workflow	Yes	Yes
Setup Complexity	Easy	Medium
Scalable to Multiple Devices	No	Yes
Hardware	Nubia M153	Can operate most mobile devices
Background Task Execution	Yes	Limited to cloud phones

How Doubao Works

The first thing you notice on the Doubao AI Phone is its dedicated AI button. Press it and the assistant appears immediately, ready to execute the task. It opens apps, navigates interfaces, types text, and moves through multiple screens autonomously. The experience feels much closer to delegating work to an assistant.

How Mobilerun Works

Instead of requiring dedicated hardware, it connects AI models to existing mobile devices. Users can either:

connect their own Android or iPhone or Cloud phones for remote scalable automation, or
launch cloud phones for remote automation. The AI interacts with the device by observing the interface and performing actions on behalf of the user. Unlike consumer-focused assistants,Mobilerun is a infrastructure layer for mobile agents.

Let’s compare both Doubao and Mobilerun for a few tasks:

Ordering an Iced Americano: Doubao vs Mobilerun

On Doubao: We asked Doubao to order an iced Americano. The assistant opened the food delivery app, searched for coffee, compared prices, selected the lowest-priced option, and attempted to complete the order. During the process, it paused appropriately when clarification was needed.

The workflow completed successfully, although the entire process took close to three minutes. Overall, the experience felt similar to delegating the task to a junior assistant that occasionally asks follow-up questions before proceeding.

On Mobilerun: We repeated the same task using Mobilerun. The agent opened the delivery application, searched for an iced Americano, compared available options, selected one, and added it to the cart. Rather than automatically completing the purchase, it paused and asked whether the order should be placed or left in the cart.

This human-in-the-loop workflow provides an additional confirmation step before performing actions with financial consequences.

Task 2: Comment on a post

On Doubao: We asked the agent to post a comment under Instagram post, Doubao repeatedly typed and deleted text, then gave up, and simply couldn't identify the comment button. It's a small, telling failure: the agent handles familiar surfaces well, but a control it can't confidently locate stops it.

On Mobilerun. We then repeated the same task using Mobilerun. During our testing, the agent successfully navigated to the post, entered the requested comment, and submitted it.

One factor that likely contributed to this result is Mobilerun's ability to combine a11y tree information with computer vision when interpreting the interface, allowing it to identify actionable UI elements more reliably in many situations.

Task 3: Chat with a friend on Wechat

On Doubao: For our final test, we asked Doubao to open WeChat and send a message to a friend. During testing, the workflow did not complete successfully.

Public reports have noted compatibility challenges between the Doubao AI Phone and certain major Chinese applications, including WeChat, although the exact causes have not been fully disclosed publicly. Some applications reportedly blocked Doubao from automating tasks (due to security issues)

On Mobilerun: We repeated the same task using Mobilerun. This time, the agent understood the context, opened WeChat, and chatted with the friend. Again for this task, Mobilerun agent successfully executed the task, while Doubao struggled.

What these tasks reveal

Doubao is a genuine milestone: the first agent-led smartphone that is integrated into a user's device.

Unlike earlier swings such as the Rabbit R1, which stumbled on even its promised basics, Doubao completes real end-to-end workflows like ordering food, playing podcasts, navigating apps entirely through the agent, on a device you can buy today. But it runs those tasks as a self-contained device experience, and when it can't parse a UI element or hits an app's defenses, it stops. It works just well enough to prove an agent-first phone is possible, and fails just often enough to show how far the idea has to go. It is still a testing ground.

Mobilerun treats the same problem as a layer rather than a device. Because it's model-agnostic (OpenAI, Anthropic, Gemini, Ollama, DeepSeek) and runs on both Android and iOS, on personal phones or cloud phones, it isn't tied to one handset or one vendor's reasoning. The human-in-the-loop chat model means you stay in control of consequential actions like placing an order, making a payment etc. And the a11y + vision mode + better architecture is what lets it push through the exact UI moments, like finding a "Send" button, where Doubao agent gives up.

Doubao is a product you hold, Mobilerun is a infrastructure layer you operate with. But on the same tasks, they draw the two roads to the same destination: the phone as something you delegate to rather than operate.

Which one to choose?

If you're looking for a consumer-friendly AI phone that works out of the box, Doubao offers one of the most compelling implementations currently available.

If you're building AI agents, automating mobile workflows, or integrating smartphones into larger AI systems, Mobilerun provides considerably more flexibility and infrastructure.

Mobilerun vs DuoPlus: Which one to choose?

Priya Negi — Thu, 16 Jul 2026 07:44:42 +0000

Both Mobilerun and DuoPlus put mobile devices in the cloud and let you automate them and both can run many social media accounts at scale with automation. Let’s compare these two on different parameters.

Quick take

Mobilerun is an open-source, LLM-agnostic framework plus a managed cloud that lets AI agents drive real Android and iOS devices with natural language. It also provides cloud devices and real mobile devices in the cloud.
DuoPlus runs real ARM-based Android devices in the cloud, each in an isolated environment, so one person can operate many social media, e-commerce, or gaming accounts from a single computer without buying physical phones.

Side-by-Side Comparison: Mobilerun vs DuoPlus

Parameter	Mobilerun	DuoPlus
Core purpose	Give AI agents a phone; developer automation, social media automation, RPA, QA	Anti-detect cloud phone for multi-account social/e-commerce operations
OS support	Android and iOS	Android only
Automation approach	Natural-language LLM agent; deterministic replay scripts	RPA templates, custom workflows, Operation Sync, DUO+ AI Agent
LLM support	LLM-agnostic (OpenAI, Anthropic, Gemini, Ollama, DeepSeek, OpenRouter)	Proprietary AI templates / DUO+ AI Agent
Device technology	Cloud-hosted virtual phones + real physical hardware; residential proxy	Real ARM-chip Android devices in the cloud
Identity / stealth	Real-device identity, carrier-grade residential IPs, eSIM	Independent fingerprints, GPS + SIM data across 150+ countries
Scale model	Fleets from 1 to 10,000+ phones	Unlimited multiplicity
Developer tooling	Open-source framework, CLI, Python SDK, Docker, REST API, webhooks	REST API, ADB access, proxy management
Open source	Yes (MIT licensed)	No
SMS / numbers	Receives SMS on real devices and eSIM	No real SIM; uses "Cloud Number" add-on for SMS
Entry pricing	From $5/month (bring your own phone); $0.03/min pay-as-you-go	Cloud phone from ~$2/month

Platform support

Mobilerun controls both Android and iOS, and its cloud even offers real physical iPhones on custom hardware built for iOS stealth.
DuoPlus is Android-only. If iOS matters to you, DuoPlus is off the table today; if you specifically want the newest Android on real ARM silicon, DuoPlus is the stronger claim.

Automation approach

Mobilerun is built around LLM agents that read the screen (a11y trees plus screenshots), then tap, swipe, and type from a natural-language instruction. It's LLM-agnostic and supports a reasoning mode for complex multi-step tasks. Usefully, you can build a workflow with the agent and then replay it as a fast, deterministic script with no model in the loop.

DuoPlus approaches automation through RPA: pre-built templates and custom workflows, plus an Operation Sync feature that mirrors one action across many devices at once (like posting to dozens of accounts simultaneously).

Device technology and identity

Both Mobilerun and DuoPlus stress that their devices look like real phones to detection systems, but they get there differently.
DuoPlus runs virtual Android on authentic ARM chips deployed globally, and gives each instance an independent environment which means its own device parameters, GPS, and simulated SIM/base-station data across 150+ countries to reduce account association risk. There is basically no cap on how many devices you create or run.

Two constraints DuoPlus states plainly: each cloud phone requires a dedicated proxy IP, and there's no real SIM, so calls/SMS need the separate Cloud Number product.

Mobilerun offers a mix: cloud-hosted virtual phones, plus real physical hardware (including iPhones) for workflows that need the strongest device authenticity. It bundles carrier-grade residential proxies and real-device identity, and its real devices can receive SMS directly.

Access and developer tooling

DuoPlus is built for reach without setup friction: no client download is required, and you control your fleet from any PC or mobile browser. Under the hood it's a proprietary, closed platform, but it exposes a REST API, Android ADB access, and proxy management, with extensive API docs for phone control, automation, and team management.

Mobilerun’s core framework is open source under the MIT license. You can run it locally on your own machine and devices, then scale to the managed cloud with a config change.
The difference is: Mobilerun is code-first and inspectable; DuoPlus is a managed, browser-based dashboard product with an API attached.

Pricing

Mobilerun (per its pricing page): a dedicated cloud Android phone is $80/month ($768 billed yearly); a real physical iPhone is $200/month ($1,920 yearly); bring-your-own-phone is $5/month ($48 yearly). There's also pay-as-you-go cloud Android at $0.03/min with no commitment. Usage add-ons: cloud Android time $0.03/min, mobile premium proxy $10/GB, and agent step $0.01. Enterprise pricing (10,000+ concurrent phones, SOC2/SSO) is custom.

DuoPlus (per its help center and product pages): the cloud phone itself is around $2/month (cheaper in bulk), billed separately from "startup" time. You then pick a startup mode — Temporary Startup billed by the minute (its help center lists $0.06 per 10 minutes per device, capped at $1.2/day per device) or a flat-fee monthly Subscription Startup that allows unlimited startup during its validity. New users get 1 month of cloud phone plus 30 minutes of free startup time. (DuoPlus lists slightly different per-minute figures across pages, so check its live pricing page before buying.)

The main difference: DuoPlus is optimized for cheap, large fleets of Android instances you spin up and down; Mobilerun's per-device plans cost more but include the AI agent, stealth identity, proxy, and iOS.

Which should you choose?

Choose Mobilerun if you're building AI agents, want an open-source and LLM-agnostic framework, need iOS as well as Android, or want to prototype locally and scale to a managed cloud with the same code.
Choose DuoPlus if your job is running many Android social media or e-commerce accounts safely and cheaply at scale, you want a no-download browser dashboard with bulk operations, one-click reskin/sharing, and RPA templates, and you don't need iOS.

Both can run large fleets of social media accounts with automation, so this isn't an either/or on capability - it's a fit decision. Pick Mobilerun if you want AI-agent-driven automation, open-source flexibility, and cross-platform (iOS + Android) reach. Pick DuoPlus if you want a no-code, browser-based dashboard tuned specifically for scaling Android account operations.

Browseruse vs Mobilerun: Automation Model, Scaling and More

Priya Negi — Fri, 10 Jul 2026 04:57:02 +0000

At first glance, Browser Use and Mobilerun might seem like they solve the same problem. But they don't. Browser use gives your AI agent access to a browser, while Mobilerun gives it access to a mobile device. That distinction determines what your agent can actually automate.

What is Browser Use?

Browser Use is AI browser automation: you give an agent a natural-language task and it drives a real web browser to complete it. It comes in two forms. There's the open-source Python library (browser-use), which you run on your own machine and point at your own LLM provider, and there's Browser Use Cloud, a managed API that runs the same idea on hosted, stealth browser infrastructure so you don't manage anything yourself.
The pitch is that you send a task like "List the top 20 posts on Hacker News today with their points" and get structured results back. Under the hood the agent looks at the page, decides the next action, clicks, types, scrolls, and repeats until the task is done.

What Browser Use provides

Two modes: Agent and Browser. The Agent runs your natural-language task end to end and hands back a result. The Browser mode gives you a raw cloud browser over the Chrome DevTools Protocol (CDP) so your own code drives it. The infrastructure is the same infrastructure, but the control level is different.

Stealth browsers: The Cloud runs a forked Chromium built to get agents past bot detection and access sites that block ordinary automation.

CAPTCHA solving and residential proxies: You get proxies that span 195+ countries and are on by default, which helps sessions look like real regional users.

Framework compatibility: You can connect Playwright, Puppeteer, or Selenium to the hosted browsers over CDP, so existing scripts keep working.

Profiles and authentication: Persistent browser state lets an agent log in once and reuse that session. There's tooling for 2FA and for syncing local cookies up to the cloud.

Structured output: Get validated structured data back from a task instead of loose text.

Live preview, recording, and human-in-the-loop: Watch the agent's browser in real time, embed it in your own app, replay sessions, and hand control to a human mid-task for approvals, payments, or tricky auth.

Deterministic rerun: Run a task once, then re-execute the cached script for effectively $0 in LLM cost.

Integrations:An MCP server, n8n node, and webhooks make it easy to wire into agent stacks and existing workflows.

Why AI agents use it

For a browser-based agent, the browser is the "hands." An assistant researching a topic might be told "Go to Hacker News and pull today's top posts," let Browser Use launch a stealth Chromium, observe the page, decide the next action, click, and continue. The loop repeats until the task is done, and because it's real Chromium with real proxies, it can reach sites that reject naive scrapers.

How Browser Use differs from Mobilerun

The biggest distinction is the environment each one automates. Browser Use only ever sees what's inside a web browser. Mobilerun controls the whole mobile device.

Browser Use's view of the world

Browser Use runs Chromium locally or in the cloud which means it operates entirely within the browser. Browseruse agent can navigate, click buttons, fill forms, read page content, execute JavaScript, take screenshots, and upload or download files. What it cannot do is leave the browser: it can't install a native Android or iOS app, open WhatsApp, receive an SMS or push notification, grant OS-level permissions, toggle Wi-Fi, or open device Settings. All of that happens at the device/OS level, outside Chromium. For SMS- or app-based 2FA, the practical answer is a human in the loop or a stored credential/OTP, not the browser reading a text message itself.

Mobilerun's view of the world

Mobilerun runs AI agents that control real Android and iOS devices in its cloud or on your own hardware. The agent gets a natural-language goal like "open Settings and turn on dark mode" and taps, swipes, and types its way there. It controls the entire device: the home screen, Chrome, the Play Store, WhatsApp, Settings, Files, notifications, native apps, and system UI. It can install and uninstall apps, grant or revoke Android runtime permissions, read the accessibility UI tree, set GPS location, timezone, and locale, manage eSIMs and proxies, and even drive the device's own Chrome over CDP when a task does need the browser. An agent moves freely across all of it as part of a single workflow.

A concrete example

A workflow that crosses app boundaries shows the gap clearly:
_

Open Play Store → install an app → grant permissions → open Gmail → retrieve an OTP → switch back to the app → verify the account → enable notifications → parse the screen data.
_

Browser Use can't run this end to end, because most of it happens outside the browser. Mobilerun is designed exactly for it.
By contrast, a typical Browser Use agent stays entirely on the web: open LinkedIn, search for a company, extract employee names, and download a CSV.

A Mobilerun agent is device-first: install TikTok, create an account, receive an OTP, complete onboarding, upload a video, return to TikTok, and publish.

Underlying automation model

Browser Use operates through the browser. In Browser mode it exposes a raw browser over the Chrome DevTools Protocol (CDP), the same protocol Playwright, Puppeteer, and Selenium speak, giving access to the DOM, network events, and console logs. In Agent mode it wraps that in an AI loop.

Mobilerun operates at the mobile device level. Rather than being limited to a browser's DOM, it works from the device's a11y UI tree and screenshots across native apps, web views, and system screens, executing real taps with stealth mode that emulates human-like typing speed, jitter, and curved swipe paths.

Scaling

Both platforms are built for concurrency, but they scale different resources. Browser Use scales stealth browser sessions on managed cloud infrastructure. Mobilerun scales fleets of real or cloud-hosted mobile devices.

Open source and self-hosting

Both have an open-source core. Browser Use's library runs locally against your own LLM key, with the Cloud as the managed path to production. Mobilerun's framework runs the open-source mobilerun package on your own machine against your own Android device over adb, again with your own LLM key, while its Cloud offers hosted devices billed through credits. In both cases: run it yourself for control, or use the cloud to skip the infrastructure.

When to use which

Choose Browser Use when your workflow lives entirely on the web: large-scale scraping, browser-based AI agents, end-to-end web testing, form automation, data extraction, or any task that needs to reach protected sites and scale across many concurrent browser sessions.
Choose Mobilerun when you need to automate Android or iOS apps, your workflow crosses multiple apps, you need device features like notifications, permissions, GPS, SIM/eSIM, or file storage, or you're testing and operating mobile apps end to end.

Can they complement each other?

Yes. They're more complementary than competitive, unless the task is strictly browser automation. In some architectures they handle different parts of the same workflow. A core AI agent might use Browser Use to gather information from websites while Mobilerun handles the mobile portion: installing an app, signing in with an OTP, validating push notifications.
The takeaway is the one we started with. Browser Use gives your agent a browser; Mobilerun gives it a phone. Pick based on where the work actually happens.

How to Automate Apps With No API?

Priya Negi — Thu, 09 Jul 2026 09:01:18 +0000

I've hit this wall more times than I can count. I need to post to a creator account, verify an SMS code on a virtual phone, or stitch a mobile workflow into a backend pipeline. Then I go looking for the API and 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 I need :(

For a long time, the answer was "tough luck, scrape the UI." I think that answer is finally changing, because I think now the AI agents have gotten good enough to drive a phone the same way I would. This post is about how that actually works in practice.

Why so many apps don't have APIs

Let's talk about why this gap exists. Most consumer apps—banking, social, messaging, dating don't ship public APIs because their business model wants you to use the app not the web.

APIs introduce things they don't want like scraping, abuse, churn from third-party clients, and it creates regulatory headaches. Even when an API exists (eg. Instagram Graph, WhatsApp Business, the various fintech sandboxes), it's almost always a narrow slice of what the app itself can do.

So if I wanted to automate real-world consumer mobile flows, an API usually wouldn't work. I needed a different abstraction.

My old workaround, and why it kept breaking

In the past, I used UI automation frameworks like Appium, Espresso, XCUITest, and Selenium-for-mobile. The problem was they're brittle in exactly the way that matters. I'd write a script that taps a button at specific coordinates, and when the app ships a redesign, the selector moves, and my automation dies.

I spent a lot of time fixing selectors than actually shipping something. I added retries, then sleeps, then "wait for element," then a custom DOM diff tool, and eventually realized I'd built a small, sad browser inside my test harness.

The deeper issue is that these tools require me to describe the UI structurally, but apps don't actually have stable structure (iykyk). They have intent. When I look at a banking app, I don't think tap the third button in the second tab, I think open Payouts.

What changed now?

LLMs with vision finally made it cheap to do what I do naturally: look at a screen, decide what to tap, do it, look at the result, and repeat. Combine vision with the a11y tree the OS already exposes, and you have a model that can both see the pixels and read the semantic structure, which is much more robust imo. 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. That's the category Mobilerun works in.

But what is Mobilerun?

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.

It reads the screen via a11y plus a 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 my own code, and a hosted cloud if I don't want to babysit physical phones.

A few things make Mobilerun interesting if you're a developer evaluating this space:

Mobilerun is LLM-agnostic which means you can choose whichever LLM best fits your needs. The interesting part imo is that it works not only on emulators but also on real devices. That matters more than it sounds. Many apps like banking, dating, healthcare, anything with high security can sniff for emulator signals, missing SIMs, or suspicious network properties and quietly degrade.

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.

Where this actually paid off

A few workflows where this approach has beaten either an API integration or traditional UI tests for me:

End-to-end testing of my own app where flows change weekly and I'm tired of fixing selectors. I describe the test in English, and let the agent figure out the taps.
Account workflow automation at scale: scheduling posts, replying in DMs, managing creator inboxes across dozens of accounts. Long-lived, multi-profile sessions on real devices.
Turning a native app into a structured data pipeline. If the data lives only inside an app I don't own, an agent that reads the screen and returns JSON is a perfectly reasonable adapter and often the only one available.
Customer support: WhatsApp Business, Telegram, SMS. I drive them from a SIM that won't get blocked the way a third-party API gateway might.

What's the conclusion?

I don't think the no API problem is going away. If anything, it's getting worse as more value moves inside walled mobile apps. What's changed is that I no longer have to choose between a brittle XPath script and giving up.

Vision capable LLMs plus a properly engineered runtime (a stable a11y tree, a real device, structured output, and a planner that recovers from failure) make UI-driven automation actually production-grade for the first time.

If you want to try it, pip install mobilerun is the fastest path. The framework is open source, and the cloud is there when you outgrow your laptop.

I automated my iPhone using this AI agent

Priya Negi — Thu, 02 Jul 2026 12:31:26 +0000

I automated my iPhone using this AI

I've always envied Android people. Plug in a phone, run a couple of ADB commands, and you've got a bot tapping around your device in minutes. iOS never let me have that. Apple's sandboxing means there's no official way to remotely drive a physical iPhone — so for a long time, "automate my iPhone" just wasn't a sentence I could act on.

That changed when I found Mobilerun. It lets you connect your own iPhone to the cloud and hand it over to AI agents that tap, type, and navigate apps like a real person would, end to end. I decided to set it up on my own phone and see how far I could get. Here's how it went.

What I needed before starting

Before touching any code, I made sure I had:

A Mobilerun account with a Personal Phone subscription
A Mac with Xcode installed
My iPhone, connected via USB
An Apple ID with signing capability (a free personal team works fine)

One thing worth knowing upfront: with a free Apple ID, builds expire after 7 days, so you'll need to rebuild and re-trust periodically, and you can only sign for 3 devices at a time. A paid Apple Developer account ($99/year) removes both limits. I started with my free Apple ID just to test the waters.

How this actually works under the hood

Mobilerun controls the iPhone through WebDriverAgent (WDA), an open-source project that exposes input injection and screenshots on iOS. Mobilerun maintains its own fork of it, tuned for higher-quality streaming, lower-latency accessibility tree fetching, and faster touch input. The idea is simple: I build WDA onto my iPhone once with Xcode, and then a CLI tool called mobilerun-ios opens a WebSocket connection to Mobilerun's cloud and keeps my device online.

Once I understood that, the rest of the setup made a lot more sense. Here's exactly what I did.

Step 1: Turning on Developer Mode

Developer Mode is what lets Xcode install and launch development builds on the iPhone. I went to Settings → Privacy & Security → Developer Mode, toggled it on, and restarted the phone when prompted. After reboot, I confirmed the change and I was set.

One gotcha: if you don't see the Developer Mode entry at all, it's because your iPhone hasn't been connected to a Mac running Xcode yet. Plug it in, open Xcode once, and the option should appear.

Step 2: Configuring the iPhone to stay connected

A Personal Phone is meant to stay online for hours or even days, so I had to change three settings that make the difference between a connection that survives and one that needs constant babysitting.

First, I disabled Auto-Lock. If the iPhone locks, the screen goes black and the session drops offline — so I set Settings → Display & Brightness → Auto-Lock to Never.

Second, I turned on automatic time zone under Settings → General → Date & Time → Set Automatically. This keeps the device's time zone in sync with its simulated location; setting it manually just doesn't work on non-jailbroken devices.

Third — and this one I thought hard about — I removed the passcode. WDA's host session occasionally crashes or expires, and Mobilerun restarts it automatically, but only if there's no passcode in the way. Otherwise the relaunched session lands on the lock screen and just sits there until someone manually unlocks it. Since I wanted this phone to run unattended, I turned off the passcode under Settings → Face ID & Passcode → Turn Passcode Off.

I want to flag this clearly: removing the passcode disables Face ID, Apple Pay, and some iCloud features. I used a dedicated automation phone for this, not my daily driver, and I'd recommend the same to anyone trying this.

Step 3: Building and installing WebDriverAgent

This was, by far, the trickiest part of the whole process — and most connection problems I hit later traced straight back to signing or trust issues here. I took it slow.

I cloned Mobilerun's WDA fork:

git clone --branch v1.1.0 https://github.com/droidrun/WebDriverAgent

(The upstream Appium WebDriverAgent also works, but with higher latency and lower streaming FPS, so I stuck with Mobilerun's fork.)

Then I:

Opened WebDriverAgent.xcodeproj in Xcode
Selected my connected iPhone as the run destination
Chose the WebDriverAgentRunner scheme
For both the WebDriverAgentRunner and WebDriverAgentBroadcast targets, opened Signing & Capabilities, ticked Automatically manage signing, and picked my Apple ID / Team (WebDriverAgentBroadcast is the extension that enables high-FPS screen streaming — skipping it fails the build, so don't skip it)
Pressed Cmd+U to build-for-testing
On the iPhone, trusted the certificate under Settings → General → VPN & Device Management → tapped my team → Trust

I ran into both of the classic snags here. First, "Failed to register bundle identifier" — bundle IDs have to be unique per Apple ID, so I appended a suffix to the runner's ID (like com.facebook.WebDriverAgentRunner.) and mirrored it in the extension as com.facebook.WebDriverAgentRunner..xctrunner.broadcast. Second, "Could not launch WebDriverAgentRunner" on my first Cmd+U — this just meant the certificate wasn't trusted yet. I trusted it on the device and pressed Cmd+U again, and it went through.

Step 4: Installing the mobilerun-ios CLI

With WDA built, I installed the CLI. Homebrew was the easiest route for me:

brew install droidrun/tap/mobilerun-ios

There's also a curl install if you'd rather skip Homebrew:

curl -fsSL https://media.mobilerun.ai/releases/mobilerun-ios/install.sh | sh

I confirmed it installed correctly with:

mobilerun-ios --version

Step 5: Logging in

mobilerun-ios login

The CLI printed a short code and opened a verification page in my browser. I approved it there, then confirmed everything worked with mobilerun-ios whoami.

If you're setting this up in CI or a headless environment, you can skip the browser flow entirely and use an API key instead:

export MOBILERUN_IOS_TOKEN=dr_sk_your_api_key

Step 6: Connecting the iPhone

With my iPhone plugged in and unlocked, I listed available devices:

mobilerun-ios list

Which showed something like:

UDID                                      NAME             TYPE    OS     STATE    PORTAL
00008020-001A2B3C4D5E6F70                 My iPhone        real    18.2   ready    —

I copied the UDID and started the connection:

mobilerun-ios 00008020-001A2B3C4D5E6F70

Leaving the UDID off would connect every attached iPhone instead. The command keeps the device online for as long as it keeps running — Ctrl+C ends the session. For a setup I wanted to leave running in the background, I used the detach flag instead:

mobilerun-ios -d 00008020-001A2B3C4D5E6F70

This printed a PID and a log path, then exited cleanly. I could stop it later with mobilerun-ios stop.

Step 7: Running my first task

I opened the Devices page in the Mobilerun dashboard, and there it was — my iPhone, showing up as a connected Personal Phone. From there I went into the Playground, selected my device, and kicked off a task to confirm everything worked end to end. It did. My iPhone was now something an AI agent could actually drive, from anywhere.

Problems I hit (and how I fixed them)

A few things tripped me up along the way, so I'm listing them here in case they help:

WebDriverAgentRunner crashing on launch usually meant I needed to re-sign the runner target in Xcode and confirm the certificate was trusted before hitting Cmd+U again.

When mobilerun-ios list showed no devices, it was almost always one of three things: the cable was charge-only instead of a proper data cable, the iPhone was locked, or I hadn't accepted the "Trust This Computer" prompt.

Auth failures were solved by re-running mobilerun-ios login, or, for API keys, double-checking that MOBILERUN_IOS_TOKEN was actually exported in the same shell I was working in.

If the screen went black mid-session, it was Auto-Lock creeping back on — setting it back to Never fixed it every time.

And if the connection dropped after several hours and the device just sat on the lock screen, it meant the WDA session had restarted but a passcode was blocking it. Unlocking manually solved it in the moment; removing the passcode solved it for good on an unattended setup.

One more thing worth knowing: dumping TikTok's accessibility tree times out and crashes the automation session, so I've been avoiding TikTok tasks for now.

What I took away from this

Going from a stock iPhone to a cloud-connected automation device took Developer Mode, one Xcode build of WebDriverAgent, and a single CLI command. The Xcode signing step ate up the most time and patience, but it's a one-time cost — or a once-a-week one, if you're running on a free Apple ID like I was.

If you want to go deeper, Mobilerun's full documentation on connecting an iPhone is here: docs.mobilerun.ai/guides/connect-iphone

Browserbase vs Mobilerun :Detailed comparison

Priya Negi — Thu, 02 Jul 2026 11:43:04 +0000

If you're building AI agents or automation pipelines, you'll eventually hit a fork in the road: do you need to automate a browser, or do you need to automate a device? Browserbase and Mobilerun sit on opposite sides of that fork. The simplest way to hold the difference in your head is this: Browserbase gives an AI agent a browser. Mobilerun gives an AI agent an entire phone. That sounds like a small distinction, but architecturally the two are solving very different problems.

Here's how each works, where they shine, and how to choose.

What is Browserbase?

Browserbase is a complete platform for building and deploying agents that browse and interact with the web like humans. A single API key gives your agent six capabilities: cloud Browsers, Search, Fetch (page retrieval as clean markdown), Functions (deploy agents next to the browser), a Model Gateway (access major LLMs through one endpoint), and Agent Identity (getting past bot detection, CAPTCHAs, and auth walls). It's positioned as one platform replacing 5+ vendors, with one bill and one debugger.

What Browserbase provides

Cloud browsers. Every POST /session launches an isolated Chrome with a fresh profile and a remote debugging endpoint your automation connects to.

Session management. Each session has its own cookies, local storage, and IP. State can be reused across sessions via Contexts, or discarded.

Framework compatibility. Works with Playwright, Puppeteer, and Selenium with minimal code changes. Browserbase also makes its own AI-native SDK, Stagehand (natural-language selectors, self-healing actions), which it recommends as the default for agent workflows.

Recordings. Every session is automatically recorded (via rrweb) - clicks, navigation, console logs - invaluable for debugging agents.

Screenshots and artifacts. Stores screenshots, page HTML, and network logs to diagnose failures.

Proxy support. Configure residential or datacenter proxies per session without managing them yourself.

Parallel browsers. Need hundreds of Chrome instances? Create that many sessions through the API; Browserbase handles scheduling, infrastructure, cleanup, and lifecycle.

Observability. A Session Inspector / Live View layer lets you watch sessions in real time and replay them.

Why AI agents use it

For a browser-based agent, the browser is the "hands." An assistant booking a flight might prompt "Go to Expedia," let Browserbase launch Chrome, have Playwright execute actions, observe the page, decide the next action, click Search, and continue. The loop repeats until the task is done.

How Browserbase differs from Mobilerun

The biggest distinction is the environment each one automates. Browserbase only ever sees what's inside Chrome. Mobilerun controls the whole mobile device.

Browserbase's view of the world

Browserbase runs Chrome in the cloud, so it operates entirely within the browser: HTML, CSS, JavaScript, and the DOM. An agent can click buttons, fill forms, read page content, execute JavaScript, take screenshots, and upload or download files. It cannot install native apps, open WhatsApp, receive an SMS, grant Android permissions, toggle Wi-Fi, open device Settings, or test push notifications - all of that happens at the device/OS level, outside the browser. (For SMS-based 2FA, the workaround is a human in the loop via Session Live View, not Browserbase reading the text itself.)

Mobilerun’s view of the world

Mobilerun controls the entire device including the home screen, Chrome, the Play Store, WhatsApp, Settings, Camera, Files, notifications, native apps, and system UI. An agent can move freely between all of them as part of a single workflow.

A concrete example

A workflow that crosses app boundaries shows the gap clearly:

Open Play Store → Install an app → Grant permissions → Open Gmail → Retrieve OTP → Switch back to the app →Verify account → Enable notifications → Parse the screen data

Browserbase can't run this end to end, because much of it happens outside Chrome. Mobilerun is designed exactly for it.

By contrast, a typical Browserbase agent stays entirely inside Chrome, opens LinkedIn, searches for a company, extracts employee names, and downloads a CSV.

Mobilerun agent is device-first, installing TikTok, creating an account, receiving an OTP, complete onboarding, upload a video, switch to Photos, edit media, return to TikTok, and publish, spanning multiple apps.

Underlying automation model

Browserbase typically relies on browser automation protocols such as the Chrome DevTools Protocol (CDP), which expose the browser's internal structure i.e. DOM, network events, console logs.

Mobilerun operates at the mobile device level. Rather than being limited to a browser's DOM, it interacts with the rendered UI across native apps, web views, and system screens, letting an agent automate complete mobile experiences.

Scaling

Both platforms are built for many concurrent sessions, but they scale different resources. Browserbase scales hundreds or thousands of browser instances. Mobilerun scales fleets of real mobile devices or cloud-connected phones.

When to use which

Choose Browserbase when your workflow lives entirely in a web browser: large-scale web scraping, browser-based AI agents, end-to-end web testing, form automation, data extraction, or browser workflows that need to scale across many concurrent sessions.

Choose Mobilerun when you need to automate Android or iPhone apps, your workflow crosses multiple apps, you need device features like notifications, permissions, camera, or file storage, or you're testing and operating mobile apps end to end.

If your automation needs to touch native mobile apps, device settings, notifications, cameras, GPS, or other operating-system features, a mobile automation platform is the better fit.

Can they complement each other?

Yes. They're more complementary than competitive, unless the task is strictly browser automation. In some architectures they handle different parts of the same workflow. A backend AI agent might use Browserbase to gather information from websites while Mobilerun handles the mobile portion: installing an app, signing in with an OTP, validating push notifications, or completing an in-app purchase flow.

The takeaway is the one we started with. Browserbase gives your agent a browser; Mobilerun gives it a phone. Pick based on where the work actually happens.

BrowserStack vs Mobilerun

Priya Negi — Thu, 25 Jun 2026 06:29:08 +0000

At first glance, BrowserStack and Mobilerun can look like similar tools. Both run on real or virtual devices in the cloud, both interact with apps, and both promise to save time wasted on tedious manual work. But put them side by side and you can see they are quite different. One is built to test software. The other is built to operate it.

Here's a clear breakdown of what each does and when to reach for it.

What is BrowserStack?

BrowserStack is a cloud-based software testing platform that lets developers and QA teams test websites and mobile apps across thousands of real devices, browsers, and operating systems. Its core promise is simple: you no longer need to buy and maintain expensive in-house devices.

The platform's strengths lie mostly in quality assurance. Teams can instantly access a large cloud of real Android and iOS devices, along with desktop browsers, to verify that their applications behave correctly across different environments.

Developers can manually interact with apps to validate user experiences, while automated test suites built with tools such as Selenium, Playwright, Cypress, and Appium can be executed at scale. BrowserStack also provides visual testing, accessibility testing, performance testing, and integrations with CI/CD pipelines so issues can be caught before software reaches production.

In short, BrowserStack exists to find bugs, compatibility issues, performance bottlenecks, and accessibility problems before real users ever see them.

What is Mobilerun?

Mobilerun is built for AI-driven task execution and automation. Instead of testing an app's code, it gives an AI agent a virtual phone that it can use to open apps, understand what is happening on the screen, and carry out tasks the way a human would.

The key difference is how the work gets done. With Mobilerun, instead of writing scripts that define every action in advance, you describe the goal in plain English, invoke it through an API, or integrate it into a larger agent workflow. The AI then interprets the interface and determines what actions it needs to take in order to accomplish the objective.

This makes it suitable for operational workflows such as collecting data from mobile-only apps, managing social media accounts, monitoring marketplace listings, completing forms, onboarding customers, or carrying out repetitive tasks that span multiple applications. The goal is not to verify that software behaves correctly. The goal is to get useful work done.

Why not just automate the website?

A common question is why mobile automation is necessary when browser automation tools already exist.

The answer is that many modern businesses are increasingly mobile-first. Platforms such as Instagram, TikTok, ride-sharing apps, delivery apps, banking apps, and various marketplaces often release features in their mobile apps before making them available elsewhere. In some cases, the web version offers limited functionality, while in others there may be no public API available at all.

As a result, important workflows often exist exclusively inside mobile applications. Traditional browser automation excels when a workflow is available on a website, but it cannot always access mobile-only experiences. Mobilerun addresses this gap by allowing AI agents to operate directly inside mobile environments.

API Automation vs UI Automation

Traditional automation works best when software exposes APIs. APIs provide structured access to data and actions, making them highly reliable and efficient for developers.

The challenge is that many real-world workflows involve systems with incomplete APIs, restricted APIs, or no APIs at all. Sometimes the only way to perform a task is through the user interface itself.

Mobilerun approaches automation from the UI layer. Instead of requiring backend access, an AI agent can observe the screen, interpret the current state of the application, and interact with buttons, forms, menus, and other interface elements much like a human user would. This allows automation to be applied even in environments where traditional integrations are unavailable.

How the Two Differ

Core Purpose

BrowserStack is fundamentally a QA platform. Its purpose is to help engineering teams verify that software behaves correctly before release. Teams use it to identify bugs, validate compatibility across devices and browsers, test accessibility requirements, and ensure new code changes do not introduce regressions.

Mobilerun serves a different purpose. Rather than validating software, it uses the software as a real human would. It gives AI agents the ability to perform tasks within applications and complete workflows that would otherwise require human interaction.

How Automation is Driven

BrowserStack automation relies on predefined test scripts and element locators. Engineers explicitly define what actions should occur and what outcomes should be verified. While this approach is highly reliable for testing, changes to an application's structure, identifiers, or workflow often require updates to the automation scripts.

Mobilerun uses AI agents that combine vision, reasoning, and tool use. Instead of following a rigid sequence of instructions, the agent evaluates what it sees on the screen and decides what action should happen next. This allows it to adapt more naturally when interfaces evolve or workflows change.

Cross-App Capabilities

BrowserStack is designed to validate application behavior. While test automation can involve multiple browsers, devices, or applications, the objective remains verification and testing.

Mobilerun is designed around completing operational workflows. An agent can move between applications when necessary, carrying information from one app to another. For example, it could open a banking application, retrieve an OTP from a messaging app, return to the banking app, and complete the transaction. These types of workflows mirror how people actually use mobile devices in everyday operations.

Example: Booking a Hotel

A simple hotel-booking scenario highlights the distinction.

If you were using BrowserStack, the goal would be to verify that the hotel application works correctly. A QA engineer might test whether search results load properly, whether room listings appear as expected, whether forms accept input correctly, and whether checkout completes without errors. Success is measured by whether the application behaves as intended.

With Mobilerun, the QA engineer can do the same but in an automated way. Instead of testing the booking flow, an AI agent would use the application to accomplish a real outcome. It might search for hotels in Goa, compare available options, choose one based on specified criteria, and complete the booking process. Success is measured by whether the task gets completed.

The same application is involved in both scenarios, but the objective is fundamentally different.

Side-by-Side Comparison

Where Each Shines

BrowserStack is strongest when QA is the main direction. It provides broad device coverage, mature testing frameworks, visual regression testing, accessibility validation, and performance testing capabilities. For teams preparing software releases, these capabilities make it an essential part of the development lifecycle.

Mobilerun shines when the objective is automation rather than manual validation. It is particularly useful for mobile-first workflows, cross-app operations, app-based data collection, and AI agents that need to interact with applications as part of larger business processes. It enables automation in environments where traditional APIs or browser-based approaches are insufficient.

Neither platform is intended to replace the other. BrowserStack is not designed to run business operations, and Mobilerun is not designed to replace comprehensive and deterministic QA testing frameworks.

Can They Be Used Together?

In many organizations, the two tools could be complementary rather than competitive.

A development team might use BrowserStack before release to ensure an application works correctly across devices and operating systems. After the application is live, the same organization could use Mobilerun to automate workflows inside that application, allowing AI agents to perform operational tasks on behalf of users or internal teams. The same organisation can use automated AI workflows to test the app before every minor release or update assisting QA engineers.

One helps ensure the software is reliable. The other helps put the software to work.

Which One Do You Need?

Reach for BrowserStack when your goal is a traditional QA. If you are shipping a release and need to verify that your application behaves correctly across browsers, devices, and operating systems, BrowserStack is built for that purpose.

Reach for Mobilerun when your goal is getting work done inside applications or to create automatic QA flow that will assist your QA engineers in their work. If you want an AI agent to complete tasks, automate workflows, move across multiple apps, and operate within mobile-first environments, Mobilerun is the better fit.

How I build my first automation as a non-coder

Priya Negi — Wed, 01 Apr 2026 06:33:07 +0000

I'll be honest, when I first heard about mobile automation, I pictured lines of incomprehensible code scrolling down a black terminal screen. As someone who barely remembers high school algebra, the thought of programming anything made me want to close my laptop and pretend I never heard the word automation. Okay that was exaggerated.

But here's the thing, I like listening to people talking about automating this and that. I also wanted to try something. So I looked for some options, and that's when I discovered Droidrun.

The Problem with Traditional Automation

Most automation tools expect you to write code or scripts, understand programming logic, learn technical syntax and then debug when things break. Basically configuring at every single step.
( I don’t know these many things, I just asked LLM the problems with traditional automation)

For someone like me, this felt like being handed a spaceship manual when I just wanted to ride a bike or maybe a scooter.

Mobilerun: Automation for non-coders

Mobilerun is the cloud infrastructure of Droidrun, an AI-powered mobile automation framework. But here's the thing, you don't need to know what a framework is to use it.

Instead of writing code, you just describe what you want in plain English. The AI figures out how to do it. Simple.

Think of it like this:

You : Send a WhatsApp message saying hello to John
Mobilerun: Sends a message to John.

You don’t need to think about what happens in the backend, you just get a task executed as simple as that.

My First Automation

Let me walk you through exactly how I set up my first automation without coding anything.

What You'll Need

Before we start, here's what you need:

An Android phone (sorry iOS users, not yet!)
About 15 minutes
A Mobilerun account (free to start)

That's it. No programming knowledge needed.

Step 1: Get the Droidrun Portal APK

The Droidrun Portal APK is like a bridge between your phone and Mobilerun's AI. It allows the AI to see what's on your screen and interact with your apps.

Here's the complete setup guide for this : https://docs.droidrun.ai/guides/device-setup

Important: You'll need to enable "Install from Unknown Sources" in your Android settings. Don't worry, the Portal app is open-source and safe. It's like giving your trusted friend the remote control to help you with tasks.

Step 2: Set Up Portal Permissions

Once Portal is installed, open it. It will ask for a few permissions:

Accessibility Service: This lets the AI see what's on your screen and interact with buttons and text fields
Display Over Other Apps: This allows Portal to work in the background while you use other apps

These permissions sound scary, but they're necessary for automation to work. It's like giving someone permission to use your keyboard and mouse on your behalf.

Step 3: Connect to Mobilerun Cloud

Now comes the easy part:

Go to cloud.mobilerun.ai
Sign up for a free account (just email and password).
You'll land on your dashboard
Look for "Connect Device" or "Add Device"
On your phone's Portal app, you'll see a "Connect to Cloud" option
Scan the QR code shown on the Mobilerun website (or enter the code manually)

And that's it! Your phone is now connected. You'll see it appear as "Online" on your Mobilerun dashboard.

Note: Make sure to use the same email address to login to mobilerun and portal apk. Otherwise, you won’t be able to see the device in the cloud.

Step 4: Your First Automation

Here's where it gets fun. Let's start with something simple automatically saving Instagram posts you like.

On the Mobilerun dashboard:

In the playground, write the task in plain english. Something like, Open Instagram, go to my saved posts, and unsave them all.
Select the agent
Under devices, you can already see the connected device
Under advanced setting, choose the other relevant settings
and finally click on Run to start the automation

That's it. Now your mobile will automatically perform tasks specified by you.

What Can You Automate?

Once you've got the basics down, the possibilities are pretty wild. You can automate anything you do on your phone.

What I Learned

Building my first automation taught me something important: technology should work for you, not the other way around.

For years, I thought automation was only for programmers. I was wrong. The real barrier wasn't knowledge, it was that tools were built by developers for developers.

Mobilerun changes that. It's built for people who just want their phone to do things without becoming a software engineer in the process.

Final Thoughts

If you're also someone who wants to run automation or at least try it once, Droidrun is the tool you can use.

You don't need to learn to code.
You don't need to understand how AI works.
You just need 15 minutes and a willingness to try something new.

Happy Learning.

How I automated LinkedIn with my old phone

Priya Negi — Sun, 29 Mar 2026 06:31:26 +0000

We all have at least one old phone that nobody uses anymore. A Galaxy something or other with a cracked screen protector. A phone that still works fine but hasn't been charged for so many months now. They just sit there, slowly becoming e-waste. Until you turned one into your personal LinkedIn automation agent.

That’s right. Just an old Android phone and an AI that does all the clicking, scrolling, posting, commenting stuff for me.

Let me explain. If you've ever tried to automate LinkedIn, you know the deal. Chrome extensions that inject scripts into the page. Cloud tools that log into your account from some random IP in Virginia. Dedicated SaaS platforms charging $99/month to send connection requests. and LinkedIn's crackdown has only gotten worse. People are getting accounts restricted left and right. The problem isn't the automation itself but how most tools do it. They're all browser-based hacks pretending to be you, and anti-bot software has gotten scary good at spotting them.

So I asked myself what if the automation happened on an actual phone, doing actual taps, like an actual human?

Here's what I did. I grabbed my old Android device from the drawer, installed the Droidrun APK, and connected it to Mobilerun. That's it. That was the setup. Mobilerun is a platform that lets you automate real Android devices with plain English. You literally tell it what to do and it does it on a real phone, with real taps, real scrolls, real keystrokes.

I told it to open LinkedIn, go to my feed, and start engaging with posts. Liking. Commenting thoughtful responses (not those cliche Great post bots). Sending connection requests to people in my niche. Checking messages. And because it's happening on a real device with a real screen, LinkedIn sees exactly what it expects: someone using the app normally on their phone. Because that's literally what's happening. The AI is just the one holding the phone.

What I Actually Automated:

Here's my daily LinkedIn workflow that now runs without me touching anything:

Morning engagement round: The agent opens LinkedIn, scrolls through my feed, likes relevant posts, and leaves actual comments. Not generic ones contextual comments based on what the post is about.
Connection requests: Targeted outreach to people in my industry. The agent visits profiles, reads their bio, and sends personalized connection requests.
Message replies: It checks my LinkedIn inbox and drafts responses. I review the important ones, but for the, thanks for connecting messages it handles it all.
Content interaction: When I post something, the agent monitors engagement and responds to comments throughout the day.

All running on a phone that was of no use two weeks ago.

Watch it in action:

https://www.youtube.com/watch?v=LVx_jL8PT4o

Why This Approach is Different:

Most LinkedIn automation tools work at the API or browser level. They're essentially puppeteering a web session. LinkedIn knows(trust me, you are like this far from getting banned). They track browser fingerprints, unusual session patterns, and IP mismatches. But a real phone running the real LinkedIn app? That's just... a phone. The touch events are real. The screen renders are real. The network requests come from a normal mobile connection. There's nothing to detect because there's nothing fake. And here's the kicker if you don't even have an old phone lying around, Mobilerun offers cloud-hosted real Android devices. Same concept, but you skip the hardware entirely.

The Results:

After two weeks of running this:

Connection acceptance rate went up (personalized requests hit different)
My posts got more early engagement because the agent was actively engaging with others' content (LinkedIn's algorithm rewards that)
I reclaimed about 40 minutes per day I was spending on manual LinkedIn engagement
No account warning so far. Because it is an actual device working for me like a real person.

Should You Do This?

Look, I'm not telling you to go full bot-mode on LinkedIn. The platform has rules, and mass-spamming connection requests is still a terrible idea whether a human or an AI does it. But thoughtful, measured automation? Engaging with content you'd engage with anyway, just without spending an hour doing it manually? That's not gaming the system. That's just being efficient.

And if you've got an old phone sitting in a drawer doing nothing... well, now you know what to do with it.

I talk about AI agents and agentic AI.

Get in touch with me on LinkedIn.

Tasker Vs Droidrun: Rule based automation vs Agentic AI system

Priya Negi — Thu, 26 Mar 2026 06:02:51 +0000

Mobile automation has been around for quite some time with tools like Tasker and MacroDroid. But the landscape of Android automation has evolved dramatically over the past few years. In this blog, I will examine two distinct paradigms in mobile automation technology.

Tasker enables users to perform custom actions based on contexts such as time, location, application state, and events. The platform has continuously evolved to adapt with Android's changing ecosystem.

Droidrun, by contrast, launched in 2025 as an open-source mobile AI agent framework specifically designed to enable natural language control of Android and iOS devices. The framework represents a shift from programmed automation to agent-based control.

Tasker vs Droidrun: Approach

Tasker: Rule-Based Automation

Tasker works as a rule-based automation engine for Android. Users create profiles (trigger conditions) that activate tasks (sequences of actions). This model provides precise automation:

Profiles: Define when something should happen. It looks for contexts such as time-based triggers, location changes, application launches, system states, or custom events.

Tasks: Define what should happen when a profile is triggered for Eg. Modifying system settings, launching applications, manipulating files, sending network requests, or controlling hardware.

Apart from this Tasker supports variables, which makes it very flexible. It can also create custom interfaces like popups, buttons, menus etc.

This architecture grants users granular control over Android's operating system, without requiring root access for most operations. Users can also extend capabilities through JavaScript, shell scripts, and Java code execution.

Droidrun: Agent-Based Control

Droidrun uses large language models to understand and execute tasks written in natural language. Rather than pre-programmed rules, the system uses AI reasoning to complete objectives:

Natural Language Commands: Users describe what they want to achieve in natural language command.
UI Understanding: Vision models and accessibility tree parsing enable dynamic interface comprehension
Multi-Step Planning: LLMs decompose complex objectives into sequential actions
Cross-Application Workflows: Agents can navigate between applications to complete integrated tasks.

This removes the need to write code, letting you automate things just by texting. But it can sometimes behave unpredictably because it relies on AI-generated responses.

Feature Comparison

Dimension	Tasker	Droidrun
Core Approach	Rule-based (IF → THEN)	AI-driven (intent → execution)
Triggers	Built-in (time, app, events, system)	No native triggers (manual / external)
Actions	Predefined (400+ actions)	Decided dynamically by AI
UI Automation	Limited (via plugins)	Strong (native, vision-based)
Ease of Use	Hard to learn	Easy to use (after setup)
Setup	Simple	Complex (Python, ADB, APIs)
Execution	Deterministic (predictable)	Non-deterministic (can vary)
Speed	Fast (milliseconds)	Slower (seconds)
Adaptability	Low (breaks on UI change)	High (adapts to UI changes)
Platform	Android only	Android + iOS (limited)
Internet Needed	No	Yes (usually)
Privacy	Fully local	Cloud-dependent
Best For	System automation, routines	UI automation, complex workflows

Tasker and Droidrun address fundamentally different automation paradigms, making direct comparison challenging.

Criteria	Choose Tasker if you…	Choose Droidrun if you…
Automation Type	Need deterministic, repeatable automation	Need flexible, adaptive automation
Operation Mode	Prefer fully offline operation	Are okay with internet/API dependency
Control Level	Need precise system-level control	Need UI-level control across apps
Ease of Use	Can learn structured logic	Prefer natural language commands
Use Case	Automate device settings, routines	Automate app workflows, UI tasks
App Dependency	Work with system features/APIs	Work with apps without APIs
Adaptability	Can manually fix broken automations	Need automation that adapts automatically
Cost Preference	Want one-time cost	Okay with ongoing API costs
Platform	Only need Android	Need Android + iOS support

For many users, the tools are complementary rather than competitive. Tasker excels at system automation and trigger-based actions, while Droidrun addresses UI navigation and adaptive workflows. The optimal approach may involve both: Tasker for predictable system control, Droidrun for intelligent application interaction.

The broader question is rather more philosophical: Should mobile automation require users to program specific behaviors, or should AI agents interpret human intent? Tasker represents the former; Droidrun explores the latter. Both approaches have merit, and the mobile automation landscape is richer for their coexistence.

I talk about mobile app automation. Follow me on Linkedin.

Best Mobile AI Agents in 2026

Priya Negi — Mon, 16 Mar 2026 09:08:32 +0000

Stop me if you've heard this one: "AI agents are going to revolutionize how you use your phone!"

Yeah, I've been hearing that since 2024. And for two years, most of it was vaporware slick demos that fell apart the second you tried to do something real.

But 2026 is different. I'll give it that.

I've spent the last few weeks installing, configuring, cursing at, and occasionally being impressed by every mobile AI agent I could get my hands on. Some of these are legitimately game-changing. Others are polished marketing wrapped around mediocre tech. And a few surprised me in ways I didn't expect.

This isn't another top 10 best tools listicle.

This is what I actually found when I put these things to work. Lets dive into the Best Mobile AI Agents in 2026.

What are we even talking about?

A mobile AI agent is software that can:

Look at your phone screen
Understand what's happening
Take actions such as tapping, scrolling, typing

Just like you would.

The big leap in 2026 is that these agents don't just work inside one app anymore.

They work across apps, controlling the entire device.

THE ONES THAT ACTUALLY IMPRESSED ME

Droidrun: The Open-Source Framework That Punches Way Above Its Weight

I almost skipped Droidrun because open-source mobile agent framework sounds like something that'll eat my entire weekend just getting it to run.

I was wrong.

Droidrun is the foundation that serious developers are building on.

MIT-licensed
LLM-agnostic (plug in GPT-4, Claude, Gemini, whatever)
Handles device communication
Screen understanding
Action execution

While your model does the thinking.

What I love

You own the entire stack.

No vendor lock-in
No surprise pricing
Android support today
iOS planned for the future

I had a custom agent controlling my test device within an afternoon and this is why I have placed Droidrun at top in the Best Mobile AI Agents list.

The catch

A few months ago it required a bit more setup.

But when I checked again recently, they launched their cloud as well.

And honestly — even if you know nothing about coding, you can still set up automation in under 10 minutes.

Mobilerun — Droidrun's Cloud-Powered Big Sibling

If Droidrun is the engine, Mobilerun is the fully assembled car.

It gives you cloud-hosted real Android devices that you can automate using simple English instructions.

Let's be real — managing physical devices is a nightmare at scale:

Charging issues
OS updates breaking things
Devices going offline at 2 AM

Mobilerun tries to eliminate all of that.

The tech is still evolving, but it's clear where this is going.

My test

I connected my old Android device using the Droidrun APK and asked the agent to order a blueberry cheesecake on a food delivery app.

The interesting part:

This was done on a real device, not an emulator.

The platform is still young and evolving, but for teams building mobile automation at scale, this approach feels like the future.

THE BIG TECH HEAVYWEIGHTS

Google Gemini

Google replaced Assistant with Gemini, and the screen automation is impressive when it works.

I watched it complete a multi-step food order.

Then the next day it got confused by a slightly different menu layout.

That's Gemini in a nutshell:

Incredibly high ceiling
Frustratingly low floor

Still beta for a reason but still deserves a place in the list of Best Mobile AI Agents.

Apple Intelligence & Siri

Apple took the philosophical opposite approach.

It's privacy-first, and Private Cloud Compute is genuinely impressive engineering.

But as an autonomous agent, it's less capable.

Apple treats AI more like a background assistant than a fully autonomous actor.

If you want your phone to execute complex tasks on its own, Gemini is further along.

But a real agent ecosystem on iOS is still a work in progress.

Samsung Galaxy AI

The Galaxy S26 ships with Gemini integrated deeper than stock Android.

Some features are surprisingly good:

Live Translate during calls
Circle to Search

But there’s a catch:

Samsung hardware only
Feature fragmentation across models

So What Should You Actually Use?

If you are building mobile AI agents or automation

Droidrun → open-source, full control
Mobilerun → cloud devices, less infrastructure headache

If you want a smarter phone

Gemini → Android
Apple Intelligence → iPhone
Samsung Galaxy AI → Samsung devices

These technologies are genuinely changing how we interact with our phones.

And honestly, it's about time.

The future of headless apps is not very far.

I talk about Mobile AI Agents and Browser AI Agents.

If you're building in this space, feel free to connect with me on LinkedIn.