Most Rails teams treat mobile as a second project — a separate repo, a separate team, and a separate budget. Hotwire Native breaks that assumption. With Rails 8 as your backend, a single engineer who knows Ruby can put a production iOS and Android app in the stores in four to eight weeks. Here’s the complete picture of how that works, when it makes sense, and when it doesn’t.
– Hotwire Native lets existing Rails teams ship native iOS and Android apps from a single server-driven codebase — no separate mobile team required.
– Rails 8 features (Solid Queue, Solid Cache, Kamal 2) make Hotwire Native more production-viable than at any point in its history.
– You get real native navigation controllers and gestures — not a styled WebView — while your business logic stays in one Rails app.
– Best for teams already running a Rails app who need a mobile presence; not the right call for offline-first or animation-heavy experiences.
– Hotwire Native vs React Native represents a genuine trade-off: one optimises for team size and speed, the other for UI fidelity and ecosystem depth.
What Is Hotwire Native and How Does It Work?
Hotwire Native is a framework for building native iOS and Android apps that are driven by your existing Rails server — the navigation stack and gestures are fully native, but the screen content renders from HTML responses your Rails app already produces.
Unlike a WebView wrapper (which just draws a browser inside an app shell), Hotwire Native hands the navigation lifecycle to UIKit on iOS and Jetpack on Android. When a user taps a link, the native OS pushes a new screen onto the navigation stack. The back swipe gesture is a native gesture. The header bar with the back button is a native UINavigationBar. What is server-rendered is the content inside that frame — your Turbo-enabled HTML pages.
The technology stack has three layers:
- Turbo Drive — intercepts link taps and form submissions, issues a fetch request, and swaps the
<body>without a full page reload. This is the same mechanism that powers Hotwire on the web. - Turbo Frames — scope partial page updates to a
<turbo-frame>element, allowing independent page regions to update without reloading the navigation stack. - Turbo Native bridge — a thin Swift (iOS) or Kotlin (Android) library that wraps a
WKWebView/WebViewand delegates navigation events to the native navigation stack. The current stable versions are iOS 1.2.2 (released July 2025) and Android 1.2.5 (released January 2026).
The result: your Rails controllers, views, and Stimulus controllers do the heavy lifting across web, iOS, and Android simultaneously. Business logic lives in one place.
What’s New in Rails 8 That Changes the Equation
Rails 8 shipped in November 2024 and made Hotwire Native a substantially stronger production bet — primarily because it eliminated the infrastructure dependencies that used to make small Rails apps expensive to run.
Solid Queue replaces Redis-backed Sidekiq or Resque as the default background job adapter. It runs on your existing database (SQLite in development, PostgreSQL or MySQL in production) with zero additional services. For Hotwire Native apps, this matters because push notifications require reliable background jobs — and with Solid Queue you can run job workers in the same Puma process using config.solid_queue.connects_to, removing a separate worker container from your deployment.
Solid Cache brings the same database-backed philosophy to fragment caching. A Hotwire Native app serving hundreds of concurrent users benefits from aggressive fragment caching on Turbo Frame responses. Solid Cache gives you that without managing a Redis or Memcached cluster.
Kamal 2 became the default deployment tool in Rails 8, replacing Capistrano-centric workflows. Kamal 2 ships with Thruster, a built-in reverse proxy that handles SSL termination and HTTP/2 without Nginx configuration. For a startup deploying its first Hotwire Native backend, this collapses a typical four-service deployment (app, Nginx, Redis, Sidekiq) down to one or two containers.
Propshaft replaces Sprockets as the default asset pipeline, delivering faster builds and a simpler mental model. When your Rails views are the source of truth for mobile screens, build-time asset performance directly affects developer iteration speed.
Rails 8 also ships SQLite as a production-ready default for low-to-medium traffic apps, configured across four separate database files: one each for application data, cache, queue, and cable. This makes a “single server” Hotwire Native deployment genuinely viable — no managed database, no cache server, no job broker.
✅ Pro tip: Start your Hotwire Native project on Rails 8 from day one. Backfilling Solid Queue and Kamal 2 onto an older Rails app is possible but adds a migration cost. New projects get the full “no PaaS required” philosophy out of the box.
The Technical Architecture: From Rails Server to Native Screen
The full stack in a Hotwire Native app moves like this:
A user opens the iOS or Android app. The app shell — built in Swift or Kotlin — contains a native UINavigationController (iOS) or NavController (Android) and a single WKWebView / WebView instance. The native shell loads your Rails app’s root URL on first launch.
From there, every interaction follows the Turbo Native request lifecycle:
Rails-side responsibilities:
- Render HTML responses for every screen. Your
HomeController#indexthat serves the web also serves the mobile home screen. - Add
data-turbo-frameattributes where independent partial updates are needed (for example, updating a cart badge without reloading the whole screen). - Use
Turbo::StreamsChannelfor real-time updates via Action Cable — a product feed that refreshes live on web works identically in the mobile app. - Add Turbo Native bridge components when you need to call native device APIs (camera, biometric auth, push notification tokens).
Native-side responsibilities:
- Define path configuration rules that map URL patterns to native presentations. A URL matching
/modal/*can be configured to always present as a native modal sheet rather than a push navigation. - Implement native screens for routes where HTML is genuinely insufficient (for example, a camera scanner or an in-app purchase flow).
- Register for push notification tokens and post them to your Rails backend.
- Handle deep links and universal links by routing the URL through your Turbo Navigator.
The path configuration (path-configuration.json) is the key architectural file. Fetched from your server at launch, it tells the native app how to present each URL: push, replace, modal, or external browser. Updating this file on your server immediately changes navigation behavior for all users — no App Store submission required.
⚠️ Watch out: The Turbo Native bridge runs a
WKWebViewunder the hood. Apple’s App Store review Guideline 4.2 (Minimum Functionality) means a Hotwire Native app that simply wraps your website without any native enhancement will be rejected. At minimum, add push notifications or one native screen (biometric auth is a natural fit) to clear this bar.
Hotwire Native vs React Native vs Flutter vs Capacitor
No framework wins across all dimensions. The table below scores each on the five criteria that matter most to a startup CTO making this call in 2026.
| Dimension | Hotwire Native | React Native | Flutter | Capacitor |
|---|---|---|---|---|
| Team requirement | 1 Rails engineer + basic Swift/Kotlin | 1–2 dedicated JS/TS mobile engineers | 1–2 Dart engineers | 1 web engineer with JS skills |
| UI fidelity | Native nav + gestures; HTML content | Near-native (JSI bridge, no more old bridge) | Pixel-perfect custom; own render engine | WebView content; native-feeling shell optional |
| Offline support | Limited — page caching only; no offline-first | Full — JS runs on device | Full — compiled to device | Partial — depends on local plugins |
| Server-code reuse | 100% — same Rails views serve web + mobile | 0% — separate React codebase | 0% — separate Dart codebase | ~60% — same HTML/JS with Capacitor plugins |
| Time to first app store release | 4–8 weeks for existing Rails apps | 10–16 weeks from scratch | 10–16 weeks from scratch | 6–10 weeks for existing web apps |
| Hiring difficulty (India market) | Low — Rails engineers are plentiful | Medium — strong React Native pool | Medium — growing Flutter pool | Low — web engineers transition easily |
| Long-term ecosystem risk | Medium — Basecamp-backed, but niche | Low — Meta-backed, large community | Low — Google-backed, strong adoption | Medium — Ionic-backed, web-centric |
When Hotwire Native wins the table: Your team already ships a Rails app, you need mobile presence inside 8 weeks, and your screens are content-and-form driven (dashboards, listings, settings, detail pages).
When React Native wins: You need a standalone mobile experience with rich animations, complex state offline, or a dedicated mobile team already on JavaScript.
When Flutter wins: Brand-differentiated UI that must look pixel-identical across platforms — fintech onboarding flows, gamified experiences, apps where design is a product differentiator.
When Capacitor wins: Your team builds web apps in Vue, React, or Angular and you want a thin native wrapper faster than Hotwire Native’s server-driven model.
[INTERNAL LINK: React Native vs Flutter comparison]
When to Choose Hotwire Native (and When to Walk Away)
Hotwire Native is the right call when all four of these are true: your backend already runs on Rails; your app is primarily content, forms, and lists; you cannot justify a separate mobile engineering hire; and your users tolerate a slight load delay on first screen paint.
Four scenarios where Hotwire Native wins clearly:
B2B SaaS companion app — A web SaaS product that wants to give field teams a mobile app. The admin portal already exists in Rails. Adding Hotwire Native iOS/Android means field reps get push notifications and a native app shell without a single new controller.
Internal operations tool — A warehouse management system or dispatch tool where the user base is 50–500 internal staff. No App Store discoverability pressure; a fast shipping timeline is the only KPI that matters.
Early-stage consumer app with product-market fit uncertainty — When you don’t yet know which screens will survive to V2, server-driven rendering lets you iterate instantly. Shipping a UI change to all mobile users requires a deploy, not an App Store release.
Existing Rails app expanding to mobile — Teams that built their product on Rails 5 or 6 and now need iOS and Android. Hotwire Native reuses 100% of existing views and controllers.
Three scenarios where you should walk away:
Offline-first requirement — A field inspection app, a route-planning tool for areas with poor connectivity, or any app where users must work without internet. Hotwire Native’s page caching handles read-only offline gracefully but cannot handle offline writes.
Animation-heavy or game-like UX — Custom transitions, physics-based interactions, or canvas-heavy screens are painful to implement through server-rendered HTML and CSS. Flutter is built for exactly this.
No existing Rails app — If you’re starting fresh and mobile is the primary product (not a companion to a web app), the setup cost of building a Rails backend just to serve Hotwire Native screens is rarely justified. React Native or Flutter with a lightweight API backend will move faster
Real-World Use Cases: What Gets Built with Hotwire Native
The clearest indicator of Hotwire Native’s maturity in 2026 is the Rails World conference app — a Hotwire Native app built by the Rails community and distributed through both the App Store and Google Play. It handles schedule browsing, speaker detail pages, and session bookmarks — all server-driven, all delivered by a single Rails backend.
Beyond conference apps, the production use-case pattern looks like this:
B2B SaaS mobile companions: A project management tool where managers use the web dashboard and field staff use the iOS app for status updates and photo uploads. The Rails backend serves both; the mobile app adds push notifications for task assignments.
E-commerce with a Rails backend: Product listings, order tracking, account management, and checkout flows translate directly from web to mobile. The one area requiring native implementation is payment capture (Apple Pay / Google Pay), which the Turbo Native bridge handles via a custom bridge component.
Marketplace apps: Two-sided marketplaces (service provider + consumer) often run on Rails. Hotwire Native lets the same Rails app power a consumer-facing mobile app and a provider-facing companion — different path configurations, same server.
Internal tools at scale: A logistics company managing 200 drivers across three cities can give dispatchers a mobile dashboard that mirrors the web tool precisely, with push alerts for pickup requests — built by the same backend team, shipped in six weeks.
[TECORB PORTFOLIO REFERENCE]
[INTERNAL LINK: Ruby on Rails development]
💡 Insight: Every server-side fix, copy change, or feature flag you deploy to your Rails app instantly reaches every mobile user. A startup that shipped a Hotwire Native app avoids the 24–48 hour App Store review cycle for content and logic changes — only binary changes to the native shell require resubmission.
Key Steps to Ship Your First Hotwire Native App
This is a build roadmap, not a line-by-line tutorial. The goal is to give your engineering lead a clear picture of the five stages before committing.
Stage 1 — Prepare your Rails 8 app (Days 1–3)
Ensure your Rails app runs Turbo (via the turbo-rails gem, included by default in Rails 7+). Audit your views for mobile-unfriendly patterns: large data tables, complex multi-column layouts, and Flash messages that assume a full-page context. Add a turbo_native_app? helper (detectable via User-Agent) to serve mobile-optimised variants of problematic views.
Stage 2 — Add the Hotwire Native gem and configure path rules (Days 4–7)
Add hotwire-native-rails to your Gemfile. Create your path-configuration.json file defining which URL patterns present as push, modal, or external. This file is served from your Rails app and cached by the native client — updating it on the server changes app behavior instantly.
Stage 3 — Build the iOS and Android native shells (Days 7–21)
Clone the Hotwire Native iOS and Android starter templates. Customise the app icon, splash screen, tab bar (if needed), and color scheme. Configure your TurboNavigator with the URL of your Rails app. At this stage you have a functional app that renders every screen from your server.
Stage 4 — Add native features (Days 21–35)
Implement push notifications via APNs (iOS) and Firebase Cloud Messaging (FCM) on Android. Store device tokens in a DeviceToken model in your Rails app. Add any native screens that need device API access (camera, biometrics, location). Implement universal links so your web URLs open the app when it’s installed.
Stage 5 — App Store submission (Days 35–42)
Test on physical devices. Prepare App Store screenshots (Xcode Simulator works for static screens). Write your app description emphasising the native features — specifically push notifications — to clear Guideline 4.2. Submit. Average first-submission review time is 24–48 hours for apps with demo credentials supplied.
[INTERNAL LINK: reducing time-to-market for mobile apps]
Common Pitfalls and How Tecorb Has Navigated Them
Production Hotwire Native apps surface a predictable set of problems. Here are the ones that surface most often and the solutions that actually work.
Deep-link handling breaks after cold launch
Universal links work when the app is already running, but on cold launch (app not in memory), iOS sometimes falls back to the browser. The fix: implement application(_:continue:restorationHandler:) in your AppDelegate and pass the incoming URL to your TurboNavigator before the initial page load completes. On Android, handle ACTION_VIEW intents in your MainActivity with the same pattern.
Push notifications arrive but don’t navigate
Registering for push tokens is straightforward; acting on a notification tap to open a specific screen is not. The pattern that works: encode the destination URL in the notification payload, handle the userNotificationCenter(_:didReceive:) delegate callback, and pass the URL through TurboNavigator.route(). Store unprocessed notifications in a queue if the navigator isn’t ready on cold launch.
Offline page caching is fragile
Turbo Drive automatically caches visited pages in memory. When the device goes offline, the cached version renders — but forms fail silently because POST requests can’t reach the server. The solution: add a JavaScript snippet that detects offline events, renders a user-visible “You’re offline” overlay for form interactions, and queues re-submission attempts when connectivity returns. Do not rely on Turbo’s default behavior here.
App Store Guideline 4.2 rejections
Apple reviews apps against Guideline 4.2 (Minimum Functionality) more aggressively for web-driven apps. The two things that reliably pass review: (1) push notifications that provide time-sensitive or personalised information native to the app context, and (2) at least one native screen that uses a device capability (camera, biometric auth, location) not available in the web version. Building at least one of these is not optional.
Authentication state desynchronisation
Rails session cookies work in Hotwire Native — WKWebView shares cookie storage with Safari’s data store. However, token expiry and forced re-authentication can leave the app in a broken state if not handled. Implement a PathConfiguration rule that intercepts requests to /login and presents them as a modal, then post a native notification from the native login modal back to the Turbo session on success.
Frequently Asked Questions
What is Hotwire Native and how does it work?
Hotwire Native is a framework from Basecamp that lets you build native iOS and Android apps backed by your existing Ruby on Rails server. The app shell — built in Swift or Kotlin — provides native navigation controllers and gestures, while screen content renders as HTML from your Rails app. Turbo Drive intercepts link taps, fetches the next screen via HTTP, and swaps content without a full reload. The result is native-feeling navigation with server-driven screens.
Is Hotwire Native production ready in 2026?
Yes. The framework is stable: iOS 1.2.2 shipped July 2025, Android 1.2.5 shipped January 2026. Basecamp ships its own production apps — HEY and Basecamp — using this approach. The Rails World 2025 conference app, built and distributed publicly, ran on Hotwire Native. For content-driven and form-heavy apps, production readiness is not in question.
Can you build a real native app with Hotwire Native — not just a wrapped WebView?
Yes, with an important distinction. The navigation stack (push/pop/modal transitions, back gestures, nav bars) is fully native UIKit on iOS and Jetpack on Android. The content inside each screen is HTML rendered by your Rails server inside a WKWebView. For most business apps — dashboards, lists, detail pages, forms — users cannot tell the difference. Where you need true native UI (in-app purchase, camera, biometrics), you build native screens and integrate them via Turbo Native bridge components.
How does Hotwire Native compare to React Native for a startup?
The core trade-off: Hotwire Native optimises for team size and code reuse; React Native optimises for UI control and mobile ecosystem depth. A Rails team of two can ship a production Hotwire Native app in 4–8 weeks. The same team would need 10–16 weeks and at least one dedicated React Native engineer to ship a comparable React Native app. React Native is the better choice if your app requires complex offline behavior, heavy animation, or your team is already JavaScript-native.
Does Hotwire Native work offline?
Partially. Turbo Drive caches visited pages in memory, so previously viewed screens render offline. What doesn’t work offline: form submissions, any action that mutates server state, and real-time Turbo Stream updates. For apps where users read more than they write — a product catalog, a knowledge base, a schedule viewer — this is often acceptable. For apps that need write-offline-sync-later patterns, Hotwire Native is the wrong tool.
Do I need a separate Rails API, or does Hotwire Native use my existing Rails app?
No separate API needed. Hotwire Native uses your full Rails app — the same controllers, the same views, the same authentication. Your ProductsController#show serves the web browser and the iOS app from the same action. The Turbo Native client requests HTML, not JSON. This is the key architectural distinction from React Native or Flutter, which require a separate API layer.
What types of apps are best suited for Hotwire Native?
Apps that perform best with Hotwire Native share three characteristics: they are backed by an existing Rails codebase, their primary interactions are browsing content, filling forms, and taking list-based actions, and their user base is tolerant of server-round-trip latency on screen transitions (typically 100–400ms on a good connection). B2B SaaS companion apps, internal operations tools, marketplace apps, and e-commerce mobile experiences with standard checkout flows all fit this profile well.
Conclusion: The Fastest Path to Mobile for a Rails Team
Hotwire Native in 2026 is a serious production option, not a shortcut that trades quality for speed. The caveat is real: if your app needs deep offline capability, animation-driven UX, or a standalone mobile identity that looks nothing like a Rails view, walk toward React Native or Flutter.
But if your team runs a Rails app today, your screens are content-and-action driven, and you need mobile without hiring a mobile team — Hotwire Native on Rails 8 is the most direct path available. The new Rails 8 defaults (Solid Queue, Solid Cache, Kamal 2) mean your backend is production-ready on a single server without Redis or a managed queue service. The Hotwire Native iOS and Android SDKs are stable and actively maintained by Basecamp.
The fastest sequence: upgrade to Rails 8, audit your views for mobile compatibility, add the hotwire-native-rails gem, build the native shell from the starter template, add push notifications to clear App Store review, and submit. Four to eight weeks is realistic.
Building a mobile app on top of your Rails stack?
Tecorb’s mobile engineering team has shipped iOS and Android apps across web-native hybrid and fully native approaches. If you’re deciding between Hotwire Native and a dedicated mobile framework, we can walk you through the trade-offs in a 30-minute architecture call.
