My hybrid app framework is now running on 100k devices

Bet you didn’t think you’d hear from me until January, yeah? Well, as of this writing, baby isn’t here yet, so I have a bit of extra time on my hands. And what timing, because I can share some of the most exciting (professional) news of my year: Ruby Native apps are now running on over 100,000 devices!

A huge nod to Equipe for making this possible. They recently migrated their 10+ year-old Hotwire Native app to Ruby Native. And with close to a million downloads over the last decade, they started contributing the majority of the active devices running Ruby Native apps.

This milestone feels a bit surreal for me. The first commit to Ruby Native was only in February of this year. Back then I just had a lofty dream of making mobile apps easier for Rails developers. But now? Real businesses are trusting Ruby Native. Equipe is no side project. It’s a profitable business supporting a huge portion of the equestrian events across Europe.

Right before I went on leave, I published a case study on how and why Equipe migrated. Check it out on Ruby Native. Jon, the founder of Equipe, went from having to hire contractors for every native update to running native builds and deploys himself. He even said “The app has never felt so good on Android. Love this.”

One of the big reasons Jon, a self-described “Rails guy,” is able to do this himself is thanks to Herb. Bundled with the Ruby Native gem is a check command. It traverses your views looking for Ruby Native calls like native_navbar_tag and native_haptic_data. Because Herb can process/analyze ERB, the check command can actually walk the AST and find bugs before you deploy. For example, having multiple “navbars” doesn’t make sense, but isn’t exactly a compilation error.

➜ bundle exec ruby_native check
app/views/books/index.html.erb
  17:  warning 2 elements carry `data-native-navbar`; only the first one is used.
​
Checked 18 templates: 0 errors, 1 warning.

The most important check is that if you hook up your Ruby Native account, it can tell which native version you last deployed with. So if you try to add a Ruby Native feature that your users don’t yet have access to, it will spit out an error to update your native version.

➜ bundle exec ruby_native check --deployed
app/views/books/new.html.erb
  5:   error   `data-native-keyboard-toolbar` needs 0.15.0, your ios build is 0.14.2
​
Checked 18 templates: 1 error, 0 warnings.

This takes a huge amount of stress off of Rails developers’ shoulders. It means they can reliably and safely adopt Ruby Native features without worrying about breaking things, backwards compatibility, or accidentally using unsupported features. You can even hook it into your CI pipeline as a step to ensure it blocks a release if the check fails!

And the proof? Equipe is reporting less than 0.01% of users experiencing crashes across both platforms.

My long-term goal is to make mobile development easier and more accessible for Rails developers. And it’s hard to find a better example than this. A Rails founder is now running their mobile apps without stepping outside of Ruby. And doing it with confidence.

I’m proud of where Ruby Native has gone and I’m even more excited about what’s next. Being a finalist in the Ruby Runway at RubyConf was where it started to feel real. But now it’s like I have proof.

Enjoy Rails World later this month if you’re going. I wish I could be there!