Migrated a decade-old Hotwire Native app to a single config file.

The apps worked. But somebody had to keep them working.

Equipe's apps were fine. They had been in the stores since 2013, they shipped monthly, and bugs got fixed. Which meant maintaining a Swift codebase and a Kotlin codebase on top of their Rails app. For a while, I owned the mobile work so nobody at Equipe had to open Xcode or Android Studio.

That works. It also means the apps only move when someone who writes Swift and Kotlin has time, and that someone was me.

The apps weren't broken. They were separate: two codebases and a set of custom bridge components, none of which written in the language the team writes every day.

In June, Jon asked the question directly:

When do you think it is time to move to Ruby Native?

Jon's blockers became product features

Two months earlier I had told Jon that Ruby Native would suit Equipe, with one exception: it couldn't put an image in the nav bar. I treated that as cosmetic.

It wasn't.

What worries me most is the branding. The riders are my sales staff. I want them to see the Equipe logo on all pages, as before.

Equipe's users are competitors and organizers at live events, and the app is Equipe's face in front of them all day. A generic nav bar was a business objection, not a styling preference.

So nav bar branding got built. So did iPad support, which surfaced the same way: Equipe's app already supported iPad, so Ruby Native had to before the migration could deploy.

This is what a design partner is for! Jon was migrating a real app with a decade of requirements attached, so every gap he hit was a gap the next person would hit too. Both features shipped to every Ruby Native customer, not to a branch.

A greenfield app asks a framework for very little. An app that already exists asks for a whole lot more.

Migrating the apps

Replacing both the Xcode and Android Studio projects took:

• config/ruby_native.yml to define the native shell: colors, tabs, linked domains
• a 30-line adapter into their existing push pipeline
• about 34 lines of layout and controller wiring
• a Gemfile addition

No data migration. Years of registered devices and a working push pipeline carried over untouched, still sending through the same code that always sent them. So did the checks scattered through their views asking "are we in the app right now?", because Ruby Native requests answer them the same way.

Equipe is not a vanilla Rails app

Equipe's Rails views are ERB, but a great deal of the app is React: 86 components rendering inside those views, including the nav bar menus. Jon calls it "my special Turbo/React mix."

Ruby Native left all of it alone. Equipe's menus moved to Ruby Native's React components, and that was the whole change: a component swap inside their existing JSX. Nothing about their frontend architecture had to change.

Jon ran the migration himself

I wrote the initial integration branch and the gem features it needed. Jon did the rest: upgrading the gem, deploying, triggering builds, testing both platforms on real devices, and releasing to the app stores.

He is not a mobile developer. And he never opened Xcode or Android Studio once.

It wasn't friction-free. A decade-old app surfaces edge cases a new one never will, and Jon found his share.

This is like a Pandora's box. I have been thinking, every time, this is the last thing.

He asked about migrating in June. The apps went to the stores in September, with nav bar branding and iPad support built along the way.

What Equipe owns now

The apps in the stores are the Rails app now. The config file describing their shell sits in the same repo as everything else, and shipping a change to either platform is shipping Rails code.

Before officially launching, Jon asked about the user journey:

How can we do the transition from the old app to the new app without breaking the app for our users?

Nobody had to be cut over. Equipe's new app replaced the old one in the stores, users update on their own schedule, and the old build keeps working for everyone who hasn't.

The maintenance retainer ended. Nobody is shipping Swift or Kotlin anymore, so there's nothing left for it to maintain.

Equipe pays for Ruby Native Business instead. It costs less per year than the retainer cost per quarter, and Jon runs the releases himself now.

I'm very happy to go the Ruby Native direction.

Who Ruby Native is wrong for

If your app's value is in native surfaces, custom camera work, complex offline sync, heavy background processing, Ruby Native will fight you. Equipe's apps are a Rails product delivered to a phone, which is the case it is built for.

And a migration is not totally free. If your native app is stable, unattended, and nobody minds owning it, staying put is a legitimate answer. The case for moving is strongest when the native codebase is a tax: a language nobody on the team writes, a release cycle separate from your deploys, and a person who has to be available for it.