DEV Community: Priya Negi

I tried automating 5 apps using mobilerun ai, here's what happened.

Priya Negi — Wed, 09 Sep 2026 11:28:34 +0000

Most mobile apps were never built with AI agents in mind. They use different navigation patterns, they interrupt you with permission dialogs and promotional pop ups, they hide the thing you want behind a login screen, and they each have their own way of doing what is essentially the same task. A tool that works beautifully on one app tends to fall apart on the next one.

So I wanted to find out how far a general purpose mobile agent could actually get. I gave Mobilerun a single challenge, which was to automate five completely different apps using nothing but natural language instructions.

I picked LinkedIn, Instagram, Amazon, TikTok and WhatsApp. There was no custom flow written for each app, no hardcoded screen coordinates, and no selectors. I described the outcome I wanted and let the agent work out how to get there.

Here is how each one went.

LinkedIn, where the agent has to make a judgment call

LinkedIn was the first test, and it turned out to be the most demanding one for a reason I did not expect.

The instruction was straightforward. I asked the agent to open LinkedIn, search for a specific topic, work through the posts it found, and interact with the profiles that were relevant. What makes this harder than it sounds is that the agent cannot succeed by tapping a fixed sequence of buttons. It has to open the app, locate the search field, enter the query, move into the results, and then decide which of those results actually match what I asked for before it does anything.

That decision is the interesting part. Everything up to it is navigation, which any automation tool can handle if you write enough selectors. Deciding whether a particular profile fits a description you gave in plain English is a different kind of problem, and it is the one that separates telling an agent what you want from telling a script where to click.

Instagram, where the target is never in the same place

Instagram is a different environment entirely, and it exposes a different weakness in traditional automation.

I asked the agent to search for content and interact with the relevant result. On LinkedIn, results arrive in a reasonably predictable list. On Instagram, what you get back is a grid of images with very little text to anchor to, and the thing you are looking for could be in any position depending on what the algorithm decides to show you that day.

A script that depends on selectors or a predefined path has nothing stable to hold onto here. An agent that reads the screen and reasons about what it is seeing has a much better time of it, because it is working from what is actually in front of it rather than from what somebody assumed would be there when they wrote the automation.

Amazon, where the goal is fixed and the path is not

Amazon was the clearest illustration of the whole idea.

The instruction was simple. I asked the agent to open Amazon and find a particular product. It opened the app, ran the search, moved through the results and interacted with the product page.

What makes Amazon a good test is how much of it changes between runs. Search results reorder themselves. Sponsored listings appear and disappear. Recommendation carousels shuffle. Promotional banners drop in without warning. Run the same script twice and the second run lands somewhere completely different from the first.

The goal, though, stays exactly the same throughout. You still want that product page. This is the situation where an agent earns its keep, because it is solving for the destination rather than following a route that stopped being accurate the moment the page loaded.

TikTok, where there is barely any interface to navigate

TikTok breaks most of the assumptions that the other four apps share.

There is no menu structure to speak of and no results page in the conventional sense. There is a feed, it plays automatically, and you move through it by swiping rather than tapping. The content is video, which means the information the agent needs is changing continuously rather than sitting still on a static page.

I asked the agent to navigate TikTok and complete a simple task related to the content it found. What I wanted to know was whether an approach built around reading screens and choosing actions could cope with an interface that has almost no structure to read.

This is also the point where the value of a single interaction model becomes obvious. Automating these five apps the traditional way would mean learning several different frameworks and maintaining separate flows for each one. Describing the objective and letting the agent find its own way through does not care that TikTok looks nothing like Amazon.

WhatsApp, the simplest interface and the most useful result

WhatsApp has the most straightforward interface of the five, and it is also the one where automation feels immediately practical rather than merely impressive.

I gave the agent a messaging task. Rather than opening the app myself, finding the contact, opening the conversation and typing, I described the outcome I wanted and let it handle the steps. Something along the lines of opening WhatsApp, finding a specific contact, and sending a particular message.

The reason this one matters more than the others is that it is the end of a workflow rather than a demonstration on its own. Consider what happens when you connect it to everything upstream. You find your leads, you write a message personalised to each one, the agent opens WhatsApp and sends it, and the result gets recorded so you know what went out and to whom. The mobile agent stops being a novelty at that point and becomes the execution layer for work you were already doing by hand.

What I actually took away from it

The takeaway wasn’t that an AI agent can open five apps. That’s easy, and nobody should be impressed by it.

