The Multi-Account Handbook · Chapter 03
Cloud Phones and Mobile Identities
Why app-first platforms need a phone and not a browser, how cloud phones compare with emulators and handsets, and when each tool is the right one.
- Why apps see more than browsers
- Cloud phone, emulator or handset
- Metered running time as a model
- Choosing phone or browser profile
6 min read · page 16 of the PDF
A retail brand's regional TikTok account is created on a phone, posts from a phone and goes live from a phone. A desktop browser profile can sign in, but the desktop site does not offer everything the app does. Accounts that live in an app are better served by something that is actually a phone.
Why a phone is not a small browser
A web page runs inside a sandbox. It can ask the browser a fixed set of questions and nothing more. An app is installed on the device and sits much closer to it.
Depending on the permissions the operating system grants, an app can read things a page cannot:
- The device brand, model and Android version.
- Device and advertising identifiers that persist between sessions.
- Carrier and SIM details, and whether the connection is mobile data or Wi-Fi.
- Sensor readings, battery state and GPS location.
- Whether the device and the app pass integrity checks, such as Google's Play Integrity.
A browser profile can present a mobile user agent and a phone-sized screen. That produces the mobile website, not the app. For platforms that put their main features in the app, the difference is practical before it is technical. Live streaming, some seller tools and some messaging features may exist only there.
History matters too. An account that has only ever appeared from a phone has a pattern. A sudden move to a desktop browser is a change in that pattern, and changes invite verification prompts.
Cloud phone, emulator or real handset
There are three ways to give an account a phone. A small agency often starts with a drawer of handsets and stops when the drawer is full.
| Option | What it is | Works well for | Main drawback |
|---|---|---|---|
| Real handset | A physical phone on a desk | A few high-value accounts | Does not scale; handover means posting a parcel |
| Emulator | Android simulated on a desktop computer | App testing and development | Apps can often tell it is not a phone |
| Cloud phone | An Android device hosted by a vendor | Many app accounts shared by a team | Ongoing fees and trust in the vendor |
An emulator is built for developers. It typically runs on desktop hardware, lacks real sensors and carries build details that mark it as an emulator. That is fine for checking a layout. It is a weak home for a long-lived client account.
A cloud phone is an Android environment that runs on a vendor's servers and streams its screen to the operator. Taps and typing travel back the other way. Vendors differ in the hardware underneath and in how complete the device looks to an app. Those are questions for the vendor's documentation and for a trial.
Three tools in the ProxyLook directory illustrate the range. DuoPlus offers Android cloud phones only, opened from a browser tab. GeeLark offers Android cloud phones plus browser profiles. Multilogin offers browser profiles plus Android cloud phones.
What a cloud phone identity includes
A cloud phone is the mobile version of a browser profile. It bundles a device description, stored app data and a network exit into one identity. The typical contents are:
- Device description. Brand, model, Android version and screen size.
- Identifiers. The device and advertising IDs that apps read.
- Carrier and SIM details. The network operator and country the device reports.
- Location settings. GPS position, timezone and system language.
- Apps and their data. Installed apps, logins and caches.
- Network. The proxy the phone sends its traffic through.
Which of these can be set, and which are fixed, depends on the vendor. The rule from chapter 2 carries over unchanged. The values must agree with each other, and they must stay the same for the life of the account. A phone reporting a French carrier, a Texas GPS position and a Tokyo timezone contradicts itself three times.
How the traffic flows
Two separate connections are in play. Mixing them up causes most setup mistakes.
The first connection is the screen stream between the operator and the vendor. The platform never sees it. An operator can work from the office, from home or from a train, and the app's view does not change.
The second connection is the app's own traffic. It leaves the cloud phone and should pass through a proxy assigned to that phone. Without one, the traffic exits from the vendor's own network. A phone that claims a mobile carrier but connects from a hosting network breaks the consistency rule at layer one.
A mobile proxy is the natural match, because phones normally connect through carriers. A residential IP also fits, since phones spend much of the day on home Wi-Fi. Chapter 4 covers the choice. Either way, the phone's GPS position, timezone and language should follow the proxy's location.
Metered running time
Browser profiles are usually sold by the number of profiles. Cloud phones often add a second meter: time. The vendor charges for the minutes a phone is switched on. GeeLark meters running time. DuoPlus charges a per-device fee plus metered running time.
The model rewards short, deliberate sessions. Consider two accounts. One needs twenty minutes a day to post and answer comments. The other hosts a three-hour live stream twice a week. Under a time meter, the second uses roughly three times the running time of the first, on identical phones.
Three habits keep the bill predictable.
- Shut each phone down when the session ends. A phone left running overnight is billed overnight.
- Estimate before buying: phones, multiplied by minutes per day, multiplied by working days.
- Review usage monthly and retire phones for accounts that are no longer managed.
Rates change often and are not printed here. Current figures are on each tool's page in the antidetect browser directory.
Cloud phone or browser profile
The choice follows the platform and the task, not the tool's popularity. A browser profile is usually cheaper to run and quicker to work in. A cloud phone is the better fit only where the app is the real product.
| If… | Then… |
|---|---|
| The platform works fully in a desktop browser | A browser profile is enough |
| The account was created in the app and lives there | Use a cloud phone |
| A needed feature exists only in the app | Use a cloud phone |
| QA needs to check a mobile web page | A browser profile with a mobile setup will do |
| QA needs to see in-app ads in another country | Use a cloud phone with a proxy there |
| A client has both web and app accounts | Use both, under one record per account |
A cloud phone changes the device layer and nothing else. Behavior, payment details and content still link accounts, exactly as in chapter 1. App-first platforms also tend to have strict account rules. Running multiple accounts can breach their terms of service, and the operator carries that risk. A cloud phone does not make an account immune to restriction.
Key takeaways
- Apps can read device details that web pages cannot, so app-first accounts need a phone identity.
- Emulators suit testing, handsets suit a few accounts, and cloud phones suit teams with many.
- A cloud phone bundles device details, identifiers, location settings, app data and a proxy.
- App traffic leaves from the cloud phone through its proxy, never from the operator's own connection.
- Metered running time rewards short sessions and switching phones off afterward.
- A browser profile is enough unless the account or the feature lives in the app.
Prefer the designed PDF? The Multi-Account Handbook is 43 pages, free, with no sign-up.
Download the PDF