Docs

Rails

Rails is RubyEverywhere's primary framework, and its best-tested path. every install detects a Rails app and wires everything up for you.

Detected by

An app is treated as Rails when it has a config/application.rb and its Gemfile depends on rails.

Requirements

  • Rails 7+ on Ruby 3.2+. rbe-tebako presses Ruby into the binary.
  • The standard toolchain: Rust, a C/C++ compiler, and rbe-tebako.
  • For local mode, SQLite. A local-mode app ships without a database server, so Postgres and MySQL are not there on the user's machine. Use them in remote mode.

How it boots

Rails keeps its own boot path. The packaged app loads config/environment and starts the server through Rails::Command bound to 127.0.0.1, and the database is prepared (migrations, multi-db prepare_all) before the window opens. You wire none of this up: every install drops a neutral boot stub that hands off to the Rails adapter.

Development

Terminal bash
every dev        # boots your Rails dev server inside the desktop shell

Your normal bin/dev / asset pipeline keeps working; the shell just wraps a native window around it with live reload.

View helpers

The engine mixes a set of helpers into every view and controller. No include, no import. They render the same everywhere: plain HTML, or inert metadata, in a browser, and native behavior inside the app.

Detecting the shell. These read the shell's User-Agent, so they are right on the first request, before any JavaScript runs:

Helper Returns
native_app? true inside any RubyEverywhere shell: iOS, Android or desktop
native_platform :ios, :android, :desktop, or nil
mobile_app? / mobile_platform the phone shells only: :ios, :android, or nil
desktop_app? true in the Tauri desktop shell
native_version the shell version (Gem::Version) or nil
everywhere_auth_redirect(url) a reset-aware redirect target for after sign-in / sign-out

Reach for the narrowest one that fits what you are branching on. native_app? means "not a browser tab". mobile_app? means a phone, with a tab bar, safe-area insets and biometrics. desktop_app? means a window, with a title bar and a menu bar.

Safe-area padding, hiding a web nav in favour of native chrome, and anything touching Face ID are all mobile_app?: the desktop shell has none of those. Reserving room for an overlay title bar is desktop_app?.

Badges (details). Server-rendered counts, applied on every Turbo visit:

Helper Renders
everywhere_badge(count) app-icon badge (0 clears)
everywhere_tab_badge(path, count) native tab-bar badge for a tab

Biometrics (details). Gate sensitive markup behind Face ID or Touch ID:

Helper Renders
everywhere_biometric_lock(reason:) { … } wraps content that stays hidden until biometrics pass
everywhere_biometric_toggle the device-local "require biometrics" switch

Native chrome (details). Lift ordinary markup into native controls:

Helper Renders
everywhere_nav_button(title, href) a navigation-bar button
everywhere_submit_button(title) a form's Save button, in the nav bar
everywhere_nav_menu { … } a nav-bar pull-down / overflow menu
everywhere_menu_item(title, href) one item inside a menu or action sheet
everywhere_menu(trigger) { … } an in-content action sheet
everywhere_fab(href, icon:, label:) a floating action button

The native-chrome and FAB styles live in everywhere/native.css. Add <%= stylesheet_link_tag "everywhere/native" %> to your layout.

Notes

  • The Bridge API is delivered as the @rubyeverywhere/bridge package, vendored and pinned in your importmap by every install.
  • Everything else (routes, controllers, Hotwire, Active Record) is plain Rails. RubyEverywhere wraps your app; it does not change how you write it.
Rails · Hanami · Sinatra — built with Ruby