What stood out was that the same interaction model worked across five completely different interfaces. LinkedIn doesn’t work like Amazon. Amazon doesn’t work like TikTok. Yet the approach stayed the same: I gave the agent a goal, it read the screen, figured out what to do, and executed it.

That’s a meaningful shift from traditional mobile automation, where you have to define every tap, swipe, and input—and hope the interface never changes.

The difference is simple: automating clicks vs. automating outcomes.

Mobile automation is becoming less about controlling an interface and more about giving it a goal.

A note on limits

Two things are worth saying plainly, because a post like this is easy to write as though nothing ever goes wrong.

The first is that agents fail, and they fail in ways scripts do not. A script that breaks usually breaks loudly and stops. An agent that misreads a screen will keep going and do something slightly wrong instead, which is harder to notice. Anything you automate at volume needs a way to check the result rather than assuming it worked.

The second is that several of these apps restrict automated access in their terms of service, and WhatsApp in particular enforces this aggressively against accounts that behave mechanically. This is worth understanding before you build anything that runs continuously. Keeping volumes modest and behaviour realistic matters more than squeezing out throughput.

Best way to automate Instagram DMs for small businesses

Priya Negi — Mon, 07 Sep 2026 09:35:44 +0000

If you run a small business on Instagram, your DMs are probably where most of your money actually happens. Product questions, price checks, order follow-ups, "is this still available?" it all lands in one inbox that never stops. And unlike a big brand, you don't have a social media team. You are the social media team.

So the appeal of automating Instagram DMs is obvious. The problem is that Instagram automation is a minefield, and most of the advice online skips straight past the part where accounts get restricted or banned. This post covers the honest version: what the limitations really are, what a safer approach looks like, and how tools like Mobilerun let you automate

DMs on a real phone either a cloud phone or your own personal device, with a human still in control.

Why DMs Are Worth Automating in the First Place
A few realities of small-business Instagram:

Response speed directly affects sales. A customer who DMs three boutiques about the same product usually buys from the one that answers first. If you reply six hours later, that sale is often gone.

Most DMs are repetitive. Pricing, shipping, availability, store hours, "do you deliver to X?" the same five to ten questions make up the bulk of any small business inbox. That's exactly the kind of work automation is good at.

And the inbox never sleeps, but you do. Messages arrive at midnight, on weekends, during the school run. Without some form of automation, "fast replies" means being glued to your phone.

The Limitations Nobody Tells You About

Before picking any tool, you need to understand why Instagram automation is genuinely hard. This is the part most vendor blogs gloss over.

The official API is restrictive Meta does offer an official Messaging API for Instagram, but it comes with real constraints. You need a professional (business or creator) account, apps generally have to go through Meta's review process, and there are strict rules around when you can message people for example, businesses can typically only respond within a limited window after a customer messages first. You can't use the official API to send cold outreach at scale, and that's by design.

For a small business without a developer, building on the official API usually means paying a monthly SaaS subscription for a chatbot platform and even then, you're limited to comment-triggered replies and inbound-message flows.

Third-party bots get accounts banned The other end of the spectrum is the classic "Instagram bot", browser scripts and emulator farms that are mass-DM, auto-follow, and auto-like. Instagram has spent years building detection for exactly this. Automation that runs from datacenter IPs, emulators, or unofficial API endpoints tends to trip signals like impossible activity patterns, mismatched device fingerprints, and suspicious network origins. The result is action blocks, shadow restrictions, forced password resets, or permanent bans.

For a small business, your Instagram account often is the business. Losing it to a $20/month bot is not a trade worth making.

Rate limits and behavioral signals
Even legitimate automation has to respect how a real person behaves. Instagram watches for message velocity, repeated identical text, and sudden spikes in activity from an account that was quiet yesterday. Any automation that ignores this official or not creates risk.
Automation can hurt your brand
A subtler limitation: customers can smell canned bot replies. If every DM gets an instant, generic response and follow-up questions go nowhere, you've automated your way into worse customer service. Good DM automation should draft and triage, not blast.

The takeaway: the question isn't just "how do I automate DMs?" It's "how do I automate DMs in a way that looks and behaves like a human on a real phone, keeps me in the loop, and doesn't put my account at risk?"

A Different Approach: Automation on a Real Phone

This is where Mobilerun takes a fundamentally different angle. Instead of hitting Instagram through browser scripts or reverse-engineered APIs, Mobilerun gives an AI agent an actual phone real hardware, running the real Instagram app and the agent operates it the way a person would: opening the app, reading the screen, tapping, and typing.

For Instagram DMs specifically, the Mobilerun Instagram agent can:

