The first time I helped a Rails team get an iOS app into TestFlight, I was sure the hard part would be the code. The team had a polished Rails app, a real product, and paying customers. We just needed to put it in front of people on their phones. How hard could the wrapper be?
Hard enough that I built a career around it.
That was almost ten years ago. Since then I’ve shipped more than 25 mobile apps for Rails businesses, written a book on it, and trained hundreds of developers in workshops, livestreams, and office hours. The teams keep changing. But the wall doesn’t.
And the wall isn’t Rails!
Rails developers are usually delighted by how much of their existing app works inside a Hotwire Native shell. Their forms, their auth, their navigation, their styling: most of it just runs. The wall is everything that happens once the web app is humming and somebody asks the question that always comes next.
“How do we get this into the app stores?”
Then the real pain starts. Apple Developer Program enrollment, provisioning profiles, signing certificates, app identifiers, capabilities, push notification keys, a privacy manifest, a build number that has to be bumped just so. An archive in Xcode that fails the first three times for reasons that will not be Googleable. A TestFlight upload that disappears and comes back with a single-line rejection.
For someone who lives in Rails, that gauntlet is alien. It’s not that any one step is impossible. It’s that every step is its own small adventure, and the adventures compound. By the time you’re staring at App Store Connect trying to figure out which of nine tabs the rejection came from, you’ve forgotten you were supposed to be shipping a feature.
I’ve walked teams through this so many times that I started keeping notes on the order I do it in. The notes turned into a book chapter, the chapter turned into a workshop, the workshop turned into a paid newsletter. Underneath all of it was the same uncomfortable observation. I was getting good at a thing that, ideally, nobody should have to be good at.
So I started building Ruby Native.
The pitch is simple, even if the work was not. You should be able to write Ruby, run a command, and end up with a real iOS app on a real device, without ever opening Xcode. Not “without writing Swift,” which Hotwire Native already gave us. Without Xcode at all. There are no project files to manage, no signing dialogs to fight, and no manual archive step. The infrastructure Apple insists on is still there, of course. It just isn’t yours to operate.
I posted a teaser on Substack on February 11, the kind of post that promises something is coming and then quietly hopes anyone cares. Somebody named Ender left a two-word comment.
Wow. Looking forward.
Ender Ahmet Yurt is a Rails developer in Turkey. We had never spoken. I had no way of knowing whether “looking forward” meant he’d open the next email or whether his comment would scroll off into the void with everybody else’s. I replied and went to sleep.
Yesterday I officially launched Ruby Native.
Today, Ender shipped Foxance to the App Store.
“I started with Hotwire Native, then tried plain Swift. Both took too long. Ruby Native got me from zero to TestFlight in a day.”
Ender Ahmet Yurt
Software Engineer
He never opened Xcode. He’s never met me. He lives on a different continent, in a different time zone, and he turned a Rails app into a real app on real iPhones in less time than it usually takes me to debug a missing entitlement. Foxance is the first customer app shipped on top of Ruby Native. I had nothing to do with the app itself. I only built the path.
What this actually changes #
For most of the last decade, the way a Rails business closed the gap between the web app and the App Store was to hire someone like me, or to spend several months becoming someone like me. There was no shortage of talented Rails developers who wanted to ship to the App Store. There was a shortage of patience for the path that got them there.
That gate sets a price, a timeline, and a confidence floor that keeps a lot of perfectly good Rails businesses out of the stores entirely. “Should we have a mobile app?” turns into “do we have the budget and runway to learn a whole second discipline?” and the question quietly answers itself.
If a Rails developer in Turkey can take an app from working-on-the-web to live-on-the-store in the days after a launch announcement, the gate is lower than it used to be. Not gone. The App Store still has rules and review and rejections, and there will always be room for people who have been through that grinder before. But the part that was about Xcode is, finally, somebody else’s problem.
I’ll keep helping Rails teams ship mobile apps. That’s still what I do. But for the first time the question I get to ask isn’t “are you ready to commit to the ramp?” It’s “do you want your app in the store next month or next week?”
Ten years of closing this gap, and the headline I get to write today is the one I never could before.
Somebody shipped without me.