## What a deploy changes

Everything that is HTML. New pages, changed forms, fixed copy, a whole new feature. The app fetches
it from your server like a browser would, so the release cadence of your app becomes the release
cadence of your website.

For a small team this is the entire value of the approach. A bug fix that would otherwise be a build,
a submission and a wait is a deploy.

## Navigation rules are served too

```bash
bin/rails routes | grep configurations
```

`/configurations/:platform` returns the path configuration: which URLs open as modals, which replace
the current screen, which are handled natively. The shells fetch it at launch, so changing how a
screen behaves is a server change.

That is also where the in-app purchase marker paths are declared as native, which is what makes the
purchase sheet appear instead of a web page.

## What still needs a build

- App icon, name and launch screen.
- Permissions and native capabilities.
- The shell's own source in `mobile/ios` or `mobile/android`.
- Anything the store shows in the listing.

In practice that is a handful of releases a year rather than one per feature.

## The caching caveat

Users do not get changes mid-session. The web view holds what it loaded, so a change lands on the
next navigation or the next launch. For an urgent fix that is minutes, not the days a review takes,
but it is not instant.

## Do not let it drift into a rule you cannot keep

The temptation is to put things in the shell because it is faster to write Swift or Kotlin for one
screen. Every screen that moves native is a screen that needs a release to change, and the ratio
creeps. Keep the shell thin and the value stays.

## Test the web views at phone width

The app is a phone-sized web view, so the page frame has to work there. The layout collapses to a
flex stack under 900px, which is defined in `app/assets/stylesheets/03-layout.css`, and a screen that
only works on a laptop looks broken in the app before anyone notices on the web.