What I've learned from shipping 25+ mobile apps

And what I tell my clients when they ask which framework to use for their Rails business.

Hey friends, I recently published a new article on my website: The Rails developers’ guide to mobile app frameworks. It covers fully native (Swift/Kotlin), React Native, PWAs, and Hotwire Native with a comparison table and recommendations for when to pick each.

But I didn’t want to just send you a link. The article is the balanced, “here are your options” version. What you’re reading is the opinionated version. The stuff I’ve learned from actually building these apps, not just evaluating frameworks.

Most teams overestimate how much “native” they need

This is the pattern I see more than any other. A team comes to me convinced they need custom native screens for half their app. They want native forms, native lists, native everything. They’ve been burned by web views that look janky and they don’t want that experience.

Then we look at what their users actually do. And 80-90% of it is standard CRUD. Creating records, viewing lists, editing profiles, managing settings. All of that works beautifully as server-rendered HTML inside a native navigation wrapper. No custom Swift or Kotlin needed.

The native parts that matter are the ones that can’t be web. Push notifications, camera access, biometrics, haptic feedback, in-app purchases. Those need to be native. And most of them are doable with bridge components in a few lines of HTML!

The apps that struggle try to do too much natively

When I look at Hotwire Native projects that have gone sideways, the pattern is almost always the same: they tried to build too many custom native screens too early.

Every screen you build natively is a screen you now maintain in three places. The data model in Rails, the API endpoint, and the native UI in both Swift and Kotlin. That’s fine for two or three critical screens. It’s a nightmare for fifteen.

The best Hotwire Native apps I’ve worked on keep the native layer thin. They lean heavily on server-rendered HTML and only “drop down to native” when there’s a clear reason. That discipline is what keeps the maintenance burden manageable for a small team.

The React Native question

This is the one I get asked most. “Should we just use React Native?”

My honest answer: if your team is already writing React on the web and you have a mature API, React Native is a solid choice. I won’t pretend otherwise. You never have to open Xcode or Android Studio, the plugin ecosystem is huge, and the developer ergonomics are genuinely good.

But that’s rarely the situation I see. Most Rails teams are using ERB, Hotwire, and Turbo. They don’t have a React frontend. They don’t have a robust JSON API. Choosing React Native means building both of those from scratch, on top of learning the framework itself.

And here’s the part that surprises people: React web and React Native are different enough that you can’t share frontend code between them. You’re not “leveraging your React skills.” You’re learning a new platform that happens to use the same language.

For a Rails team with server-rendered views, React Native often means more work than going fully native. At least with native you’re only learning one new thing.

App Store rejections are rarely about the tech

Teams spend a lot of time worrying about whether Apple will reject their Hotwire Native app for being “just a web view.” In practice, I’ve almost never seen this happen.

Apple’s actual rejections are about business rules. You need Sign in with Apple if you offer any third-party login. You need in-app purchases if you sell digital goods. You need a way to delete accounts. You need your app to do something that justifies its existence in the stores.

I’ve had apps rejected because the onboarding flow was confusing, because the screenshots didn’t match the app, and because the privacy policy link was broken. Never because the content was HTML.

The framework doesn’t matter to Apple. What matters is that your app provides value and follows their guidelines.

Small teams ship faster with less native code

The fastest Hotwire Native launch I’ve been part of went from zero to the App Store in seven weeks. The team was two Rails developers who had never opened Xcode before. They shipped with zero custom native screens, a handful of bridge components, and their existing Rails views.

The slowest projects I’ve seen took 6-8 months. They were teams that tried to build native equivalents of screens they already had on the web. Not because those screens needed to be native, but because someone assumed “app” meant “native UI.”

Speed comes from constraint. Build the minimum native layer, ship, then enhance based on what users actually ask for. You can always add native screens later. You can’t get back the months you spent building them too early.

You don’t need mobile developers

This is the part that’s hardest for CTOs to believe. Your Rails team can ship a mobile app. They don’t need to learn Swift and Kotlin from scratch. They need to learn just enough to set up the Hotwire Native shell and wire up bridge components.

I wrote my book specifically for Rails developers with zero mobile experience. And I’ve trained developers who had never opened Xcode to ship real apps to the App Store. The learning curve is real, but it’s weeks, not months.

The alternative is hiring iOS and Android developers, which means new team members, new processes, and ongoing coordination between three teams. For a small company, that’s often a bigger risk than the technical challenge of learning a new framework.

What this all comes down to

The right framework depends on your situation. That’s why I wrote the comparison guide, so you can look at the tradeoffs and make an informed decision. Check it out on my website.

And if you’d rather have someone help you figure out the right approach before writing any code, that’s exactly what the Mobile Playbook is for.

I’d love to hear what framework you’re using or considering. Leave a comment and let me know.