Spotlight: Joe Masilotti (Author) Interview and AMA!

Community In The Spotlight
, , , ,
1

Native Mobile Development in Rails with
Joe Masilotti
@joemasilotti

joe03
joe03400×400 31 KB

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

X, @joemasilotti

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!

3 Likes
2

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!

2 Likes
3

Oh wow, I had no idea this Spotlight was available(since mid March actually) but it seems the post was opened up today.

Thank you everyone(Margaret, Aston and Pragmatic Publishers) for making this happen.

Some quick ones coming your way, @joemasilotti:

  1. 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?

  2. 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?

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

  4. 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?

  5. 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?

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

  7. Still in line with the previous question: why the name change i.e what was/is wrong with the name Strada?

Hopefully this is not too much ;-). I’m really looking forward to your answers.

Many thanks!

1 Like
4

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!

4 Likes
5

Excellent questions! I’ll copy-paste them in above my answers so it’s easy to follow.

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

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

  1. 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).

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

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

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

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

3 Likes
6

Thanks for the kind words, @DevotionGeo! :smiley:

2 Likes
7

Another great Spotlight! Thanks for taking part and for writing the book (and library) Joe!

Dave actually asked the most important question I wanted to ask - is knowing Rails enough to use Hotwire Native (and to read the book) and Joe answered, yep - knowing Rails is enough! :048:

Another couple that come to mind while I’m watching:

  • Can a Hotwire Native app have ‘proper’ iOS push notifications? (Actually looks like you answered half-way through, but worth asking here again as I’m sure lots of people might be wondering the same).
  • Can you make an Hotwire Native app which has location based functionality? (I’ve thought about making an app for Welsh people, and it would be cool to show who’s near you!)

Also this might be a bit off-topic, but would you happen to know how to ‘reserve’ an app name? And is there anything specific to keep in mind when doing this?

1 Like
8

Thanks @AstonJ!

Can a Hotwire Native app have ‘proper’ iOS push notifications? (Actually looks like you answered half-way through, but worth asking here again as I’m sure lots of people might be wondering the same).

Yep! Hotwire Native apps can receive real push notifications on both platforms. And all the features only native apps have access to like Critical Alert Notifications, images, badge counts, and more. I cover all of this in chapter 9 of my book.

Can you make an Hotwire Native app which has location based functionality? (I’ve thought about making an app for Welsh people, and it would be cool to show who’s near you!)

Yes again! Hotwire Native sits “next to” your native Swift/Kotlin code. Which means you can access every native API available on the platform. I cover this in the chapters on bridge components in the book.

Also this might be a bit off-topic, but would you happen to know how to ‘reserve’ an app name? And is there anything specific to keep in mind when doing this?

To reserve a name you’ll need to create a developer account, pay the (annual) fee, create an app/bundle identifier, then create the app. That should be enough to reserve the name. But if you don’t upload a build Apple/Google has the right to remove it after a certain number of days.

2 Likes
9

Thanks for the response to my questions @joemasilotti! I have a couple more questions for you :smile:

Ok this one is key. Maybe in future we could consider having additions to the docs about what kind of apps, you can and can’t build with Hotwire Native. Do you mention this in your book?

I’m still a little bit lost on this. Had to go back to the docs to get a second look. So Strada allows you to build native controls and from Rails I know Turbo is a JS library that allows you to change parts of the page using Javascript and web sockets. So basically combine those aspects if what constitutes Hotwire Native. Please confirm if this is the right definition/model or way of looking at things.

1 Like
10

I introduce the chapter on native screens with a breakdown of when to go native and when to stick to web views. I also have a short summary of those recommendations on my blog.

Pretty much, yeah! Strada components (renamed to “bridge components”) allow you to pass messages back and forth between the web and the app. Once in native app code, you can interact with native Swift and Kotlin APIs.

Here are some examples of bridge components I’ve created in the past. Source code included!

2 Likes
11

Thanks for the reply, Joe! I found another nice blog post where you described in detail(and with screenshots) every chapter of your book.

Great work and I’m looking forward to reading the finished product! Happy writing!

2 Likes