Read and triage your inbox: sorting new DMs by intent (order question, complaint, price check, spam) so you see what matters first.
Draft replies in your voice: the agent prepares responses, and nothing is sent without your approval, so you keep control of tone and timing.
Handle publishing and analytics too: the same agent can publish approved posts and Reels and pull reach and engagement numbers, so DM automation slots into a broader workflow.
The key design choice is human in the loop. The agent does the reading, sorting, and drafting the tedious 80% while you do the approving. That's what separates "automation that helps" from "automation that spams."

Under the hood, Mobilerun is built on an open-source framework (GitHub) that scores state-of-the-art results on public mobile-agent benchmarks, and it works with whatever LLM you prefer. But as a business owner, you don't need to touch code you can hand tasks to the hosted assistant in plain English from the Mobilerun Cloud dashboard.

Two Ways to Run It: Cloud Phone or Your Own Device

Mobilerun gives you two setup paths, and the right one depends on how you work.

Option 1: A cloud phone
You rent a real phone that lives in Mobilerun's infrastructure. You log in to Instagram on it once, and from then on your agent operates that device 24/7, you access everything from your browser via cloud.mobilerun.ai.

This suits you if:

You want the automation running around the clock without draining or occupying your own phone.
You manage a separate business account (or several) and want each on its own clean device.
You want to start in minutes with zero hardware setup.
Each rented phone comes with a dedicated residential IP through Mobilerun Connect, a stable address that stays with your device, matched to its country, timezone, language, and GPS. In other words, the cloud phone looks to Instagram like exactly what it is: one consistent phone, in one place, used by one account.

Option 2: Connect your personal device
Alternatively, you can connect your own Android phone the one already logged in to your Instagram and let the agent work on it directly. Mobilerun's framework is open source and installed with a couple of commands; the docs walk through both the local-device and cloud paths.

This suits you if:

Your business account lives on your personal phone and you don't want to move it.
You want to physically watch what the agent does, at least at first.
You prefer a free, open-source starting point before paying for cloud devices.
Many small businesses actually do both: prototype on their own phone, then move to a cloud phone once they trust the workflow.

Why This Is Safer: Especially the Personal-Phone Angle

"Safe" in Instagram automation means two things: safe for your account, and safe for your credentials. Here's why the real-phone approach holds up on both and why the personal-device option is arguably the most conservative way to start.

Real device identity, not a fake one. Instagram's detection is largely about spotting things that aren't phone emulators, datacenter servers, headless browsers. Mobilerun's devices are genuine hardware running genuine app builds, compatible with integrity checks like Play Integrity and App Attest. Your activity reads as what it is: a person's phone.
On your personal phone, nothing about your footprint changes. This is the part worth underlining. When the agent runs on your own device, the DM replies come from the same phone, same Instagram session, same home Wi-Fi or mobile network, and same location that Instagram has associated with your account since day one. There's no new login, no unfamiliar device alert, no IP jump to another country the classic triggers for security checks simply don't occur. From Instagram's perspective, you answered your DMs, because in a real sense, you did: from your phone, with your approval on every send.
You never hand your password to a third-party web app. With typical DM tools, you type your Instagram credentials into someone else's website and hope for the best. Here, the login happens inside the Instagram app on a device you control your own phone, or a cloud phone only you access.
Human approval is built in, not bolted on. Because the agent drafts and you approve, message velocity stays human, replies stay personal, and you can't accidentally mass-send something regrettable at 3 a.m.
The core is open source. The framework behind Mobilerun is public code with an active community. You (or anyone technical you trust) can see exactly what runs on your device a level of transparency closed-source bot tools can't offer.
Consistent, verifiable networking on cloud phones. If you go the cloud route, the dedicated residential IP that ships with each phone means your device isn't sharing a recycled proxy pool with a thousand spammers. Historically one of the fastest ways automation tools got accounts flagged.

No tool can make Instagram automation entirely risk-free, and no vendor should claim otherwise. Instagram's terms still apply to what you do, not just how you do it. Blasting cold DMs to strangers is against the rules whether a human or an agent types them. The safe lane is the one Mobilerun's workflow is built around: your own accounts, inbound conversations, human-approved sends, and human-scale pacing. Start slowly, keep volumes reasonable, and treat automation as an assistant not a growth hack.

How to Automate Snapchat Using Your Personal Mobile

Priya Negi — Thu, 27 Aug 2026 06:00:12 +0000

Automating Snapchat means using an AI agent to handle repetitive tasks like uploading content, posting, replying to messages, or checking your account.

