Your Rails team can now ship real iOS and Android apps.

Whoever works on your Rails app. A developer with a coding agent sets it up, usually in a day or two, and after that the apps ship with your normal deploys. Nobody needs mobile or app store experience.

Your team, with help. The listing is a file in your repo, so your coding agent drafts the name, subtitle, keywords, and description from the product it already knows, and anyone on the team edits them in their own editor. With the launch review, you send it to Joe from the dashboard before you submit and he reads it the way a reviewer will, tuning the keywords and categories so the app gets found.

Foxance went from an existing Rails app to the App Store in two days. StatusGator, with two years of false starts behind it, was live in both stores in six weeks. Most of your own timeline is Apple's and Google's approvals, which run side by side while your agent drafts the listing.

Yes. Email [email protected] with your app's URL and what you need, or try the demo app on your phone first. Previewing never needs an account.

Ruby Native apps are built to pass. They include what separates a real app from a wrapped website under Apple's guideline 4.2 (Minimum Functionality): a native tab bar, push notifications, and proper app assets. Joe has taken 30+ apps through review on the same technology. If Apple still says no, the launch review covers it: send the rejection to Joe from your dashboard and hear back on exactly what to change. Learn more about App Store review.

Ruby Native apps are built to pass, and apps built with it are already live on Google Play. Ruby Native builds your Android app the same way it builds your iOS app. Your Rails backend doesn't need to change. Read the Android docs.

Nothing your team needs to plan for. Anything a new version changes is fixed once in Ruby Native for every app, and your next build picks it up. When iOS 26 redesigned tab bars and navigation in Liquid Glass, Ruby Native apps got the new look with their next build.

Yes, that is how it is built. ruby_native mcp install registers an MCP server with every command as a tool: config checks, the listing, screenshots, testers, builds, and submission. status tells the agent what is next and which steps only you can take. It works with Claude Code, Cursor, and any MCP client, and every tool is a CLI command first, so nothing needs an agent. The MCP server, documented.

No. Every tool the agent uses is a command you can run yourself, and the dashboard walks you through the same list with the same words. An agent just means you type one sentence instead of running each step.

A few steps the stores keep for a person, because there is no API for them. On Apple: creating the app record, the App Privacy questionnaire, and the age rating. On Google: creating the app, the App content declarations, the tester list, and promoting a release to production. Plus paying. None of it needs expertise. Ruby Native hands you the exact steps at the moment each one comes up, with the link, and your agent picks back up when you are done. Anyone promising you will never open App Store Connect has not checked.

You can, and it will hand you a working shell in an afternoon. Then you own it: two codebases in languages nobody on your team reads, certificates and profiles, App Store review, and whatever September's iOS release breaks. Since spring the changelog has fixed dozens of platform edge cases, from keyboards covering inputs on older Android WebViews to an OAuth cookie that could route sign-in to the wrong app, and an agent-written shell ships with every one of them until your users find them. AI moved the cost of the first build to nearly nothing and left the cost of the fifth year where it was. Ruby Native is priced against the fifth year. If you would rather own the native layer, Hotwire Native is the right call, and the source you download from us is a normal Xcode and Android Studio project if you change your mind later.

Yes. Ruby Native works with any Rails app regardless of frontend framework. Hotwire, Inertia, HTMX, React, Vue, Stimulus, or plain ERB all work as-is. The Rails libraries you already use keep working too, including Devise, OAuth, Active Storage, Action Cable, and Trix. Add Ruby Native to your Gemfile, run the generator, and the app is running on your phone.

Yes. Send them from your Rails server to iOS and Android, and a tap opens the right screen in the app. Read the push docs.

No. Cloud builds compile, sign, and deliver the app from your Rails project, on any operating system.

Yes. Apple requires a $99/year membership to publish apps. You don't need it to preview your app, but you'll need it before your first cloud build. The dashboard walks you through enrolling and waits with you while Apple approves it.

Apple ties cloud signing and bundle ID registration to the Admin role and offers no way to grant either to an App Manager or Developer key, so a lesser role could upload builds but not sign them. The key is encrypted at rest, handed to a fresh build runner for the length of one build, and you can revoke it in App Store Connect at any time without affecting apps already in the store. The security page lists everything Ruby Native holds and how to take it back.

Your app stays live in the App Store and on Google Play, and your users are unaffected. You keep a copy of the native source for your app at the version you had: real Xcode and Android Studio projects you can open, build, and modify. You lose cloud builds, future updates, and in-app subscription management, and you can resubscribe when a new OS version ships to pick them back up.

Your app keeps working. It loads its config and every page from your Rails app, not from us, and Apple and Google host the binary. The only thing that stops is a launch ping the app already ignores when it fails. Download the native source from your dashboard whenever you like: it's a real Xcode and Android Studio project you can build and ship yourself or hand to any iOS developer, and Advanced Mode runs on Hotwire Native, the open-source library 37signals maintains, so most of what you inherit is a stack the Rails community already knows. More on what we hold and how to take it back.

Yes. Accounts have unlimited members and no per-seat pricing. Invite teammates from Settings.

A human on your side through App Review, $999 for one version of your app. Before you submit, you send Joe your listing from the dashboard and he reads it and the screenshots the way a reviewer will, tuning the keywords and categories. If Apple or Google rejects that version, you send the rejection to Joe from your dashboard, and he replies with exactly what to change, or the reply to send when the reviewer is wrong, until it is approved. Every email in between is answered within two business days. Once it clears, the next version that needs the same help gets its own launch review. Without a launch review, email still reaches Joe, just without the two-day promise. How the launch review works.

Once a store has confirmed we can ship your app: after your App Store Connect key validates, or Play Console access verifies. You pay your first month then, and it renews monthly until you cancel. The yearly plan ($1,990, two months free) renews a year after you subscribe.

Yes. Point a second app at your staging URL. Every app is its own subscription, staging included, and previewing on your phone never needs one.

Ruby Native is the starting point, not a dead end. If you outgrow YAML configuration, graduate to Hotwire Native for deeper native control. Your Rails backend stays mostly the same at every step. There's no lock-in and no rewrite. Email [email protected] if you want help planning the next step. Comparing approaches? Ruby Native next to a PWA, Capacitor, and Hotwire Native.