What I wish Hotwire Native actually was - Joe Masilotti

Joe Masilotti

SubscribeSign in

What I wish Hotwire Native actually was<br>I wrote the book on Hotwire Native. Then I built what I actually wanted.

Joe Masilotti<br>Aug 14, 2026

Share

In 2021, Dale Zak published a post on dev.to called Reusable Turbo iOS project configured entirely from your Rails app. He set five goals for the project:<br>Reusable base project that can be pointed to any Rails app

App styling, tabs, and navbar buttons driven from the server

Handle both authenticated and unauthenticated users

All logic and functionality contained in a single Swift file

No need for other developers to write any Swift code

I was excited enough at the time to leave a comment: “Amazing work here! EVERYTHING is configurable via the Rails code without needing any Swift.”

First, take a look at the cute little avatar. Remember my Mii? 😅<br>But that was five years ago, and I haven’t stopped thinking about that list. Four of the five goals describe what I’ve been building. Honestly, almost exactly.<br>The one I’d change is number four. All the logic and functionality shouldn’t live in a single Swift file. It should live in your Rails app, and you should never have to look at the Swift at all .<br>I’m the Hotwire Native guy

I’ve been Hotwire Native’s biggest advocate since the day it was released. I wrote Hotwire Native for Rails Developers for The Pragmatic Bookshelf and I’ve built more than 30 apps with it.

But I still think it asks too much of a Rails developer. Working through the book means writing Swift and Kotlin, keeping a Mac configured with Xcode, and debugging in the simulator. Every sharp edge that Rails spent two decades removing from web development comes right back.<br>Which is a fair price… if your goal is to learn mobile development. But for most Rails developers, the goal is to get in the App Store !<br>Those 30+ apps taught me a few things, but most importantly, they all come down to the same 95%:<br>a native tab bar

a nav bar with a button or two

push notifications

a little native UI on top of the web views you already have

The last 5% is real custom work. But in my opinion, that 95% shouldn’t require writing any native code at all .<br>Everything driven by your Rails app

Ruby Native is what I wish Hotwire Native actually was. No mobile experience, Mac, or Xcode required. Everything is driven by your Rails server.<br>And by everything, I mean everything. New pages, new content, native buttons, push notifications, deep links, in-app purchases, and more. You deploy your Rails codebase like you always have and the native app picks up the changes immediately. The goal is for the iOS and Android apps to never need an update again.<br>Because native UI is rendered by your views, it follows your business logic. Here I’m adding a native button based on the user’s role in the system:

Admins get an Export button, signed-in users get New order, and everyone else gets Sign in. None of this business logic lives in the native codebase. It stays in Rails, instead of being split across iOS and Android, or React and React Native.

But… AI writes Swift now

So if AI writes native code, who cares what language the native layer is in?<br>Honestly… fair. Point Claude at my book and it will scaffold a Hotwire Native app that isn’t far from what I’d write by hand.<br>But writing the code was never the hard part. It’s all the other stuff. AI can hand you a working Swift codebase, but it can’t get that codebase onto the phone in your pocket.<br>Then come signing certificates, App Store Connect, version numbers, screenshots… Don’t forget to do it all over again for Google Play! My book barely touches that part, because each app store could be its own 200+ pages.<br>Ruby Native handles all of this for you . Connect your App Store account with one API key and Ruby Native signs, builds, screenshots, and distributes your app for you. Everything that’s a pain in the butt for a Rails developer is just, well, handled.<br>Keep writing Ruby

I don’t want a Rails developer to have to learn Swift to launch in the App Store, or Kotlin to launch on Google Play, or to maintain three codebases when one has been paying the bills all along. I want them to keep writing Ruby, push to production like they always have, and watch their app update itself.<br>That’s what I wish Hotwire Native was. So I built it: rubynative.com

Share

Discussion about this post<br>CommentsRestacks

TopLatestDiscussions

No posts

Ready for more?

Subscribe

© 2026 Joe Masilotti · Privacy ∙ Terms ∙ Collection notice<br>Start your SubstackGet the app<br>Substack is the home for great culture

This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts