Ruby Native vs website-to-app wrapper services

Paste a URL, pick an icon, get an app. Website-to-app services have offered that for years, and for a lot of sites it is the right product. Ruby Native looks similar from the outside and is different underneath: it is built for Rails apps, it lives in your codebase, and the stores see your app, not a template. Here is where the line is.

#What a wrapper service gives you

A wrapper service builds a native shell around a web view of your site, configured from the service's dashboard. Most add a native menu or tab bar, push notifications through a push provider's SDK, and a splash screen, and some will handle the store submission for you. Pricing is usually a one-time license plus an annual fee for updates, or, for the done-for-you services, a setup fee plus a monthly retainer that grows with your users. Some let you download the native source. Some do not.

#Where a wrapper service is the right call

• Your site is not a Rails app. A WordPress site, a Shopify store, a hosted site builder. Ruby Native needs a Rails app, so this is not a close call.
• There is no developer on the project, and everything has to be configured from a dashboard.
• The app needs to exist, and nobody expects it to do anything the site does not.

#Where Ruby Native is the right call

• It is a Rails app, and your team works in it. Ruby Native is a gem. The tab bar, icon, and permissions are in config/ruby_native.yml, and navigation bar buttons, menus, form handling, push, and the rest are view helpers in your templates, reviewed in pull requests like everything else. Your Rails app knows when it is inside the app, and sessions, OAuth sign-in, and push tokens are handled on the Rails side rather than by scripts injected from outside.
• Built to pass guideline 4.2. Apple's rule rejects a "repackaged website", and a wrapper is one by definition, so every wrapped site has to argue its way past it. Ruby Native apps include a native tab bar, push notifications, and real app assets by default, and in Advanced Mode native push and pop transitions. Joe has taken 30+ apps through review on this stack.
• Submitted as your app. Apple's guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content, and that such services should not submit on behalf of their clients. Every Ruby Native build is signed under your own Apple developer account with your own App Store Connect key, uploaded to your App Store Connect, and submitted on your yes, by you or your agent. Nothing goes to Apple from a Ruby Native account.
• Push from your server. Devices register with your Rails app and you send from it, and a tap opens the right screen. No push provider in between.
• Kept current. When Apple or Google ships a new OS, the fix lands once in Ruby Native and your next build picks it up. When iOS 26 shipped Liquid Glass, Ruby Native apps got the new tab bars with their next build.
• Yours to keep. Download the native source any time, a normal Xcode and Android Studio project, and keep it if you cancel. Unlimited team members, no per-seat tiers.

Google Play draws its line differently. Play's spam policy bars apps whose primary purpose is a webview of a website without the site owner's permission. It is your site, so that is not the risk there. The judgment that matters on both stores is whether the app is more than the site.

#Side by side

#Moving between them

From a wrapper to Ruby Native, add the gem, run the generator, and the preview is on your phone. If the existing app was published under your own developer account, Ruby Native ships the next version under the same app record in App Store Connect and Google Play, so the switch is an update, not a new app.

The business comparison, against hiring a mobile team, an agency, or a React Native rebuild, is on Why Ruby Native. Try the demo app on your phone from /try, or email Joe at [email protected] with your app's URL.