Hotwire Native: ship iOS and Android apps with Rails
Hotwire Native wraps your Rails app in a real iOS and Android shell. I've shipped 25+ apps with it, wrote the book, and gathered everything you need to ship your own.
My book, Hotwire Native for Rails Developers, published by Pragmatic Programmers.
Weekly posts on shipping mobile apps with Rails, plus lessons from running a solo business.
Add native features to your app without writing any Swift or Kotlin.
Handle in-app purchases with native payment sheets and server-rendered paywalls.
A decision guide comparing Native, React Native, PWAs, Hotwire Native, and Ruby Native for Rails teams.
Strategy, building, or maintenance. I help Rails teams ship to the app stores.
Trusted by 37signals, Context Travel, The StoryGraph, and 20+ others.
What is Hotwire Native?
Hotwire Native is the open source framework, maintained by 37signals, for building iOS and Android apps on top of a Rails app. Instead of rebuilding your product in Swift, Kotlin, or React Native, you wrap the app you already have in a thin native shell. The screens you serve over HTML render inside native navigation, so your Rails views are the mobile app.
That means one codebase powers three places: the web, iOS, and Android. When you ship a feature or fix a bug in Rails, every platform gets it at the same time, with no app store review standing in the way.
How Hotwire Native works
Two pieces do the work: a native navigation stack and a web view running Turbo. The native side owns everything that should feel native, like tab bars, navigation bars, transitions, and gestures. The web side renders your content, and Turbo makes moving between screens feel instant, the same way it does on the web.
When a screen needs to feel fully native, or reach hardware like the camera, biometrics, or push notifications, you drop down to native code with bridge components. A bridge component connects a Stimulus controller in your HTML to Swift or Kotlin, so you add native behavior without leaving the Rails mental model. You write the native code once, expose it to your web app, and reuse it on every screen that needs it.
One Rails codebase, two app stores
The reason Rails teams reach for Hotwire Native is reuse. You keep building the product you already know how to build, and your existing screens go to work on iOS and Android instead of being rebuilt from scratch. Most of your work stays on the server, where your team is already strong, and the native projects stay small.
This is the opposite of the React Native or fully native path, where every screen and feature gets built two or three more times. With Hotwire Native, a new feature usually means shipping Rails code, and the apps follow.
Is Hotwire Native right for your app?
Hotwire Native is the fastest way into the app stores when you already have a Rails app and a small team. You reuse your product instead of maintaining separate codebases, and you get real apps in the App Store and Google Play without hiring a mobile team to get there.
It isn’t the right fit for everything. If your app has to work fully offline today, or every screen needs heavy custom animation, you’ll work against the framework more than with it. Before you write any code, it’s worth understanding the tradeoffs, so I wrote a full guide comparing native, React Native, PWAs, and Hotwire Native for Rails teams.
How to get started
The fastest way in is to follow my roadmap for building Hotwire Native apps, which lays out what to build first and which app store to launch to. From there, my book, Hotwire Native for Rails Developers, takes you from an empty Xcode project to apps in both stores, even if you’ve never written a line of Swift or Kotlin. And the newsletter keeps you current with weekly posts as the framework grows.
If you’d rather have help, I work with Rails teams on strategy, building, and ongoing maintenance.
Who uses Hotwire Native?
37signals builds Basecamp, HEY, and ONCE on Hotwire Native, serving millions of paying customers across iOS and Android. I helped build the iOS library with their team, and I’ve since shipped 25+ apps for Rails businesses including Strety, Exodus 90, and Context Travel. These aren’t demos or side projects. They’re revenue-generating apps maintained by small teams, because Hotwire Native keeps the work on the server.
Frequently asked questions
Do I need to know Swift or Kotlin?
Not to start. You can launch a complete app using the Rails views you already have, and add small amounts of native code only when a screen calls for it. The book is written for Rails developers with zero Swift or Kotlin experience.
Does a Hotwire Native app feel like a real native app?
Yes, when it’s built well. Native navigation, transitions, push notifications, and in-app purchases all live on the native side. Basecamp and HEY are the proof. Most people never realize the screens are served from Rails.
Is Hotwire Native production-ready?
Yes. It’s the framework 37signals uses for their own apps, it’s open source, and the official documentation lives at native.hotwired.dev. I’ve shipped 25+ apps on it for real businesses.
Does Hotwire Native work offline?
Not today. Your app needs a connection to load screens, though offline support is being explored. If your users have to work without a connection, plan for that early.
Does Hotwire Native support both iOS and Android?
Yes. The same approach powers both platforms, and you write your screens once in Rails. You manage an Xcode project and an Android Studio project, but the bulk of the app, and the logic behind it, stays in one Rails codebase.
“Joe is the person to go to for Hotwire Native guidance and expertise. Joe has been instrumental in building the Hotwire Native libraries with the team at 37signals.”
“Working with Joe was an absolute pleasure – his expertise and collaborative spirit made him a standout partner. He seamlessly helped us build native apps the Rails way with Hotwire Native.”
