Mobile apps for your Rails business

Most Rails apps already have everything they need to go mobile. Here's how teams are getting to the app stores in weeks, not months.

Your Rails app is great on the web. But your customers are on their phones.

This isn’t a hypothetical. Nearly all mobile time, over 90%, is spent in apps.

A browser tab gets lost. But an app lives on their home screen, sends push notifications to bring them back, and taps into native features like the camera and biometrics. That’s where your customers are.

The question isn’t whether your business should have a mobile app. It’s how to build one without starting from scratch.

I’m Joe Masilotti, author of Hotwire Native for Rails Developers. Every week I share what I’m learning about building mobile apps for Rails businesses, running an indie consultancy, and staying present at home.

---

Four paths, one codebase worth protecting

There are four real options for Rails teams: fully native (Swift and Kotlin), React Native, Progressive Web Apps, and Hotwire Native. Each trades off development speed, native feel, and maintenance cost differently.

Here’s the quick version:

Fully native gives you total control but means building everything three times. You’ll need dedicated mobile developers and a JSON API on top of your existing Rails frontend.

React Native gets you cross-platform from one JavaScript codebase. But it’s still a separate codebase. You’re duplicating logic, building a new API layer, and hiring React developers.

PWAs skip the app stores entirely. Zero native overhead, lowest cost. But almost nobody clicks “Add to Home Screen,” and you lose the legitimacy and discoverability of being in the stores.

Hotwire Native wraps your Rails app in a native shell. Your existing views are the mobile app. Deploy a change to your Rails server and both apps update instantly. No app store review required for most changes.

I wrote a full breakdown of all four approaches, with a comparison table and guidance on when to pick each one: The Rails developers’ guide to mobile app frameworks.

Why most Rails teams should start with Hotwire Native

I’ve shipped 25+ mobile apps backed by Rails. The pattern I see over and over is this: most teams overestimate how much “native” they actually need.

Look at the screens in your Rails app. 80-90% of them are standard CRUD. Lists, forms, detail views, settings. That stuff doesn’t need to be rebuilt in Swift or React. It needs to show up on a phone with native navigation and feel good to use. That’s exactly what Hotwire Native does.

Your Rails app already has the screens, business logic, and authentication. Hotwire Native puts all of that inside native navigation. You’ll still have Xcode and Android Studio projects to manage, but they’re thin wrappers. The real work stays in Rails. Your Rails developers can do this, no dedicated mobile team is required.

And when you do need native features like push notifications, camera access, or biometrics? Bridge components handle that. They connect your HTML to native code on both platforms. Drop one in and you’ve got a native feature in minutes, not weeks.

Here’s the thing: you can always go deeper. Hotwire Native lets you “drop down to native” for fully custom screens when the situation calls for it. Start with your Rails views, add native polish where it matters, and skip the months of rebuilding.

Real apps, real businesses

This isn’t theoretical. Real companies are running real businesses on Hotwire Native.

37signals builds Basecamp, HEY Email, and HEY Calendar this way. Millions of paying customers across iOS and Android, maintained by a small team. These are revenue-generating products, not experiments.

The StoryGraph serves over 4 million users with a single developer. One person, three platforms, and one Rails codebase doing the heavy lifting.

Ruby Friends, my own conference networking app, went from concept to the App Store in three weeks. It has fully baked native features like push notifications, QR code scanning, and Apple Wallet passes. All backed by a Rails app with a thin native layer on top.

I’ve seen this pattern repeat across my client work, too. Teams that expected a 6-month timeline ship in 6 weeks. Rails developers who’d never opened Xcode are building production apps. Companies are saving tens of thousands by not hiring a mobile team.

Honest tradeoffs

I’d be doing you a disservice if I didn’t mention the limitations.

If your app is the product (not a companion to a web app) or if you’re building something with complex custom animations and interactions then fully native or React Native might be the better call.

You’ll also need to manage Xcode and Android Studio projects directly and write a bit of Swift and Kotlin. It’s not a lot, but it’s not zero. If nobody on your team is willing to learn some native basics, you’ll need help getting started.

Also note that Hotwire Native doesn’t have offline support right now. Your app needs a network connection to load screens. If your users need to work without connectivity, this is a real constraint. It’s being worked on, but it’s not here yet.

For the full decision framework, check out the comparison guide.

Where to go from here

If you’re ready to bring your Rails app to the app stores, here’s where to start.

Learn it yourself. My book, Hotwire Native for Rails Developers, walks you through building iOS and Android apps from scratch. It’s the same approach I use with clients.

Add native features fast. Bridge Components is a cross-platform library of production-ready native components. Push notifications, action sheets, menus, and more. Drop them into your app in minutes.

Need help deciding? The Mobile Playbook is a 2-week engagement where I help your team figure out the right framework, architecture, and build plan before writing any code.