# https://tunnels.io/use-cases/mobile-testing

[Home](https://tunnels.io/) / [Use cases](https://tunnels.io/use-cases) / Mobile testing

Use case

# Put your local API on a real phone, anywhere.

A tunnel gives the port on your development machine a public HTTPS address, so any handset with a data connection can call your API. No shared wifi, no LAN address, no deploy. It works the same for a tester three time zones away as for the phone on your desk.

[Get started free →](https://tunnels.io/get-started) [See pricing](https://tunnels.io/pricing)

## Which devices can actually reach your machine?

Mobile testing is a routing problem in disguise. The question is whether the handset holding the build has any path to the machine running your API. On a network you do not administer, it has none.

| Where the device is | What it can reach | What breaks without a public URL | What tunnels.io gives it |
| --- | --- | --- | --- |
| A QA tester in another country | The public internet only | No address to give them; every fix needs a staging deploy | An HTTPS hostname that answers from anywhere |
| A device on a mobile network | The carrier's network and the internet | Your private address means nothing out there | The same hostname on cellular as on wifi |
| A client's own phone | The internet, plus their own office network | You cannot install anything on their device | A link, with a certificate their phone trusts |
| A cloud device farm | The internet, from the farm's data centre | The runner has no route to your desk | A reserved subdomain the farm keeps between runs |
| A tablet on a guest network | The internet; isolation blocks other devices | Same SSID, still no route | Outbound traffic only, so isolation stops mattering |
| A handset at a trade stand | Whatever the venue hands out | No control over DNS, ports or firewall rules | An outbound connection on 443, which venues allow |

Every row wants the same two things: a name that resolves on the public internet, and a certificate the device already trusts.

## Why does a debug build need a stable base URL?

Mobile builds carry their configuration inside them. The API base URL is chosen at build time and compiled into the artifact. Changing it is not editing a config file, it is producing and distributing a new build.

That is cheap while the phone is on your desk. It stops being cheap once the artifact is on someone else's device, because a tester cannot re-point a build.

The free plan issues a random 16-character subdomain on `tunnels.host` and reassigns it when the client restarts: fine for a session you are watching, wrong for a value compiled into a binary.

```
# the same name back, every session
$ tunnels --subdomain acme-dev http 3000
Active Tunnels:
▸ https://acme-dev.tunnels.host → http://localhost:3000  [https]
```

Reserved names start on Professional. Our guide to [reserved subdomains](https://tunnels.io/learn/what-is-a-reserved-subdomain) covers how the lease works.

## Testing over a mobile network, not your wifi

Cellular is the honest case, because nothing local can rescue it. The handset is not on your subnet, not on your SSID, and not reachable by any address you could type. A public hostname is the only thing that works, and it keeps working on every network the device meets later: a hotel, a guest VLAN, a carrier behind its own address translation.

A mobile network also shows what a desk network hides. Round trips get longer and less even, connections drop, and your retry logic finally gets exercised. The client runs a request inspector on `127.0.0.1:4040` listing every call with its method, path, status and duration, so you read what the phone sent rather than what you assumed. If the link drops, the client reconnects on a backoff with jitter.

## How do you hand a build to someone who is not a developer?

Give them two things: the build, and a URL. No VPN client, no profile to install, no certificate to trust, and no instruction beginning with "open a terminal". The moment a test plan needs software on their device, you have added a support job.

A tunnel URL is an ordinary HTTPS address with a certificate their phone already trusts. The risk worth naming is that the address is public: anyone holding the link can reach it. If the build touches data you would rather not expose, put basic auth in front of the tunnel with `--httpauth user:pass`, enforced at our edge.

There is no OAuth sign-in at the edge and no IP allowlisting, so basic auth plus an unguessable hostname is the whole access story. If you want your own devices on a private network instead, see [how we compare with Tailscale](https://tunnels.io/compare/tailscale).

## What does a real handset show that a virtual one does not?

A virtual device borrows your machine's network stack. It cannot prove a request survives a carrier's address translation, a corporate proxy or a captive portal, because it has never met one.

### The platform is real

Background work killed while the screen is off, push tokens from a real registration, and biometrics.

### The network is real

A resolver you did not choose, a proxy nobody mentioned, and a connection that changes mid-session.

### The timing is real

Slower, less even round trips turn a race condition into a reproducible bug and test your timeouts.

None of this argues against virtual devices; they are faster, and most of a suite should stay on them. It argues for making sure a physical handset can reach your API on demand. Addressing for virtual devices is covered separately in [pointing an emulator at your machine](https://tunnels.io/learn/how-to-test-a-mobile-app-against-localhost).

## Which plan you need

Start free. Pay when a machine, rather than a person, has to remember your URL.

Basic, free

$0

One HTTPS tunnel, 4 GB a month, 1,024 requests a second. The hostname is 16 random characters and changes when the client restarts.

Professional

$4 /mo, or $40/yr

Three reserved subdomains, four concurrent HTTPS tunnels, 128 GB a month, 8,192 requests a second, raw TCP. The reserved name is what keeps a baked-in base URL working tomorrow.

Gold

$10 /mo, or $96/yr

Custom domains of your own, with certificates issued through Cloudflare for SaaS after a CNAME.

Students verify a school email and get 8 GB a month and 2,048 requests a second free. [Pricing](https://tunnels.io/pricing) is the authoritative list.

## What this does not do

- HTTPS and raw TCP only. UDP is not supported, so an app with a UDP media path cannot be tested through a tunnel. There is no SMTP tunnel type, though SMTP is TCP and rides a raw TCP tunnel like any other TCP service. Neither either.
- Raw TCP starts on Professional at $4 a month. The free plan cannot open a TCP tunnel, so a device pointed at a local database needs a paid plan.
- TLS is terminated at our edge. The public leg negotiates TLS 1.3 where the device supports it, and TLS 1.2 at minimum. See [HTTP vs HTTPS tunnels](https://tunnels.io/learn/http-vs-https-tunnels).
- No IP allowlisting, no OAuth at the edge, no request replay. Basic auth is the access control on offer, and the inspector shows traffic rather than resending it.
- It is not a device farm and it does not distribute builds. It gives a device you already have a route to your machine.

## Related reading

[Pointing an emulator at your machine The virtual-device side of the job, and which address a hosted device uses to find the machine under it.](https://tunnels.io/learn/how-to-test-a-mobile-app-against-localhost) [What is a reserved subdomain? Why a name that changes on every restart breaks anything holding your URL, including a shipped build.](https://tunnels.io/learn/what-is-a-reserved-subdomain) [HTTP vs HTTPS tunnels Where TLS is terminated, and why a mobile platform refuses a plain HTTP endpoint.](https://tunnels.io/learn/http-vs-https-tunnels)

Neighbouring use cases: [receiving webhooks](https://tunnels.io/use-cases/webhooks) and [CI and CD pipelines](https://tunnels.io/use-cases/ci-cd). Also [tunnels.io vs Tailscale](https://tunnels.io/compare/tailscale), [pricing](https://tunnels.io/pricing), and more in [Learn](https://tunnels.io/learn).

## Questions

### Can a tester in another country use my local API?

Yes. Run the client on your machine, send them the HTTPS hostname it prints, and build that hostname into the artifact they install. Their requests reach our edge and travel down the connection your machine holds open. Nothing is deployed.

### Does the phone have to be on the same wifi as my machine?

No, and that is the point of a public hostname. The device only needs to reach the internet. Office wifi with client isolation, a guest VLAN and a mobile connection behave the same way, because the request goes to our edge, not your subnet.

### Will the URL still be the same after I restart the client?

Only on a paid plan. Basic and Student get a random 16-character subdomain that is reassigned on restart, so a build compiled against yesterday's name fails today. Professional at $4 a month includes three reserved subdomains, which return the same hostname every session.

### Can a cloud device farm reach a tunnel?

Yes, as long as the farm's devices have ordinary outbound internet access. Give the tunnel a reserved subdomain so the farm's configuration keeps the hostname between runs, and start the client before the run begins.

### How do I stop strangers reaching a test build?

Start the tunnel with the httpauth flag and a user and password of your choosing; our edge challenges every request before it reaches your machine. There is no IP allowlisting and no OAuth login, so for anything stronger, put the check in your application.

## Put it on a real device today.

The free plan is enough to point a handset at your machine and watch the requests arrive. Move to Professional at $4 a month when the hostname has to stay put.

[Get started free →](https://tunnels.io/get-started) [See plans and limits](https://tunnels.io/pricing)