Answers
Shipping the same app to the App Store and Play Store, and the rules you cannot route around.
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.
Inside the app, yes, for anything digital your users consume in the app. Apple takes 15 to 30 percent and rejects apps that link out to an external checkout for it. On the web, in a browser, you keep using Stripe. The same account can be entitled by either path.
Practically, yes. Xcode runs only on macOS and it is what archives, signs and uploads an iOS build. Cloud macOS runners and rented Macs work and add cost and latency. Android has no equivalent constraint: the Android shell builds on Linux, macOS or Windows.
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.
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.
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.
The icon is an asset catalog entry in the shell project and the display name is a value in its configuration, both under mobile/ios or mobile/android. Unlike your screens, these are compiled in, so changing either needs a new build and a new submission. Set them before your first upload.
Generate an upload key, build a signed Android App Bundle from mobile/android, and upload it in the Play Console. Google signs the delivered app with its own key, so your upload key is recoverable if lost. Budget most of the time for the store listing and the data safety form, not the build.
Use the hotwire_native_app? helper in app/controllers/application_controller.rb. The shells append "Hotwire Native" to the user agent, and the helper reads it. That check is how you show the native purchase trigger in the app and the Stripe button on the web, which the store rules require you to get right.
Change the URL in the shell to your machine's LAN address, such as http://192.168.1.20:3000. An iOS simulator can reach localhost but a physical device cannot, because localhost on the phone is the phone. Both platforms also block plain HTTP by default, so development needs an explicit exception.
The app completes the purchase natively, then posts the receipt to /iap/purchase. Your server verifies it with Apple or Google through the store adapters and calls the same Subscription.activate! a Stripe checkout would. One entitlement row, two possible ways of paying for it.
Fifteen percent for developers under the small business thresholds on both platforms, thirty percent above them. Apple's programme applies under one million dollars a year; Google's reduced rate applies to the first million. Neither is automatic: you apply. Stripe's fee on the web is under three percent, which is the comparison that matters for pricing.
Two reasons account for most rejections of apps like this. Linking out to Stripe or any external checkout for digital goods, which the guidelines prohibit. And minimum functionality: an app that reviewers judge to be a website in a wrapper with nothing native about the experience. Both are avoidable before you submit.
Apple sends a server notification to the endpoint you registered, and your app updates the local Subscription row so entitlement ends at the period they paid for. If that endpoint is not wired, the cancellation happens entirely on Apple's side and your app keeps granting access forever, with nothing reporting it.
Google refuses OAuth inside embedded web views and returns a disallowed-user-agent error. The flow has to leave the web view and run in the system browser, then return to the app. That is a shell behavior, not a Rails change, and it is why the magic-code sign-in is the primary path in the native apps.