00:00:32
Even complex UX interactions are possible without writing JavaScript, thanks to Hotwire on the web—Turbo and Stimulus. Our feedback loops are lightning fast: sometimes minutes, sometimes seconds from deploying to seeing our code live in production. Best of all, we can ship whatever we want. There are no gatekeepers or special permissions required—it's the open web.
00:01:13
But when it comes to mobile apps, the rules change. New languages, new toolkits, app store policies—you suddenly lose control and are playing by someone else's rules: Apple, Google, or both. What felt effortless on the web can feel impossible on mobile, yet we can't avoid mobile apps anymore.
00:01:58
Almost all time spent on mobile devices is spent in apps: about 92% in apps versus 8% in the browser. Mobile apps aren't a nice-to-have anymore; for many products and industries they are the expectation. Users live in apps, and discoverability there matters: when someone hears about your product, they instinctively search the App Store or Google Play. If you're not there, you've likely lost a customer.
00:03:06
Beyond discoverability, mobile apps can do many things the web cannot: reliable, customizable push notifications with interactive buttons or dynamic content; interactions with Bluetooth and NFC to pair with devices like scales or heart-rate monitors; controlling nearby IoT devices; scanning tags or tapping badges at conferences to check in; and integrations with Google Fit and Apple Health for steps, heart rate, and other health data. There are also deep integrations with device data—calendar, contacts, and wallet—that enable experiences like automatically blocking calendar time for conference sessions, inviting friends from your address book without a clunky URL, or loyalty cards that appear on the lock screen when you enter a store.
00:05:07
So let's say I've convinced you—you're ready to build a mobile app. The typical path feels daunting: learn Swift for iOS, Kotlin for Android, SwiftUI and Jetpack Compose for UI, ensure compatibility across OS versions and device fragmentation, then ship to the App Store and Google Play. And that's just the front end. Getting data from your Rails server into native apps usually means building separate APIs and JSON endpoints, rendering screens in SwiftUI and Compose, duplicating networking and business logic, and increasing maintenance and debugging work—often two or three times the effort. For small teams or solo developers, that maintenance is a nightmare and makes native development feel impossible.
00:07:10
People often point to PWAs as the solution, but PWAs fall short in important ways. Outside the developer community, few users install PWAs. Native features available to PWAs are often limited or unreliable: push notifications can stop working, sessions can be cleared unexpectedly, and platform behavior can break your app with no warning. PWAs lack app store discoverability and require users to know how to add them to the home screen—an unfamiliar and confusing flow for many non-technical users.
00:09:02
If fully native is on one side and PWAs on the other, React Native sits in the middle. React Native has benefits: you can share code between iOS and Android and reduce duplication between those platforms. But you still need JSON endpoints and often move into the JavaScript ecosystem. If you already use React on the web, React Native can be a good choice. If you're using server-rendered HTML or Hotwire, React Native forces you out of the Rails ecosystem and into a heavier JavaScript stack.
00:10:05
What we want is to build mobile apps the same way we build Rails apps: ship instantly, deploy the same way as the web, and have changes go live across iOS, Android, and web. We want to own our release cycle and not be delayed by App Store review. We want to keep building with the tools we already know and love, without becoming mobile experts or hiring large mobile teams. How? Hotwire Native.
00:11:20
Hotwire Native gives Rails developers access to mobile app capabilities without abandoning the Rails stack. It changes how we think about mobile development: mobile apps are no longer off-limits to Rails developers, including solo or tiny teams who can now achieve feature parity across web, iOS, and Android. What is it? At its core, it's just a web view—a web view with a little magic around the edges. Because it renders the same HTML and CSS we use on the server, we don't have to duplicate business logic. We can send the same HTML to mobile apps that we send to mobile web clients.
00:12:48
Because we're deploying from our server, we keep the same stack and infrastructure. Changes that live only in Rails can go live immediately in apps as well, often without triggering new App Store reviews—after an initial app store submission—so long as we don't change native code. Most importantly, we keep building with Rails, avoid hiring mobile experts, and make mobile development maintainable for small teams.
00:13:55
So how does Hotwire Native work under the hood? Think of your Rails server and a mobile browser—Safari or Chrome—receiving HTML over the wire just like the web. In a native app, the middle content is an embedded web view inside a native shell that provides the navigation bar and tab bar. The key point is that the HTML doesn't need to change. That is Hotwire Native's magic: you can reuse the same HTML and CSS you already render for mobile web.
00:15:34
The tiny native shell offers significant benefits for both developers and users. When you tap a link, Hotwire Native installs a custom Turbo.js adapter that intercepts the click and, instead of performing an XHR, pushes a new native view controller onto the navigation stack. That gives you native transitions and animations on iOS and platform-specific transitions on Android. The native tab bar and navigation controls are first-party UI components—UITabBarController on iOS and BottomNavigationView on Android—so they behave and feel like native controls, including separate navigation stacks per tab. A hidden benefit is that when OS design paradigms change, your app inherits those updates immediately because you’re using platform controls.
00:17:54
You can build a minimal native shell for an MVP and later add deeper native integrations when needed. There are two main strategies: fully native screens for the highest-fidelity, performance-critical experiences (home screens, maps, games, or heavy SDKs), and bridge components—lightweight native pieces that augment web content. Native screens can load instantly from local cache and offer robust native APIs, but they incur higher maintenance cost and require duplicating some logic. Bridge components provide a middle ground.
00:20:33
For example, with Android you can build a Jetpack Compose map, wrap it in a Hotwire fragment, and give it a deep-link ID that your server understands. On the server you maintain a JSON configuration of path rules that map URL patterns to native fragments. When a user clicks a matching URL, Hotwire Native will render the native fragment instead of the web content. Because this mapping lives on the server, you can change routes remotely and Hotwire Native will download, cache, and apply those changes automatically with minimal configuration.
00:22:47
When a native screen is too heavy-handed, bridge components are ideal. Think of them as native sprinkles—Stimulus-like components for native code. They have three parts: a Stimulus controller on the web, a bridge component layer in JavaScript, and a native component in Swift or Kotlin. The Stimulus controller connects, sends a message to the native side with context, and the native component replies with primitives. For example, a Stimulus controller can ask the native component for the user’s heart rate; the native component handles authentication and APIs, then returns the number to Stimulus to display or persist. Let's walk through a live example: an "add friend" button. You put a link in your HTML, add a data-controller namespace like data-controller="bridge--button", generate a Stimulus controller under bridge, import the Hotwire Native bridge and extend the bridge component, then send a "connect" message with context and a callback. On iOS you implement the matching bridge component, create a UIBarButtonItem with the passed title, and reply to the web when the user taps it—under the hood that triggers the original link click.
00:26:57
The magic of bridge components is reusability: once you build the Stimulus controller, the bridge JS, and the native counterpart, you can drop the HTML markup on any page and the native UI will appear—no native code changes required to add the button to new screens. Bridge components scale well and can do much more than small toolbar buttons: native dropdowns (UIMenu), on-device OCR to capture a scanned paper into a PDF, retrieving notification tokens and registering for push via APNs, barcode scanning with automated focus and UI handles, secure background-locking of the app with biometric unlock, and background location access with a single prompt. I’ve collected 16 example bridge components at bridgecomponents.dev with copy-paste code for iOS and Android and Stimulus controllers and documentation. Contributions and PRs are welcome.
00:31:19
A quick history: Turbolinks Native launched in 2016 and proved the concept—turning web apps into native shells. Turbo Native followed with Turbo.js, but early implementations were verbose and required a lot of boilerplate. In 2024 Hotwire Native was released and made building iOS and Android apps from Rails dramatically simpler—what used to take hundreds of lines of code is now achievable in a dozen or so lines. Hotwire Native also added dedicated documentation and guides so it is now a first-class part of the Hotwire family.
00:33:14
The new docs at native.hotwire.dev include iOS and Android getting-started guides. Hotwire Native 1.x introduced demo apps with native tab bars and example bridge components so you can copy-and-paste examples. Those demos run against a demo server that was recently migrated to Rails, making it easier to explore complex interactions like modals, redirects, and flash messages without extra server languages. With Hotwire Native integrated into Rails, simple redirects, modals, and flash messages work out of the box and multiple navigation scenarios are handled automatically.
00:37:06
Hotwire Native continues to evolve. Upcoming improvements include custom animations, lazy-loading tab bars, customizable error handling with native views, and—most importantly—offline caching. Offline caching, leveraging service workers and a PWA-like manifest, is the single biggest blocker for many clients; it will allow Turbo.js pages to be cached and served when the device is offline. Work is underway, and Rosa will speak tomorrow about bringing offline mode to Hotwire with service workers.
00:39:10
Who is having success with Hotwire Native? Real products and teams. One app optimizes CPAP therapy and integrates custom Bluetooth medical devices plus Apple Health and Apple Watch: it uses native integrations for health data and renders charts on the web where it's easiest to build them. 37signals uses Hotwire Native for core apps like Basecamp, HEY Mail, and HEY Calendar—these are flagship apps scaling to millions of users and revenue. The StoryGraph used Hotwire Native for push notifications, native tab bars, and in-app purchases, and scaled to millions of users with essentially a small team. My own Ruby Friends prototype went from idea to App Store in two weeks by reusing mobile web screens and adding native sprinkles like QR scanning and push notifications.
