## Find the address and bind to it

```bash
ipconfig getifaddr en0
bin/rails server -b 0.0.0.0
```

The bind flag is the step people miss. By default Rails listens on loopback only, so the phone's
request never arrives even with the right address. `bin/dev` runs the same server, and the same flag
applies.

## The two platform rules

**iOS** blocks non-HTTPS requests under App Transport Security. The simulator is more permissive than
a device, which is why a build that works in the simulator fails on a phone.

**Android** blocks cleartext traffic by default from API 28 onward, with a similar result.

Both need a development-only exception in the shell's configuration, under `mobile/ios` or
`mobile/android` depending on the platform. Add it deliberately and remove it before you submit, because shipping an app that permits cleartext is both a security problem and
something review may flag.

## The alternative that avoids all of it

Run a tunnel and use HTTPS:

```bash
bin/dev
```

Then expose it with whichever tunnel you use and point the shell at the public HTTPS URL. No
transport exceptions, no LAN addressing, and it works from a device on cellular. Worth it if you test
on hardware often.

## Same network, actually

Phone and laptop on the same Wi-Fi, and a network that does not isolate clients. Guest networks
frequently do, and the symptom is a request that simply times out with nothing in the Rails log.
Nothing in the Rails log means the request never arrived, which is a network problem rather than an
app problem.

## Remember APP_HOST

Mailers and canonical URLs read `Rails.application.config.x.app_host` rather than the request. On a
LAN address they will point somewhere the phone cannot follow, which is fine for development and
worth knowing when a sign-in link in the app does not work.