Tools: Rails on iOS/Android: Can You Build a "Real" App with Hotwire Native?

The "Mobile App" Dread ## The Mental Model: It’s Not a Wrapper ## The "Yes": Why it is Production Ready ## 1. Strada is the Glue ## 2. The "Update" Loop ## 3. HEY and Basecamp Proved It ## The "No": Where it Falls Short ## 1. The Offline Problem ## 2. You Still Need to Know Native Code ## 3. The "Uncanny Valley" of UIs ## The Verdict: Who is it for? ## Summary You’ve built a beautiful Rails SaaS. You have users. You have revenue. Then comes the inevitable email: "Do you have an iOS app?" For a solo developer or small team, this is a nightmare scenario. You have three bad options: But there is a fourth option: Hotwire Native (formerly Turbo Native). It promises the Holy Grail: Use your existing Rails views to power a native iOS/Android app. But is it actually "production grade"? Or is it just a glorified web browser? The biggest misconception is that Hotwire Native is a "WebView Wrapper" like PhoneGap or Cordova from 2012. It is not. In a Hotwire Native app, the Navigation Stack is native. This subtle difference tricks the brain. Because the navigation transitions are native (the "swish" effect on iOS), users perceive the app as high-quality, even if the button they are clicking is technically HTML/CSS. In 2026, the ecosystem has finally matured. Here is why you can bet your business on it. For years, the missing link was Strada. We needed a way for the HTML to "talk" to the Native code easily. Example: You want a native "Save" button in the top right corner of the iPhone screen, but the form is in your Rails view. Strada reads this tag, tells the iOS code "Hey, render a native Save button," and when the user taps it, it submits the HTML form. It feels magical. If you build a React Native app, fixing a typo requires a new App Store submission (24-48 hours review). With Hotwire Native, you deploy your Rails app, and every user has the update instantly. For a "One Person Team," this velocity is your competitive advantage. You maintain one codebase. We aren't guessing if this scales. HEY (the email service) runs on this stack. It feels native. It is fast. It handles complex interactions. If it’s good enough for a premium consumer email client, it is good enough for your B2B dashboard. However, if you blindly jump in, you will get hurt. Hotwire Native is NOT for every app. This is the dealbreaker. Hotwire Native relies on the server to render HTML. If the user has no internet, they have no UI. You can cache screens, but interactive "Offline First" capability (like Notion or Linear) is incredibly difficult to pull off. You cannot strictly "Stick to Ruby." Eventually, you will need to implement Push Notifications. Or a Native Camera view. Or a complex Swipe Gesture. You don't need to be a Swift expert, but you need to be comfortable opening Xcode and reading documentation. You cannot live 100% in VS Code. Replicating complex native animations (like the bouncy drag-and-drop of iOS Reminders) in CSS is hard. If you are building a Game or a high-fidelity creative tool (like a photo editor), Hotwire Native will feel cheap. Hotwire Native is mature enough for 90% of SaaS applications. For the Solo Developer, Hotwire Native is a superpower. It allows you to say "Yes, we have an iOS app" without hiring an iOS developer. It requires you to learn the "Hybrid" way of thinking - delegating navigation to the OS and content to the Web - but once it clicks, you will never want to build a JSON API for a mobile app again. Have you tried wrapping your Rails app yet? Did Apple approve it? Share your story! 👇 Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: <!-- app/views/posts/edit.html.erb --> <div data-controller="bridge--form-button" data-bridge--form-button-title-value="Save" data-bridge--form-button-selector-value="#my-form"> </div> Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: <!-- app/views/posts/edit.html.erb --> <div data-controller="bridge--form-button" data-bridge--form-button-title-value="Save" data-bridge--form-button-selector-value="#my-form"> </div> CODE_BLOCK: <!-- app/views/posts/edit.html.erb --> <div data-controller="bridge--form-button" data-bridge--form-button-title-value="Save" data-bridge--form-button-selector-value="#my-form"> </div> - Learn Swift/Kotlin: Stop shipping features for 6 months to build two native apps. - React Native/Flutter: Rewrite your frontend logic in JS/Dart and maintain a separate API. - PWA: Tell users to "Add to Home Screen" and watch them leave because it feels janky. - When you tap a link, the Native OS pushes a new screen onto the stack. - The header (Title, Back Button, Action Buttons) is Native. - The bottom tab bar is Native. - The content inside the screen is HTML. - Old Way: complex JavaScript bridges and message handlers. - Strada Way: Simple HTML attributes. - Verdict: If your app requires offline work (e.g., a field inspection tool for forestry workers), do not use Hotwire Native. Use Swift + Local Database. - Marketplaces? ✅ Yes. - Social Networks? ✅ Yes. - Project Management / CRUD? ✅ Yes. - Dashboards? ✅ Yes. - Audio/Video Editors? ❌ No. - Offline-Heavy Tools? ❌ No.