
Margaret
Spotlight: Joe Masilotti (Author) Interview and AMA!
Native Mobile Development in Rails with
Joe Masilotti
@joemasilotti
Building fully native iOS and Android apps can be complex, expensive, and time-consuming—especially for small teams. But what if you could use your existing Rails skills to create native mobile apps with minimal additional effort?
We sat down with Joe Masilotti to chat about how Hotwire Native is making that dream a reality.
INTERVIEW
Watch the complete interview here:
WIN!
We’re giving away one of Joe’s books to one lucky winner! Simply post a comment or a question in his ask me anything (AMA) below, and the Devtalk bot will randomly pick a winner at a time of the author’s choosing . . . then automatically update this thread with the results!
INTERVIEW (abridged)
Introducing Joe
Joe Masilotti is a developer, consultant, and open-source contributor dedicated to making mobile app development more accessible to Rails developers. A maintainer of Hotwire Native since 2016, Joe first used the framework to launch a 100-plus-screen, Rails-powered mobile app as the sole developer—an experience that shaped his approach to bridging web and mobile development.
Now, through his consulting work and his book, Hotwire Native for Rails Developers, he’s helping developers build native-feeling mobile apps without the complexity of fully native development.
On making mobile apps easy . . .
What makes using Hotwire Native for Rails apps so appealing? You can wrap your Rails app in a native shell (Swift/Kotlin) with minimal backend changes. Joe says, “You can get by with a web view shoved inside of native chrome, so to speak, and go a really long way without having to do much on the design.”
On quick MVPs; low maintenance . . .
You’ll be happy to hear that with Hotwire Native, you can get an app into app stores quickly. Joe muses, “If you really want to go MVP, you could probably read chapter one and then put it in the app stores.”
What’s more, future updates can happen via Rails without resubmission. “The maintenance factor of Hotwire Native apps, I think, is understated,” says Joe. “Because it’s downloaded when the app launches, you can change it after app releases without doing a new push to the app stores. So you can dynamically change the way your app behaves on the fly.”
On keeping your web UI . . .
Joe advises developers to keep the web-based design consistent rather than try to mimic fully native UI patterns. “One of the things that I recommend is don’t try to recreate an Apple-looking app. Don’t try to recreate Android for Android.”
Instead, you should “keep using Tailwind CSS or Bootstrap or what have you, and keep using that to make it just a mobile version of your website that happens to be on native.”
On Hotwire Native compared to React Native . . .
Unlike React Native, Hotwire Native doesn’t replace your UI, but enhances it with native navigation. “The big benefit that I always see with Hotwire Native is that it doesn’t take over your entire app like React Native would,” Joe explains. “If you want to interact with the location API or the push notification API, you just write that native code and then send the data to your server. You don’t need to worry about finding a Hotwire Native-specific plugin for each API.”
On growing into native features . . .
Add features incrementally, Joe advises. “I always try to get a web-based app with one native feature, submit that to the app stores, and then have fun and dive into the native stuff. And that native feature is almost always push notifications because it’s the biggest benefit of native apps.”
On app stores hurdles . . .
One challenge developers face is getting apps accepted by the app stores, which have specific requirements, like at least one native feature. Joe tells us, “It has to have some form of benefit over the website. Push notifications or a native tab bar are usually enough to fulfill that.”
On getting started . . .
“If you have a mobile website, like responsive design or mobile format templates, you can get by with very little changes to get a Hotwire Native app working,” Joe tells us. You’ll find you just need to tweak small things, “iOS, for example, you probably want to hide your H1s because you already have a native navigation bar that sits above the web view.”
As far as technical skills, you’ll be using some Swift and Kotlin, but you can follow along with Joe’s book with just your Rails experience. “I’m building up every single piece of information you need for Kotlin and Swift as the book progresses,” he assures.
So, if you have a Rails app that you want to get into mobile app stores, press the Easy button by using Hotwire Native.
Now that you know his story, add Joe’s book to your library today! Don’t forget to use coupon code devtalk.com to save 35 percent on the ebook:
book-hotwire-native-for-rails-developers
Follow Joe:
Website, masilotti.com
Github, joemasilotti
Linkedin, joemasilotti
YOUR TURN!
We’re now opening up the thread for your questions! Ask Joe anything! Please keep it clean, and don’t forget that by participating, you automatically enter the competition to win one of his ebooks!
Most Liked

