DEV Community

Cover image for Rails on iOS/Android: Can You Build a "Real" App with Hotwire Native?
Zil Norvilis
Zil Norvilis

Posted on

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

#rails #hotwire #ios #android

The "Mobile App" Dread

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:

  1. Learn Swift/Kotlin: Stop shipping features for 6 months to build two native apps.
  2. React Native/Flutter: Rewrite your frontend logic in JS/Dart and maintain a separate API.
  3. PWA: Tell users to "Add to Home Screen" and watch them leave because it feels janky.

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 Mental Model: It’s Not a Wrapper

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.

  • 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.

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.

The "Yes": Why it is Production Ready

In 2026, the ecosystem has finally matured. Here is why you can bet your business on it.

1. Strada is the Glue

For years, the missing link was Strada. We needed a way for the HTML to "talk" to the Native code easily.

  • Old Way: complex JavaScript bridges and message handlers.
  • Strada Way: Simple HTML attributes.

Example: You want a native "Save" button in the top right corner of the iPhone screen, but the form is in your Rails view.

<!-- 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

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.

2. The "Update" Loop

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.

3. HEY and Basecamp Proved It

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.

The "No": Where it Falls Short

However, if you blindly jump in, you will get hurt. Hotwire Native is NOT for every app.

1. The Offline Problem

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.

  • 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.

2. You Still Need to Know Native Code

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.

3. The "Uncanny Valley" of UIs

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.

The Verdict: Who is it for?

Hotwire Native is mature enough for 90% of SaaS applications.

  • Marketplaces? ✅ Yes.
  • Social Networks? ✅ Yes.
  • Project Management / CRUD? ✅ Yes.
  • Dashboards? ✅ Yes.
  • Audio/Video Editors? ❌ No.
  • Offline-Heavy Tools? ❌ No.

Summary

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! 👇

Top comments (0)