You can do this directly from your own Android phone using mobilerun AI. The agent interacts with Snapchat by tapping, swiping, and typing on your phone, just like a person would.

Since Snapchat does not provide a public API for many of these actions, using an agent that operates the app directly is one way to automate them.

Here’s how to set it up step by step.

How this works (tl;dr)

mobilerun drives a real phone. To let it drive your phone, you install a small companion app called the mobilerun Portal on your device. The Portal is what lets mobilerun see the screen and perform taps and swipes. Once your phone is connected to your mobilerun account in the cloud, you just chat with the agent in plain English, tell it what to do on Snapchat, and it does it. You can even schedule it to run on its own every day.

No rooting, no coding, no reverse-engineering Snapchat. The agent uses the app like you would.

Step 1: Download the mobilerun Portal APK

The Portal app is open source and available on GitHub. On your phone's browser, go to the droidrun/mobilerun-portal repository:

go to github.com/droidrun/mobilerun
Head to the Releases section and download the latest APK file directly onto your phone.

Because this is installed outside the Play Store, Android will ask you to allow installs from your browser (or file manager). Go into the prompt or into Settings → Apps → Special access → Install unknown apps, enable it for the app you're downloading with, then open the APK and tap Install.

Step 2: Grant the Portal its permissions

When you first open the mobilerun Portal, it will ask for a couple of permissions it needs to actually operate your phone most importantly Accessibility access, and usually the ability to draw over other apps.

This is the part that lets the agent "see" the screen and tap the right buttons, so it's essential. Follow the in-app prompts, flip the toggles on in Android's settings when asked, and come back to the Portal. It'll confirm once everything it needs is enabled.

Step 3: Connect your phone to your mobilerun cloud account

Now link the device to your account so you can send it commands from anywhere.

Create or sign in to your mobilerun account (at cloud.mobilerun.ai).
In the Portal app, connect/pair the device with your account typically by signing in or entering the pairing details the dashboard gives you.
Once paired, your personal phone shows up as a connected device in your mobile run dashboard. That's it, your phone is now a device the agent can control, while it stays in your hand or on your desk.

Step 4: Make sure Snapchat is ready

Since the agent uses the real app, just make sure Snapchat is installed and logged in on your phone with the account you want to automate. Whatever the agent needs to reach, the camera, your friends list, your streaks should be a normal, logged-in Snapchat session. The agent will navigate it exactly as you do.

Step 5: Give the agent a command in plain English

With everything connected, you don't script anything. You open the mobilerun agent and describe what you want, the way you'd text an assistant.

For example, to keep streaks alive:

"Open Snapchat, go to my Chats, and send a snap to everyone I currently have a streak with. Use the front camera, take a quick photo, and send it to all my streak friends."

Or to post a story:

"Open Snapchat, take a photo with the rear camera, add the caption 'Open today till 9pm', and post it to My Story."

The agent reads the screen, opens Snapchat, and works through the steps like opening the camera, capturing, selecting recipients, and sending, tapping and swiping like a real user.

Because you're chatting with it, you can refine as you go: change the caption, tell it to only snap specific friends, or have it confirm with you before posting publicly.

Step 6: Put it on a schedule (the cron job)

The real payoff is not running it manually, it's letting it run itself. Ask the agent to set up a cron job, a recurring schedule, so your Snapchat task fires automatically at the time you want. For daily streaks, you might say:

"Every day at 9 AM, run my Snapchat streak task and send a snap to all my streak friends."

Pick whatever cadence suits you like once a day for streaks, a few times a day for stories, whatever your goal is. From then on the agent wakes up on schedule, opens Snapchat on your phone, does the job, and stops. Your streaks stay alive even on the days you forget.

A note on the first run vs. later runs

Expect the first run to be a little slower and to use more credits. The initial time, the agent is working the task out from scratch where the camera button is, how the send-to screen is laid out, which friends count as streaks.

After that, it gets efficient. Once it's figured the task out, mobilerun stores the skill, so future runs just replay a routine it already knows instead of solving it fresh each time. The upfront run is the investment; the daily runs after that are quick and cheap.

A few practical tips

Keep the phone charged and online if you're relying on scheduled runs, it's still a real device doing real work. Automate responsibly and within Snapchat's terms; think of this as saving yourself the repetitive taps, not spamming. And start simple: get one task (like streaks) working reliably before layering on stories, replies, or more complex flows.

Putting it together

