From a separate Flutter codebase to two Hotwire Native betas.

The client already had a mature Rails product and a separate Flutter application. The goal was not to reproduce every screen in another isolated client. It was to test a web-first mobile architecture in which Rails could continue to carry product behavior while iOS and Android supplied native navigation and selected device capabilities.

Confidentiality note: the client and product are anonymized. The architecture, working process, and delivered beta scope come from a real engagement; identifying details and private materials have been removed.

A separate mobile implementation creates a second product path

A cross-platform client can be the right choice, but in this product it meant that behavior already present in Rails had to be understood and reproduced in a separate application. Authentication paths, navigation rules, and product changes gained another implementation surface.

The migration explored a different boundary: keep web-suitable product behavior close to Rails and add native code only where the mobile experience required it.

Why Hotwire Native fit a Rails product

Hotwire Native renders server-provided HTML inside a native shell and turns link navigation into platform-native screen transitions. Bridge Components connect Stimulus controllers in Rails with Swift or Kotlin counterparts.

This made the migration incremental: a screen could remain web-first, gain native controls through a bridge, or become fully native when fidelity or a device API required it.

The agents wrote the code; context made the code possible

Claude Code and Cursor inspected the existing Flutter behavior, implemented the Swift and Kotlin clients, and wrote tests. I supplied the product model they needed: the old application, Rails behavior, client-provided Figma references, technical constraints, bounded tasks, and acceptance criteria.

I then built each version, tested it, compared the interface with Figma, and fed concrete findings into the next iteration. The useful unit was not a prompt. It was a controlled loop from evidence to implementation to validation.

From onboarding to authentication, navigation, and notifications

The applications grew in vertical slices covering the complete path from first launch and authentication to daily navigation, notifications, and selected native interactions. The work had to preserve the product behavior users already knew while moving responsibility toward the Rails application where that boundary made sense.

The Rails team supplied the web side of the Bridge Components while I directed and validated their native counterparts on iOS and Android. This collaboration kept product decisions close to Rails without reducing the mobile clients to generic web containers.

Building while the ecosystem was still moving

The engagement took place while Hotwire Native and its Bridge Component ecosystem were evolving quickly. That increased the value of small experiments, source-level research, explicit contracts between the web and native sides, and direct verification on both platforms.

Framework examples were a starting point, not proof that a product-specific integration worked.

Generated code was accepted only after it worked

Both applications included automated tests, and I personally built and exercised the flows on iOS and Android. Visual behavior was compared with client-provided Figma screens, while members of the client team also tested product flows.

Authentication, navigation, session, WebView, and notification paths were iterated from observed behavior. Agent output remained an implementation candidate until builds, tests, design comparison, and product feedback supported it.

Two credible betas, without rewriting the ending

Both native clients reached beta. The iOS application was distributed through TestFlight, went through substantial testing, and was close to release readiness; Android remained in beta.

The decision to publish belonged to the client, and no final reason for not releasing either application was communicated. The result claimed here is the delivered mobile capability and repeatable delivery method, not a production launch.