Start shipping →

Answers · Mobile

Do I need to rebuild a Hotwire Native app to change a screen?

No. The screens are your web views, served from your Rails app, so a deploy changes what users see on their next launch with no build and no App Store review. Even navigation rules are served, from /configurations/:platform. A new binary is only needed for the icon, native capabilities, or the shell itself.

Updated · 2 min read

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.

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.

Related questions

Can I put a Rails app in the App Store and Play Store?

Yes. Hotwire Native wraps your existing web views in a native shell, so the screens you already built are the screens in the app. One Shot ships both shells in mobile/ios and mobile/android. The rule you cannot route around is that digital subscriptions have to use the platform's in-app purchase, not Stripe.

How do I change which screens open as modals in the native app?

Edit the path configuration your server returns at /configurations/:platform. The shells fetch it at launch, so changing which URLs open as modals, which replace the current screen and which are handled natively is a deploy, not a new binary and not a review.

How do I keep a web app and its native shells consistent?

Keep the shells thin and let the server decide. Screens, navigation rules and feature gates all come from Rails, so they stay consistent by construction. The only things that should live in mobile/ios and mobile/android are the icon, the purchase sheet and anything the web genuinely cannot do.