Automating Snapchat on your own phone comes down to a short setup: grab the mobilerun Portal APK from the GitHub releases page, install it and grant Accessibility permission, connect the phone to your mobilerun cloud account, make sure Snapchat is logged in, then tell the agent in plain English what to do and schedule it with a cron job. The first run teaches the agent the task; every run after that, it quietly keeps your snaps going, streaks intact, stories posted because it's using Snapchat exactly the way you would.

How to setup auto reply automation on whatsapp for your business

Priya Negi — Thu, 27 Aug 2026 05:44:24 +0000

For many small businesses, WhatsApp is the sales desk, support channel, and enquiry inbox. Customers use it to ask about prices, availability, bookings, products, and delivery.

The WhatsApp Business app has made this the default way millions of small shops, salons, tutors, clinics, and home businesses actually get customers.

But there's a catch that quietly costs you money every day: slow replies.

Why slow replies lose you customers

When someone messages a business on WhatsApp, they're usually deciding right now. They've messaged you and probably two of your competitors. Whoever replies first, with the answer they need, tends to win the sale. A gap of even 15–20 minutes is often enough for the customer to have already booked elsewhere, gotten distracted, or cooled off.

The problem is you can't sit on WhatsApp all day. You're serving walk-ins, on a call, cooking, driving, or asleep. So enquiries pile up, and by the time you reply, some of them are already gone. If your business genuinely runs on WhatsApp, this isn't a small leak, it's your biggest one.

If that sounds like you, it's time to automate the replying. Here's how to set it up with mobilerun AI.

1. Get a phone for the automation

You can use either:

An old or spare Android phone
A mobilerun cloud phone
We'll use a cloud phone here.

Go to mobilerun Cloud and set up a device. Think of it as a new Android phone: sign in with a Google account, open the Play Store, and install WhatsApp or WhatsApp Business. Then set up WhatsApp with your business number as you normally would.

2. Tell the agent what to do

Once WhatsApp is ready, open mobilerun VA and describe the workflow in plain English.

For example:

"Check WhatsApp for new customer messages. Answer questions about pricing, availability and business hours using the information provided. If you don't know the answer, tell the customer that a team member will get back to them."

You can make the instructions as specific as your business requires. For example, you can tell the agent to collect a customer's preferred booking date, answer FAQs, share product information, or escalate conversations that require a human. The agent operates WhatsApp directly on the device, navigating chats, reading messages and sending replies.

3. Schedule automatic checks

You don't need to manually start the agent every time. Ask it to create a recurring task:

"Check WhatsApp every 10 minutes for new customer messages and respond according to the workflow."

You can choose whatever interval works for your business. The workflow becomes:

Check WhatsApp → Read new messages → Understand the enquiry → Reply → Repeat

What happens after the first run?

The initial run can take more time and credits because the agent has to work through the task and establish the workflow. Once the required skill has been stored, subsequent runs can be much more straightforward because the agent can reuse that skill instead of figuring out the workflow from scratch each time

What about the WhatsApp Business API?

The WhatsApp Business API is still a good option for businesses that need high-volume messaging, backend integrations, CRM workflows, and structured notifications. But it works differently from mobile automation.

WhatsApp Business API	Mobilerun + WhatsApp
Communicates through an API	Operates the WhatsApp app
Built for programmatic messaging	Works through the mobile UI
Requires API/integration setup	Runs on a cloud or Android device
Best suited to structured workflows	Useful for flexible app-based workflows
Complex workflows may require backend development	Workflows can be described in plain English

mobilerun takes the opposite approach: it uses WhatsApp as a real person would. There's no template approval, no 24-hour rule to design around, and no separate messaging pipe, the agent is literally operating the app on a real phone. It reads chats, types replies, sends media, checks statuses, and navigates the interface the same way your thumb does. Because of that, pretty much anything a human can do inside WhatsApp, the agent can do too, which is a much bigger surface than "send and receive text through an API."

The trade-off is honest: the API is built for massive, high-volume programmatic sending, and at that scale it shines. But for a small business that just wants fast, natural, human-like replies to real customer enquiries without template gatekeeping or messaging-window rules, driving the actual app is often the simpler and more flexible fit.

Keep humans in the loop

Automation doesn't have to handle every conversation. A practical setup is:

Agent: FAQs, pricing, availability, basic enquiries, information collection.

Human: Complaints, negotiations, complex questions, sensitive issues, and final decisions.

This lets the agent handle repetitive enquiries while your team focuses on conversations that actually need human input.

Putting it together

If WhatsApp is where your business gets its customers, you shouldn't have to constantly watch the inbox to respond quickly. With a cloud phone, WhatsApp, and mobilerun, you can create an auto-reply workflow in plain English and schedule it to run automatically.

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.