Ruby Native vs Hotwire Native

Hotwire Native is the open source framework from 37signals for building native apps around a web app, and Ruby Native's Advanced Mode runs on it. So this is less a competition than a question of how much of the native layer you want to own. Joe wrote Hotwire Native for Rails Developers, so this is the comparison he is least neutral about and most careful with.

#What Hotwire Native gives you

In 37signals' words, Hotwire Native is a web-first framework for building native mobile apps, available for iOS and Android. The makers of Basecamp and HEY run both on it. The current releases are iOS 1.3.0 and Android 1.3.1, both from July 2026.

You get a library, and the app around it is yours: an Xcode project in Swift and an Android Studio project in Kotlin. You write the app setup, the navigator, and the path configuration that decides which URLs push, which present modally, and which open a native screen. You can add fully native screens in SwiftUI or Compose, and bridge components that let your web pages call native code you wrote. Certificates, builds, TestFlight, the store listings, and review are yours too, along with each year's iOS and Android changes.

#Where Hotwire Native is the right call

You want to write native code: a screen in SwiftUI, a bridge component of your own, navigation rules of your own.
You have a mobile developer, or you are one, and you want the native layer in your repo.
You want no dependency on a hosted service, at the cost of running the builds and the stores yourself.

That is a good place to be, and Ruby Native will say so. If you outgrow Ruby Native, this is where you graduate to.

#Where Ruby Native is the right call

Nobody on the team writes Swift or Kotlin, and nobody wants to. The native layer is config/ruby_native.yml and a few view helpers.
The things Hotwire Native leaves to you are the things you want handled: certificates, cloud builds, TestFlight, screenshots, the listing, submission, and each OS release.
Native features from the page, already built on both platforms: a native tab bar, navigation bar buttons and menus, menus on any element, a floating action button, push notifications, badges, toasts, haptics, a barcode scanner, in-app purchases, and an in-app review prompt. In Hotwire Native each of those is a bridge component you write twice, once per platform.
Your coding agent can run the whole store journey through the MCP server, and status tells it which steps Apple and Google keep for a person.

What Ruby Native does not give you is a native screen of your own. If a screen has to be SwiftUI or Compose, that is Hotwire Native's job.

#Side by side

	Hotwire Native	Ruby Native
What it is	A library	A product: the apps, the builds, and the stores
The native projects	Yours, written in Swift and Kotlin	Ours, with a copy to download any time
Native features	Bridge components you write per platform	Signals in your HTML, already built on both platforms
Custom native screens	Yes	No
Builds, signing, TestFlight	Yours	Cloud builds, signed with your certificate
Store listing and submission	Yours	A file in your repo, one command, or your agent
New iOS and Android releases	Update the library and both projects	Handled once, picked up by your next build
Cost	Free, plus the developer who owns it	$199 a month per app

#Moving between them

From Ruby Native to Hotwire Native, download the native source from your dashboard. In Advanced Mode it is a normal Hotwire Native project, so graduating is a handoff rather than a rewrite, and you keep that copy if you cancel.

From Hotwire Native to Ruby Native, Equipe did it: a decade of native apps, moved to one config file. The case study has the before and after.

The business comparison, against hiring a mobile team, an agency, or a React Native rebuild, is on Why Ruby Native. Try the demo app on your phone from /try, or email Joe at [email protected] with your app's URL.