DevotionGeo
Joe Masilotti isn’t just the author of this book; he’s also the driving force behind critical parts of Hotwire Native itself. He co-developed the navigation system in the official iOS library, helped 37signals unify Turbo Native and Strada into Hotwire Native, and actively maintains guides, tutorials, and posts on his blog about Hotwire Native. He also maintains repos like Hotwire Native for iOS and Brige Components.
He is truly the Hotwire Native guy.
Thank you Joe!

joemasilotti
Excellent questions! I’ll copy-paste them in above my answers so it’s easy to follow.
- I saw on X that you released the bridge components library. How many years of “frustration” or “repetitive boredom” did you endure before you made the decision that bridge components were necessary?
I started thinking about a library of sorts the first time I copy-pasted a component from one project to the next. But it wasn’t until a few weeks ago that I realized I finally had enough experience to make solid abstractions for the most common use cases. It requires writing a lot of apps to know what folks will need!
- The Swift/Kotlin thing that sets up the Hotwire app has a way of tripping up anyone who is interested in Hotwire Native. I know in the video you mentioned that you ease developers down that path, but what can be done in the Hotwire Native documentation to make things easier?
I think the new docs are a huge step in the right direction. They outline the major features of the framework and explain just enough rationale behind each.
I’d love to see the docs recognize that the reader is most likely a Ruby on Rails developers. Like I assume in my book, this makes comparisons much easier for developers to understand because they already have a shared vocabulary.
- Along side the previous question, what specific sections of swift and kotlin are ideal for getting a good foundation with Hotwire Native. Think in terms of basic types, primitives, structures(classes/objects) etc. Be as specific as possible if you can.
Knowing the major differences between Ruby and Swift/Kotlin will provide the biggest bang for your buck. Knowing how Swift/Kotlin needs to be compiled (compile time errors vs. runtime errors), explicit null types (vs. Ruby’s "everything can be nil
), and how code “flows” through the app are most important (e.g. route → controller → view in Rails).
- Have you ever abandoned a Hotwire Native app projected whether for self or a client and decided to go full native? If so, what were the reasons?
I’ve abandoned a few Hotwire Native projects in the past. But never because the app went fully native. Most of these occurred because of reasons outside of the developer ecosystem, usually related to funds or business decisions.
- Still in line with the previous question: as much as you love it, in your view what’s the best reason to NOT use hotwire native?
If you’re building an offline-first app you should go with a fully native app (or React Native). You’ll be fighting Hotwire Native the entire time trying to get that to work and are better off just going all in and building the app with native APIs directly.
- I recall a few years ago, hotwire native was Strada. Looking at the ReadMe and it says Hotwire Native is consolidation of Strada and Turbo Native. Could you breakdown the distinction(if it actually exists) between Turbo Native and Hotwire Native. Imagine you were explaining to a noob.
Turbo Native + Strada = Hotwire Native
Everything you can do with Hotwire Native you could do with Turbo Native, you would just need more “glue” code to get it working.
- Still in line with the previous question: why the name change i.e what was/is wrong with the name Strada?
Mostly because it was confusing! Developers thought that to build native apps you needed Strada but weren’t even aware of Turbo Native. Consolidating both of them into a single framework with a single name makes a lot more sense - build mobile apps with Hotwire Native, nothing else needed.

joemasilotti
Hey everyone! Joe, the author, here. I’m excited to answer any questions you have about building mobile apps with Hotwire Native and Rails. AMA!
Popular In The Spotlight topics










Other popular topics










Latest in In The Spotlight
Categories:
Popular Portals
- /elixir
- /rust
- /wasm
- /ruby
- /erlang
- /phoenix
- /keyboards
- /js
- /rails
- /python
- /security
- /go
- /swift
- /vim
- /clojure
- /java
- /haskell
- /emacs
- /svelte
- /onivim
- /typescript
- /crystal
- /c-plus-plus
- /tailwind
- /kotlin
- /gleam
- /react
- /flutter
- /elm
- /ocaml
- /vscode
- /opensuse
- /centos
- /ash
- /php
- /deepseek
- /zig
- /scala
- /html
- /debian
- /nixos
- /lisp
- /agda
- /textmate
- /sublime-text
- /react-native
- /kubuntu
- /arch-linux
- /revery
- /ubuntu
- /manjaro
- /spring
- /django
- /diversity
- /nodejs
- /lua
- /julia
- /c
- /slackware
- /neovim