Ruby Native vs an agent-written Hotwire Native app

A coding agent can hand you a working Hotwire Native shell in an afternoon. That is true, and for the teams described on the Hotwire Native page it is a fine first draft. What the afternoon does not include is the next five years. Ruby Native is priced against those.

#What the afternoon gets you

Two projects, one in Swift and one in Kotlin, that load your site in a web view with native navigation. If the agent read the Hotwire Native docs it will have a path configuration, a tab bar or a single navigator, and maybe a bridge component for a button. It runs on the simulator. It may well run on your phone.

Then it is yours. Specifically:

• Certificates and profiles, which expire, and a signing setup that works on one Mac until it does not.
• App Store review. Guideline 4.2 rejects a "repackaged website", and a bare shell is exactly that. The native tab bar, push notifications, and app assets that get a Ruby Native app through are work the agent did not do.
• The yearly deadlines. Apple sets a spring deadline for the SDK your app must be built with, Google sets an August deadline for the Android version it must target, and each OS release changes something in between.
• Two languages nobody on the team reads. Every fix is a trip into Xcode and Android Studio.
• The edge cases, which you find after your users do.

#The changelog is the evidence

The Ruby Native changelog is the running list of what an agent-written shell would ship with until someone found it. A few entries from this year:

• Inputs stayed hidden under the keyboard on Android devices whose WebView predates version 139.
• A native OAuth sign-in could land in the wrong app, because the cookie that routes the flow back outlived the sign-in and a stale one from another app on the same domain hijacked the redirect.
• Android apps stopped responding after the system reclaimed them in the background, leaving every page unable to submit a form until the app was force quit.
• Tab badge counts on iOS 26 were drawn on screen but invisible to VoiceOver.
• When iOS 26 shipped Liquid Glass, tab bars and the floating action button got the new look with the next build.

Each of those was fixed once, for every app, and picked up by the next build. In your own shell, each one is a developer's day after your users' complaints.

#Where the agent-written shell is the right call

• You want to own the native layer and have someone to maintain it. Then you want Hotwire Native, and an agent is a reasonable way to write the first draft.
• It is a prototype, to see your site in a tab bar before deciding anything. Ruby Native's preview does this too: ruby_native preview puts your app on your phone with no account.
• You are a mobile developer and the shell is the part you enjoy.

#Where Ruby Native is the right call

• You want the app to exist, in both stores, kept current, without a native codebase on your roadmap.
• The afternoon was never the expensive part. AI moved the cost of the first build to nearly nothing and left the cost of the fifth year where it was.
• You want the parts no agent-written shell includes: cloud builds signed with your certificate, the listing as a file in your repo, screenshots, TestFlight, submission, and review from someone who has been through it 30+ times. Your agent can drive all of it through the MCP server, and status tells it which steps Apple and Google keep for a person.

#Side by side

If you change your mind later, in either direction: the source you download from Ruby Native is a normal Xcode and Android Studio project, and an agent-written shell is replaced by the gem and the generator in a day.

The business comparison, against hiring a mobile team, an agency, or a React Native rebuild, is on Why Ruby Native. Try the demo app on your phone from /try, or email Joe at [email protected] with your app's URL.