## What the shell is

A small native project that hosts a web view and adds native navigation, so pushes and modals behave
the way a phone user expects rather than like page loads. Your Rails app serves the same HTML it
serves a browser.

```bash
bin/dev
open mobile/ios
```

The shells are checked into the repository. Point one at your app's URL, build it, and you have an
app on a simulator.

## What you get for free

Every screen you already have. A feature you ship on the web is in the app on the next launch, with
no build and no review, because the content comes from your server. That is the whole argument for
this approach and it is a large one.

Navigation rules come from the server too, at `/configurations/:platform`, so you can change how a
screen behaves natively without shipping a new binary.

## What is genuinely native work

- The app icon, launch screen and store listing.
- Signing, provisioning and the submission process.
- In-app purchase, which has to be native because the platforms require it.
- Anything using a device capability the web cannot reach.

## The payment rule

Apple and Google both require that digital goods and subscriptions sold inside the app use their
purchase system, which takes a commission. Linking out to a Stripe checkout to avoid it is the most
common rejection reason for apps of this shape.

One Shot handles this with marker paths the shells intercept. `config/routes.rb` declares them under
the `iap` namespace, and a native receipt posts back to the server to activate entitlement. So the
same `Subscription` row backs both a web purchase and an App Store one.

## Where it stops being the right approach

If your app is mostly camera, maps, offline storage or background location, the shell is a wrapper
around the wrong thing. Hotwire Native suits apps that are mostly screens and forms, which is most
business software.