A reader asked me a great question this week:

Is there a good source for best practices in a Rails app to prepare it for going native?

They gave two examples. One small: skipping Turbo to fix an annoying redirect on the web, which then breaks page transitions on mobile. One big: realizing his web app has a dozen top-level paths, but the mobile tab bar can only hold five.

I’ve seen this pattern in almost every Rails codebase I review for clients. The code isn’t wrong. It’s just web-first in ways that make the mobile version harder than it needs to be.

The good news: most of this is about decisions, not architecture. Make them early and you save yourself a rewrite six months in. This applies whether you ship with Hotwire Native or Ruby Native.

Here are the five rules I’d hand to my past self.

1. Design your information architecture around 3-5 entry points

Apple’s Human Interface Guidelines and Google’s Material guidelines both recommend 3-5 tabs. In practice, this isn’t a suggestion, it’s a constraint that shapes your entire app.

Here’s what that actually looks like in practice. Say your web app has this top nav:

Dashboard · Projects · Reports · Teams · Billing · Notifications · Settings · Admin · Help

That’s nine items but the mobile apps can show at most five. So before you write a single controller, you have to decide which get the highest real estate. And which are demoted behind a “More” tab or link.

The constraint is a feature, not a limitation. Mobile apps work best when they’re focused. The web can afford to be a catch-all because users are sitting at a desk with a mouse, skimming a full nav bar. A phone user tapping through one-handed on a subway needs the app to pick a lane. The five-tab limit forces you to answer “what is this app for?” in a way that a web nav never does.

This exercise feels boring. But it’s the most important one you’ll do. Every URL you design, every redirect you wire up, and every nav partial you build should reinforce those five destinations.

If you skip this step and just “make the web nav work on mobile,” you’ll end up with a hamburger menu that hides everything, which is exactly the experience native users hate.

The test: Can a user reach each core feature in 2 taps from the tab bar? If yes, you’ve got the right architecture.

2. Lean into Turbo from day one

The reader’s example was perfect: They disabled Turbo to fix a rendering issue on the web, which then broke mobile page transitions.

This happens constantly. A flash message doesn’t show up after a form submit, or a JavaScript library doesn’t play nice with Turbo’s fetch, so the developer reaches for the fastest fix they can think of:

<%= button_to “Delete”, post_path(@post), method: :delete, data: { turbo: false } %>

<%= link_to “Dashboard”, dashboard_path, data: { turbo: false } %>

On the web, this “works.” The flash shows, the JavaScript library loads, and the bug goes away. On mobile, this request breaks a transition or is ignored entirely. Hotwire Native needs Turbo to navigate. Without it, link taps silently fail.

The right move is to fix the underlying issue, not mask it. If the flash isn’t showing, respond with a Turbo Stream that updates it:

def create
  @post = Post.new(post_params)
  if @post.save
    respond_to do |format|
      format.turbo_stream { flash.now[:notice] = “Post created” }
      format.html { redirect_to posts_path, notice: “Post created” }
    end
  else
    render :new, status: :unprocessable_entity
  end
end

The mental model shift: Turbo isn’t a web library, it’s the navigation layer. The web just happens to be one of the clients. Reach for data-turbo="false" and you’re papering over a web bug at the cost of the mobile experience.

The exception: The only time you want to disable Turbo navigation is with external POST requests, like Stripe checkout options. But those should be handled on their own, with fully native code. Or converted to in-app purchases.

3. Stick to RESTful, predictable URLs

Hotwire Native uses path configuration to decide how each screen should be presented. Modals, replacements, refreshes, external links… they are all pattern-matched against the URL.

Here’s a typical path configuration that relies on Rails conventions:

{
  “rules”: [
    {
      “patterns”: [”/new$”, “/edit$”],
      “properties”: { “context”: “modal” }
    },
    {
      “patterns”: [”/sign_in”, “/sign_up”],
      “properties”: { “presentation”: “replace_root” }
    }
  ]
}

Those two rules handle 90% of a CRUD app. Every form shows as a modal. Auth screens replace the whole stack. Everything else pushes onto the navigation.

But this only works if your routes look like this:

resources :posts
resources :profiles

Which gives you predictable URLs like /posts/new, /posts/123/edit, /profiles/edit. The $ anchors in the patterns above catch them all.

Now imagine your routes look like this, which is what I actually see in production Rails apps:

# "Friendly" auth routes
get  "signup",  to: "users#new"
post "signup",  to: "users#create"
get  "login",   to: "sessions#new"
get  "account", to: "users#edit"

None of /signup, /login, or /account end in /new or /edit. They won’t match your modal pattern. The signup form pushes onto the nav stack instead of presenting as a modal. Login pushes on top of whatever screen the user was on, instead of replacing the root.

You can fix it with custom patterns:

{
  “patterns”: [”/signup”, “/login”, “/account”],
  “properties”: { “context”: “modal” }
}

But now you’re maintaining two parallel systems: Rails convention for some screens, bespoke patterns for others. Every new “friendly” URL is another rule. Every refactor risks a mobile regression.

The rule is simple: resources :things, every time. Your future mobile self will thank you.

4. Gate mobile-specific UI early

You will have UI that shouldn’t appear in the mobile app:

• Your web navbar (the native tab bar replaces it)

• Your marketing footer

• A “Download our iOS app” banner (Apple will actually reject apps with this!)

• Cookie consent popups

• Chat widgets that don’t play nice with WKWebView

The cheap time to handle this is before you ship. The expensive time is after, when you’re untangling a view hierarchy built around a web-only layout.

Rails ships with hotwire_native_app? through turbo-rails. It returns true when the request’s User-Agent includes “Hotwire Native.” Use it from day one.

For one-off conditionals in views:

<% unless hotwire_native_app? %>
  <%= render “marketing_footer” %>
<% end %>

For larger chunks of layout, wrap whole partials:

<%# app/views/layouts/application.html.erb %>
<body>
  <%= render “web_header” unless hotwire_native_app? %>
  <%= yield %>
  <%= render “web_footer” unless hotwire_native_app? %>
</body>

For dozens of scattered elements, it’s cleaner to load a mobile-only stylesheet:

<%# app/views/layouts/application.html.erb %>
<head>
  <%= stylesheet_link_tag “application” %>
  <%= stylesheet_link_tag “native” if hotwire_native_app? %>
</head>

/* app/assets/stylesheets/native.css */
.d-hotwire-native-none {
  display: none !important;
}

Then mark anything you want hidden:

<nav class=”d-hotwire-native-none”>
  <%# web-only nav %>
</nav>

Now hiding a new element in the mobile app is a one-class change, not a refactor.

The pattern that scales: Every time you add a web-specific element (banner, popup, footer link), ask if it should appear in the app. If not, add the class or wrap it immediately. The cost of doing this as you go is nothing. The cost of doing it in a panicked pre-launch sprint is a week.

5. Treat authentication as “signed in forever”

On the web, session cookies expire. Users sign back in. Nobody cares.

On mobile, making someone sign in every time they open the app will destroy your ratings. “I have to log in every time” is the kind of review that kills new apps. Design for signed-in-forever from the start.

The mobile web views persists cookies automatically, so this mostly comes down to making the server issue long-lived sessions. With Devise, programmatically check remember_me for mobile users:

<%# app/views/devise/sessions/new.html.erb %>
<%= form_for(resource, as: resource_name, url: session_path(resource_name)) do |f| %>
  <%= f.email_field :email %>
  <%= f.password_field :password %>

  <% if hotwire_native_app? %>
    <%= f.hidden_field :remember_me, value: true %>
  <% else %>
    <%= f.check_box :remember_me %>
    <%= f.label :remember_me %>
  <% end %>

  <%= f.submit “Sign in” %>
<% end %>

And bump the remember-me duration to something reasonable for a mobile app:

# config/initializers/devise.rb
config.remember_for = 1.year

If you’re rolling your own auth (the Rails 8 generator, for example), the same principle applies. Use permanent when assigning the session cookie so it lasts 20 years instead of expiring with the browser session:

class SessionsController < ApplicationController
  def create
    if user = User.authenticate_by(session_params)
      session = user.sessions.create!
      cookies.signed.permanent[:session_id] = session.id
      redirect_to root_path
    else
      redirect_to new_session_path, alert: “Invalid email or password”
    end
  end
end

The mobile WebView persists permanent cookies across app launches, so once the user signs in they stay signed in until they explicitly sign out.

Build like the mobile app is coming

Two years ago mobile apps were an item on the “nice to have” checklist. Today, they are almost mandatory.

AI coding assistants compress weeks of work into hours. The flip side is that you can also paint yourself into a corner just as quickly. The reader who asked the question wants to feed these rules into Claude, and that’s exactly right. The constraint isn’t typing speed anymore, it’s the decisions embedded in the code the AI generates.

Ruby Native recently launching has also shifted the calculus. It’s early, but it makes the “Rails-first, mobile second” story more real than ever. If your Rails app follows conventions, you get a mobile app nearly for free. If it doesn’t, you get a mobile app eventually… after a lot of refactoring.

Want to know how your Rails app scores against these five rules? That’s exactly what I do in the first week of a Mobile Playbook engagement. I pull down your codebase, walk through each rule against the real code, and hand you back a concrete list of what to refactor before the mobile build starts. Plus an architecture diagram, a risk register, and a phased build plan.

Two weeks, fixed price, and you leave knowing exactly what to change. Book a call if you want to talk through whether it’s a fit.

Ruby Native turns a Rails app into a native iOS app. Beervana is my first attempt at building something real with that. It’s a native iOS app powered entirely by HTML and a YAML file living on my Rails server. Here’s how it works.

It’s a web app under the hood 🤫

Every screen you see in Beervana is a Rails view, served over HTTPS, rendered in a WKWebView. There is no separate iOS codebase. There is no API. The “app” is my existing Rails app (same controllers, same ERB templates, same Turbo frames) loaded inside a native iOS shell.

That’s the part most Rails developers already understand. And historically, that’s where the story ends, because hybrid apps just… feel off. The tab bar is painted on. The back button is wrong. The forms don’t behave like iOS forms. Users smell a web app in a trench coat.

To make Beervana feel like an app an iOS user actually expects, the shell has to do more than host a web view. It has to give me real native components. And it has to do all of that without me leaving my Rails codebase.

Here’s how that works in Ruby Native.

Native tab bar

A native UIKit tab bar with SF Symbol icons.

Drawing a tab bar in CSS is easy. The hard part is everything else: linking between tabs so a web link in the Explore tab switches to Passport without reloading, refreshing one tab’s content after a non-GET request in another (stamp a brewery in Explore and the Passport tab needs to know), and hiding the tab bar entirely when the user signs out. That state management is where most hybrid apps fall apart.

Ruby Native handles all of that. Cross-tab refresh, auto-routing, and sign-out handling are all wired up automatically, without any additional code.

tabs:
  - title: Explore
    path: /explore
    icon: binoculars
  - title: Passport
    path: /passport
    icon: wallet.bifold
  - title: Profile
    path: /profile
    icon: person

Sign in with Apple

In the video, tapping “Sign in with Apple” opens a native system sheet. Face ID runs. The sheet dismisses. You’re signed in. That’s the bar for a production iOS app.

Getting there normally means writing Swift. ASWebAuthenticationSession to open the browser sheet, state and nonce handling to survive the round trip, a custom URL scheme to receive the callback, and then the awkward dance of getting your Rails session cookie onto the WKWebView so the user is actually signed in when they land back in the app. None of that is fun to write, and every piece is another thing to break.

Ruby Native does the entire native side for you. Your existing OmniAuth setup still owns the provider credentials, callback, and user creation. You just tell it which path kicks off an OAuth flow.

auth:
  oauth_paths:
    - /auth/apple

Native navigation bar

The nav bar is where a lot of a web app’s functionality lives. Edit buttons, overflow menus, account actions. In the video, tapping the menu button on the Profile tab opens a native drop-down with Sign out and Delete account. Tapping Delete account fires a native iOS alert.

All of it is powered by ERB.

native_navbar_tag gives you a UINavigationBar. navbar.button adds a bar button item with an SF Symbol. A block turns that button into a drop-down menu. Each menu item uses one of two verbs: href navigates to a path, or click clicks a hidden DOM element — which means your existing button_to with a turbo_confirm prompt just works, including the native iOS alert it triggers.

<%= native_navbar_tag do |navbar| %>
  <% navbar.button icon: “line.3.horizontal” do |menu| %>
    <% menu.item “Sign out”, click: “#sign-out” %>
    <% menu.item “Delete account”, click: “#delete-account” %>
  <% end %>
  <% navbar.button icon: “pencil”, href: edit_profile_path %>
<% end %>

Native forms

Forms on iOS feel different from forms on the web. The edit screen slides up as a modal sheet. The Save button lives in the navigation bar. Tapping Save disables the form and shows a native loader while the request is in flight. When it finishes, the sheet dismisses and tapping back doesn’t take the user to an empty form page.

That set of expectations has no direct equivalent on the web, which is why most hybrid forms feel off. Ruby Native closes the gap with a single tag.

native_form_tag tells the native app this is a form page. The navbar.submit_button helper puts a native Save button in the nav bar that’s wired to the Rails form below it. Submit the form and the native button disables itself, shows a loader, and waits for Rails to respond. Back navigation skips the form page automatically, so the user never sees a stale draft.

<%= native_form_tag %>
​
<%= native_navbar_tag “Edit profile” do |navbar| %>
  <% navbar.submit_button %>
<% end %>
​
<%= form_with model: current_user do |form| %>
  <%= form.text_field :name %>
<% end %>

Try it

Beervana is live on the App Store today. Everything in the video and every snippet above is running in the real, shipped app.

And that’s the whole point of Ruby Native. I didn’t write Swift, I didn’t open Xcode, and I ship updates from my Rails repo the same way I always have. Same controllers, same ERB, same deploys.

Ruby Native starts at $299 per app per year, and you can start by shipping to TestFlight for free. The build pipeline runs in the cloud, so you never install Xcode or deal with signing certificates. If you have a Rails app and you’ve been putting off the native version, come kick the tires.

Try Ruby Native for free

Reply with questions. I’d love to hear what you’d build!

Earlier this year I was freaked out about AI. I’ve spent the months since using it constantly, on every project, at every stage. I expected to feel replaced, or at least unsettled. Instead, something underneath the work shifted.

What I used to get tired from

A year ago, the hard days all had the same shape. I’d close the laptop with a specific flavor of tired: I couldn’t figure out how to make a thing work. Not “this took a while.” More like banging my head against a wall for hours, trying the same thing eighteen different ways, and still not knowing why it wasn’t working.

Framework fights. State bugs. Xcode rituals. That Rails method that should have returned the thing and didn’t. The weird edge case on Android where the webview loaded twice.

That was the work. Or at least, that was the part that drained me.

It mostly doesn’t happen anymore.

The feature I wouldn’t have touched last year

Last month I was scoping a feature for Ruby Native, my new service that lets Rails developers ship an iOS app without touching native code. The feature: monitor a private build happening on GitHub Actions, validate the inbound webhooks from Apple as the binary gets processed, and surface live progress in the Rails dashboard the whole way to TestFlight.

A year ago, I would have shied away from that idea. Not because I couldn’t write the code. Because I wouldn’t have thought it was worth the investment. Inbound webhooks from Apple, signature validation, live UI updates, error states for a service where most of the errors aren’t mine? That was weeks of yak shaving for a feature most users would never see fail.

This month, the code wasn’t the problem.

The hard part was the product decisions. How do I show the user this is working? How do I show it succeeded? How do I write the error messages so they don’t have to open App Store Connect and stare at Apple’s rejection language? How do I keep them inside my app, away from Apple’s interface, as much as possible?

That’s the hard work now. And it’s much closer to the user than anything I used to spend my time on.

I love it. It’s the work I thought I was doing all along.

That same week I got off a client call where we spent an hour brainstorming a fully native navigation bar. Custom buttons, dynamic content, state that depends on the user. A year ago I would have steered the conversation toward phase two. This time we just ironed out what it should be and built it.

The feature ideas got bigger. The implementation got smaller. That’s the trade.

Why I’m mostly settled now

Ruby Native is my second AI-led project. On my first I spent too much of it looking over AI’s shoulder. Reading every diff. Second-guessing every suggestion. Reviewing code I didn’t need to review because I didn’t yet trust the tool to get it right.

With Ruby Native I review the critical stuff. Anything that touches signing, money, or the App Store. The rest, I mostly let run.

That change, from monitoring to trusting, is what moved me from “freaked out” in January to “mostly settled” now. It wasn’t a realization. It was reps. A few weeks of building real things and watching the tool deliver.

What I miss

I want to be honest about one thing.

I used to end the day done. The sheer difficulty of getting through a hard problem was a barrier that told me to close the laptop and go be a person for a while. I’d earned the break.

Now the barrier is gone. I pick up my laptop all the time because it’s so easy to just start another thing. No context switching tax. No warm-up. No twenty minutes of remembering where I left off. Just go.

The new hard thing is knowing when to stop. I’m still figuring that one out.

What it means for the work I sell

Something else has started to change, too. How I quote projects.

I’m still figuring it out, but the shape is clear. I’m billing expertise and judgment, not code output. I can build and maintain more than I could a year ago, which means the thing I’m actually charging for isn’t “how many hours the typing took.” It’s “what should be built, in what order, with which tradeoffs, to avoid which gotchas.”

That’s the work I wanted to be paid for anyway. It’s the part I’m best at.

What’s next

The hard part of my job moved. It used to be “how do I make this work?” Now it’s “what should I actually build, and how will the user feel when they use it?”

I would rather be tired from the second question than the first.

If you’re a Rails business figuring out what to build before you write a line of code, that’s exactly what the Mobile Playbook is for. Two weeks, a framework recommendation, an architecture diagram, App Store gotchas mapped out, and a phased build plan you can hand to any developer. Including yourself. Including Claude.

Subscribe now

Hey there,

I was on two podcasts recently. One is my own show, Permission Not Required, where Colleen and I talk about running solo businesses. The other is Technology for Humans, where I was a guest talking about consulting, AI, and going independent.

Podcasts are… well, weird. You say things out loud that you haven’t fully processed yet. Then the episode ships and those half-formed thoughts are just kinda out there.

Here are a few that stuck with me.

Nobody pays a stranger for consulting

Every client I’ve ever signed was someone who already knew me. They’d read the newsletter for a year. They’d seen me speak at a conference. They’d worked with me on a different project years ago. Or someone they trusted sent them my way. None of them were strangers when the contract showed up.

That’s the part of consulting nobody tells you when you’re starting out. It’s not a marketplace where the best portfolio wins. It’s a relationship game with a really long lead time. You’re not selling expertise. You’re selling the comfort of working with someone who already feels like a known quantity.

Which makes the next thing I’m about to say a little painful.

“I’m looking for work” posts have never worked for me

Every solo consultant has done this. You hit a dry spell, you post on X or LinkedIn, and you wait. It has never once resulted in a signed deal for me. Not once.

What does work: a conference talk, a newsletter issue, a podcast episode. But here’s the frustrating part. There’s a six-month lag and you’ll never know which one did it. I keynoted Rails World last year and the leads from that didn’t show up until early 2026.

Next conference I’ll take Colleen’s advice: before I go, research who’s attending via the Slack or Discord. I’ll make a list of people I genuinely want to meet, not for a sale, just because I find their work interesting. I’ll reach out beforehand. And if I can’t find someone, I’ll DM them: “I know you’re here, want to grab coffee?”

There’s no magic lever. Just the long game played consistently (with a lot of coffee).

The feast-or-famine cycle

I was honest about a typical year for me on the pod: Q1 is dry. Q2 brings leads. Q3 makes most of the money. Q4 goes quiet. I’m stressed for six months, then two clients sign at the same time.

If I could snap my fingers and change one thing about consulting, it would be stability. Not higher revenue, just steadier revenue.

My attempt at a fix this year is saying yes to smaller advisory retainers I used to turn down. A team that wants me on call for architecture questions. A maintenance engagement where I keep an app healthy month to month. These used to feel too small to bother with. Now they’re the foundation. They don’t replace the big projects, but they keep the lights on. Stability over spikes.

What I’m actually learning right now

Here’s the part I haven’t said on any podcast yet.

I have three types of client work going on right now. A maintenance retainer where I keep an app healthy. An advisory retainer where I collaborate with a team on their native app strategy. And a build project where I’m shipping an Android app from scratch.

The build project pays the most. But the advisory and maintenance work? That’s what I love. The collaboration. Helping a team make better decisions without having to write every line of code myself. Being a real part of something.

I don’t know what that means long term. More of this but rebranded? Something else entirely? I’m honestly not sure.

But figuring that out isn’t urgent. Yet. The urgent thing is making this year work. I have parental leave coming up, and the difference between stressed parents and relaxed parents going into leave is what happens in the next few months. That’s my North Star right now.

Listen to both episodes

If any of this resonated, here are the full conversations:

• Permission Not Required, Episode 9 with Colleen

• Technology for Humans with Errol from reinteractive

I’d love to hear what landed for you. Drop a comment and let me know what you’re thinking!

Leave a comment

This week I added a native navbar, and it was the first real test of whether this approach scales. Here’s what I’ve learned about keeping an API clean across frameworks, and how I’m catching regressions.

It’s HTML all the way down

When I started Ruby Native, it was ERB-only. The tab bar, push notifications, and forms all used the same pattern: render a hidden HTML element with data-native-* attributes. The native app detects these “signal elements” via a MutationObserver and translates them into real native UI.

For example, the native navbar is just this:

<div data-native-navbar="Account" hidden>
  <div data-native-button data-native-icon="ellipsis.circle">
    <div data-native-menu-item data-native-title="Edit profile"
         data-native-href="/account/edit" data-native-icon="pencil">
    </div>
    <div data-native-menu-item data-native-title="Sign out"
         data-native-click="#sign-out" data-native-icon="rectangle.portrait">
    </div>
  </div>
</div>

Hidden divs, that’s it! The native app doesn’t know what generated them. It just reads the DOM.

This turned out to be the most important decision in the entire project. Because when it came time to support React and Vue, I didn’t have to change anything on the native side. I just needed new ways to produce the same HTML.

Each framework’s API should feel good

ERB developers expect blocks and builders. React developers expect components and props. If you force one framework’s patterns onto another, the API feels wrong even if it works.

Here’s the same navbar in ERB:

<%= native_navbar_tag "Account" do |navbar| %>
  <% navbar.button icon: "ellipsis.circle" do |menu| %>
    <% menu.item "Edit profile", href: "/account/edit", icon: "pencil" %>
    <% menu.item "Sign out", click: "#sign-out", icon: "rectangle.portrait" %>
  <% end %>
<% end %>

And in React:

import { NativeNavbar, NativeButton, NativeMenuItem } from "ruby_native/react"

<NativeNavbar title="Account">
  <NativeButton icon="ellipsis.circle">
    <NativeMenuItem title="Edit profile" href="/account/edit" icon="pencil" />
    <NativeMenuItem title="Sign out" click="#sign-out" icon="rectangle.portrait" />
  </NativeButton>
</NativeNavbar>

Different syntax. Same output. The ERB version uses Ruby’s block pattern with a builder that yields menu items. The React version uses component composition with props. Both feel right in their own context.

The React components themselves are intentionally thin. Here’s NativeButton:

export function NativeButton({ position = "trailing", icon, title, href, click, selected, children }) {
  const props = { "data-native-button": true }
  if (icon) props["data-native-icon"] = icon
  if (title) props["data-native-title"] = title
  if (href) props["data-native-href"] = href
  if (click) props["data-native-click"] = click
  if (position) props["data-native-position"] = position
  if (selected) props["data-native-selected"] = ""
  return createElement("div", props, children)
}

No state or effects, just a function that turns props into data attributes. The less framework-specific logic lives in these components, the less can go wrong.

I don’t use Inertia day-to-day, and it shows! 😬

I’m a Rails and ERB developer. I don’t reach for React or Vue on my own projects. When I built the Inertia support, I leaned heavily on early Ruby Native adopters who use Inertia every day. They told me when something felt off, when a prop name was confusing, or when a pattern didn’t match how they structure their apps.

This is something I think library authors underestimate. You can read the docs and follow the conventions, but there’s a feel to a framework that only comes from daily use. Having people who live in that framework test your API is the difference between “technically works” and “feels right.”

Three frameworks from one test bundle

Supporting multiple frameworks creates a real regression problem. A change to the JavaScript bridge could break React but not ERB. A new signal element might work in Hotwire but lead to a race condition in Inertia. And I don’t want to manually check every combination on every change.

So I set up XCUITest tests for each of the three demo apps: Beervana (Hotwire/ERB), Coffee (React/Inertia), and Habits (Vue/Inertia). Each test suite boots the real Rails server and exercises the actual native UI.

The tests don’t assert on HTML or JavaScript. They assert on what the user sees:

• Does the tab bar appear after sign-in?

• Does the navbar title update when I switch tabs?

• Does the menu button open with the right items?

Here’s what the Coffee (React) test looks like for the navbar menu:

// Menu button: Account page has an ellipsis button with menu items.
let menuButton = app.navigationBars.buttons["More"]
XCTAssertTrue(menuButton.waitForExistence(timeout: 3))
menuButton.tap()

let editAction = app.buttons["Edit profile"]
XCTAssertTrue(editAction.waitForExistence(timeout: 3))

And the equivalent Beervana (Hotwire) test for tab navigation:

app.tabBars.buttons["Passport"].tap()
XCTAssertTrue(app.navigationBars["Passport"].waitForExistence(timeout: 5))

app.tabBars.buttons["Profile"].tap()
XCTAssertTrue(app.navigationBars["Profile"].waitForExistence(timeout: 5))

Both tests are framework-agnostic. They have no idea what’s rendering the HTML. They just verify the native UI works. If I break something in the JavaScript bridge, these tests catch it regardless of which framework exposed the problem.

And then someone asked about Sinatra… 😭

I haven’t tried it yet, but someone recently asked if Ruby Native works outside of Rails. With Sinatra, for example. And the honest answer is: it should. The signal elements are just HTML. The native app reads the DOM. There’s nothing Rails-specific about the data attributes themselves.

The Ruby gem’s helpers are Rails-specific, sure. But the React and Vue components aren’t. And you could render the raw HTML from any templating language.

That question made me realize the early decision to build on data attributes rather than framework hooks is paying off in ways I didn’t plan for. It’s one more framework to think about. But the fact that it’s even plausible tells me the abstraction is at the right layer.

If you’re using Inertia with Rails and want to try Ruby Native, I’d love your feedback. The people who use these frameworks daily are the ones who make the API better.

It felt right! And it’s what developers expect. It’s the “proven” model.

Then I sat down and asked myself an uncomfortable question: What do customers actually get from Ruby Native month after month?

And I didn’t love the answer.

The problem with monthly recurring value

Ruby Native lets Rails developers ship native iOS apps without leaving Ruby. The pitch is: write Ruby, get a native app.

Here’s the thing about that native app once it’s in the App Store: most of it is your Rails app rendered in a web view. You push a change to your server, the mobile app picks it up automatically. No rebuild or App Store review. And Ruby Native isn’t involved at all.

So what does month three of a Ruby Native subscription actually buy you? Or month six? If your app is shipped and working, the answer is: not much. You’re not building on Ruby Native’s infrastructure. You’re building on yours.

That’s a rough foundation for a monthly subscription business. You’re essentially charging people a recurring fee for a tool they used intensively for a few weeks and now barely touch.

I could have glossed over this with more features and more integrations. More more more! In the age of agentic coding… that feels possible. Right?

But I’m a solo operator. I’d rather be honest about what the product actually delivers than manufacture reasons for monthly churn anxiety.

What changes when you switch to annual licensing

The new model flips the equation to match reality:

Repo access is yours forever once you’ve held an active license. Ship the app, let the subscription lapse. The code you built on doesn’t disappear.

Cloud builds and iOS compatibility updates require an active subscription. Apple changes things constantly. New Xcode versions, new SDK requirements, new App Store rules. Staying current is ongoing work, and that’s what an active license covers.

Your app stays in the App Store even if your subscription expires. You just have to build and deploy manually instead of using Ruby Native’s cloud infrastructure.

This maps to actual value. Paying while you’re actively building or need to stay iOS-current makes sense. Paying because you forgot to cancel doesn’t.

The tiers

I settled on just two tiers, priced annually:

• STARTER at $299/year: Cloud builds, repo access, email support. For developers who want to ship and stay current without hand-holding.

• PRO at $999/year: Adds in-app purchases and priority support. For apps that need to make money.

I also dropped MAU limits entirely. Usage caps on a product that runs on your infrastructure never made sense anyway. It was legacy SaaS thinking applied to a tool that doesn’t work like SaaS.

The trade-off I made

Annual licensing means lower theoretical LTV than monthly if a customer sticks around for years. I’m aware of that.

But monthly pricing for a product with thin recurring value creates a different problem: customers who feel vaguely guilty every month, who churn when they get busy, who resent the charge when they’re not actively building. That’s a bad relationship to be in.

Annual licensing sets honest expectations. You pay for a year, you get a year of cloud builds and iOS updates. If that’s worth it, renew. If not, your app still works. And there’s no lock in if you want to use the code as a starting point.

I’d rather charge a fair price for what I actually deliver than optimize for a revenue model that doesn’t fit the product.

A Rails developer reaches out with a great web app. Users love it. But they want to be in the App Store and they have no idea where to start.

So I help them set up Xcode. We configure signing certificates, provisioning profiles, and entitlements. We write Swift to handle navigation, tabs, push notifications, and authentication. We debug build errors that have nothing to do with their actual product.

It always works. And it always takes longer than it feels like it should. But the hardest part is never the app itself. It’s the tooling around it.

After 25+ apps, I started to notice something. A good chunk of every app I build is the same. The tab bar. The navigation. The configuration. The bridge components. The build pipeline… I was solving the same problems over and over, just for different clients.

So I started pulling those pieces into a single tool. And I kept going until the tool could do something I’ve wanted for a long, long time: ship a Rails app to the App Store without ever opening Xcode.

And that tool, my friends, is Ruby Native.

What it actually does

You add a gem to your Rails app. You write a YAML file that defines your app name, colors, and tabs. You run a command, scan a QR code, and see your app running natively on your iPhone. The whole thing takes about ten minutes.

That YAML becomes a real native tab bar. Not a web recreation. A native tab bar using first-party Apple APIs.

When you’re ready to ship, Ruby Native handles code signing, builds, and App Store submission in the cloud. You never install Xcode. You never write Swift. You deploy your Rails app like you always have, and the native shell just works.

Why I’m excited about this

It works with any frontend. Hotwire, React, Inertia, plain ERB. If your website is powered by Rails then it works with Ruby Native. You don’t have to adopt a specific framework or rewrite anything.

It turns a config file into a native app. Change a color in YAML, hit refresh, see it on your phone. That feedback loop is something I never had when building apps by hand.

It removes the scariest part. Most Rails developers I talk to aren’t afraid of building a good product. They’re afraid of Xcode, certificates, and the App Store submission process. Ruby Native takes all of that off their plate.

Run bundle exec ruby_native preview and a QR code pops up right in your terminal. Scan it with the Ruby Native Preview app on your iPhone and your Rails app is running natively on your phone. No build step, simulator, or Mac required.

I mean, how cool is that?!

Where this is headed

I’m launching Ruby Native publicly on April 1. (Not a joke, I promise. 😅) Right now I’m getting early users set up and working through feedback.

If you want to see what it looks like, you can try it in about ten minutes. No account required.

I’ll be back in a few weeks with the full launch details. For now, I just wanted to share why this exists. It came from nine years of doing the same work and finally asking, “What if the Rails developer never had to leave Rails?”

Turns out, they don’t.

Take the Survey

Also, I’m hosting office hours on Thursday for paid subscribers. Bring whatever you’re working on. Hotwire Native questions, app architecture decisions, getting something into the App Store… whatever’s on your mind.

Thanks for reading, it means a lot!

The other day I took my four-year-old to my co-working space.

I had him all set up. Duplos. An Etch A Sketch. Headphones with a story or two queued up. A snack Multiple snacks.

I figured I’d get maybe 15 minutes in before things fell apart.

I got 45.

He walked around the space like he owned it. Got kombucha from the self-serve station. Grabbed mints from the front desk. Sat back down and built something with Duplos while I knocked out a client email and reviewed a PR.

And I sat there thinking: if he’s home sick one day, this might actually work for a little bit.

That’s such a small thing. But when you’re independent and a parent, those small things are the whole game. There’s no calling in to your manager. There’s no backup. There’s just you, figuring out how to get 45 minutes when you need them.

I’ve been independent for long enough that I’ve stopped romanticizing it. The freedom is real, but so is the weight. Every hour I’m not working is an hour I chose not to work, and that choice is never fully clean. There’s always a client waiting, a newsletter to write, a product to ship.

And now, an agent waiting for their next prompt.

But sitting in that co-working space, watching my kid drink kombucha and hand out mints to strangers, I remembered why I do this. Not for the flexibility in the abstract. But for the flexibility in the specific. For that day, specifically.

I don’t have a lesson here. I just wanted to share it.

What’s your version of this? The small moment that reminded you why you went independent, or why you want to. Drop a comment. I’d love to hear it.

Leave a comment

The hardest part of shipping a Hotwire Native app isn’t the code. It’s navigating Apple’s submission process for the first time.

There are a surprising number of gotchas that can cost you days or even weeks if you don’t know about them upfront. A DUNS number that can take a month to verify. An encryption compliance checkbox that silently holds up your TestFlight build. A rejection for “minimum functionality” because you didn’t make the app feel native enough.

I’ve shipped 25+ apps through this process (here’s what I’ve learned). This guide covers every step from setting up your developer account to hitting “Submit for Review.”

I’m Joe Masilotti, author of Hotwire Native for Rails Developers. This newsletter is where I share weekly thoughts on mobile app development, indie consulting, and doing great work while staying present at home.

Subscribe now

Set up an Apple Developer account

Before you write a single line of code, enroll in the Apple Developer Program. This might sound obvious, but I’m putting it first for a reason: it can take weeks to get approved.

Enroll as an organization, not an individual. It’s better for credibility in the App Store, and it makes things easier if you ever need to transfer the app to another team or company.

Here’s the catch: organizations need a DUNS number, which is a unique business identifier from Dun & Bradstreet. Apple uses it to verify your company. And the verification process can drag on for a while. I had a client with 100% working code, ready to submit, who couldn’t get into the App Store for months because of an issue with their DUNS number. It delayed the entire launch.

Start the enrollment process as early as possible so it’s ready when you are.

Point to your production server

This one seems obvious, but it’s easy to forget when you’ve been developing locally for weeks. Swap out http://localhost:3000 for your production URL. Or, have your app do it automatically based on which environment it was installed from.

Make sure your production server is live and accessible before you submit. Apple’s reviewers will launch your app and try to use it. If it can’t reach your server, that’s an instant rejection.

Include an app icon

You only need a single 1024x1024 image. In Xcode, delete all the other size slots in the asset catalog and your one image applies everywhere.

No need to design each version at each size. If you have a clean logo at that resolution, you’re set.

Test with TestFlight before submitting

TestFlight is Apple’s beta testing platform, built right into App Store Connect. Use it.

Internal testing lets up to 100 members of your team install builds immediately after processing. No review needed. This is your first line of defense for catching obvious issues on real devices.

External testing opens it up to 10,000 testers, but requires a quick beta review from Apple before the build is available.

Start with internal testing. Share the TestFlight link with your team, get real feedback on real devices. The Simulator is great for development, but there’s no substitute for tapping through your app on an actual phone.

I can’t tell you how many times I’ve caught a native- or bridge-component-integration bug when running the app on my physical iPhone for the first time.

Skip the encryption compliance wait

Speaking of TestFlight, make sure to add ITSAppUsesNonExemptEncryption = NO to your Info.plist.

Without this, every build you upload to TestFlight sits in “Processing” waiting for you to manually answer export compliance questions in App Store Connect. It’s a silent blocker. Your build will look like it’s still processing and you’ll be wondering what went wrong.

Unless you’re doing something custom with encryption beyond standard HTTPS, set this to NO.

The rest of this post covers: creating App Store screenshots (with and without a designer), keyword optimization tricks, privacy and review questionnaire gotchas, how to avoid Apple’s “minimum functionality” rejection, and a post-launch tip that saves you 15% on every in-app purchase.

Read more

But I didn’t want to just send you a link. The article is the balanced, “here are your options” version. What you’re reading is the opinionated version. The stuff I’ve learned from actually building these apps, not just evaluating frameworks.

Most teams overestimate how much “native” they need

This is the pattern I see more than any other. A team comes to me convinced they need custom native screens for half their app. They want native forms, native lists, native everything. They’ve been burned by web views that look janky and they don’t want that experience.

Then we look at what their users actually do. And 80-90% of it is standard CRUD. Creating records, viewing lists, editing profiles, managing settings. All of that works beautifully as server-rendered HTML inside a native navigation wrapper. No custom Swift or Kotlin needed.

The native parts that matter are the ones that can’t be web. Push notifications, camera access, biometrics, haptic feedback, in-app purchases. Those need to be native. And most of them are doable with bridge components in a few lines of HTML!

The apps that struggle try to do too much natively

When I look at Hotwire Native projects that have gone sideways, the pattern is almost always the same: they tried to build too many custom native screens too early.

Every screen you build natively is a screen you now maintain in three places. The data model in Rails, the API endpoint, and the native UI in both Swift and Kotlin. That’s fine for two or three critical screens. It’s a nightmare for fifteen.

The best Hotwire Native apps I’ve worked on keep the native layer thin. They lean heavily on server-rendered HTML and only “drop down to native” when there’s a clear reason. That discipline is what keeps the maintenance burden manageable for a small team.

The React Native question

This is the one I get asked most. “Should we just use React Native?”

My honest answer: if your team is already writing React on the web and you have a mature API, React Native is a solid choice. I won’t pretend otherwise. You never have to open Xcode or Android Studio, the plugin ecosystem is huge, and the developer ergonomics are genuinely good.

But that’s rarely the situation I see. Most Rails teams are using ERB, Hotwire, and Turbo. They don’t have a React frontend. They don’t have a robust JSON API. Choosing React Native means building both of those from scratch, on top of learning the framework itself.

And here’s the part that surprises people: React web and React Native are different enough that you can’t share frontend code between them. You’re not “leveraging your React skills.” You’re learning a new platform that happens to use the same language.

For a Rails team with server-rendered views, React Native often means more work than going fully native. At least with native you’re only learning one new thing.

App Store rejections are rarely about the tech

Teams spend a lot of time worrying about whether Apple will reject their Hotwire Native app for being “just a web view.” In practice, I’ve almost never seen this happen.

Apple’s actual rejections are about business rules. You need Sign in with Apple if you offer any third-party login. You need in-app purchases if you sell digital goods. You need a way to delete accounts. You need your app to do something that justifies its existence in the stores.

I’ve had apps rejected because the onboarding flow was confusing, because the screenshots didn’t match the app, and because the privacy policy link was broken. Never because the content was HTML.

The framework doesn’t matter to Apple. What matters is that your app provides value and follows their guidelines.

Small teams ship faster with less native code

The fastest Hotwire Native launch I’ve been part of went from zero to the App Store in seven weeks. The team was two Rails developers who had never opened Xcode before. They shipped with zero custom native screens, a handful of bridge components, and their existing Rails views.

The slowest projects I’ve seen took 6-8 months. They were teams that tried to build native equivalents of screens they already had on the web. Not because those screens needed to be native, but because someone assumed “app” meant “native UI.”

Speed comes from constraint. Build the minimum native layer, ship, then enhance based on what users actually ask for. You can always add native screens later. You can’t get back the months you spent building them too early.

You don’t need mobile developers

This is the part that’s hardest for CTOs to believe. Your Rails team can ship a mobile app. They don’t need to learn Swift and Kotlin from scratch. They need to learn just enough to set up the Hotwire Native shell and wire up bridge components.

I wrote my book specifically for Rails developers with zero mobile experience. And I’ve trained developers who had never opened Xcode to ship real apps to the App Store. The learning curve is real, but it’s weeks, not months.

The alternative is hiring iOS and Android developers, which means new team members, new processes, and ongoing coordination between three teams. For a small company, that’s often a bigger risk than the technical challenge of learning a new framework.

What this all comes down to

The right framework depends on your situation. That’s why I wrote the comparison guide, so you can look at the tradeoffs and make an informed decision. Check it out on my website.

And if you’d rather have someone help you figure out the right approach before writing any code, that’s exactly what the Mobile Playbook is for.

I’d love to hear what framework you’re using or considering. Leave a comment and let me know.

Leave a comment

I just spent two weeks building a custom newsletter platform from scratch. Auth, subscriptions, analytics, drip campaigns, email previews, Stripe integration… the list goes on.

I did it all with Claude. 20,000+ lines of code. And it worked!

Then I deleted it.

Content in two places felt broken

For six months I’ve had this nagging feeling that my content lives in the wrong place.

My newsletter is on Substack. My website is a Jekyll site. Every time I wrote something, I’d copy it to both places. Then I’d update one and forget to update the other. It felt messy. And all the SEO/AI juice I thought I was losing by having my stuff live on two separate domains.

So I decided to fix it. I’d build one system where everything lives together. My website would become my newsletter platform. No more duplication. No more sync issues. One source of truth.

I fired up a new Rails app and got to work.

What I built

In two weeks, I had:

• User authentication with free and paid tiers

• Subscription flows through Stripe

• Admin interface for managing posts

• Multiple analytics dashboards

• Email sending through Postmark

• Drip campaigns through Bento

• Dynamic CTAs based on whether you were signed in, free, or paid

• A custom markdown renderer (I’m still pretty proud of this one!)

Over 20,000 lines of code. It all worked. I set up my Render config, deployed it, and watched it run.

But then I thought: what happens if…?

Then the “what ifs” started

What happens if a background job fails and I don’t notice?

What happens if a job gets stuck in a loop and sends 500 emails to one person?

What happens if I forget some esoteric header in the emails and my domain gets flagged for spam?

What happens if I leak a credential?

What happens if Cloudflare caches a page wrong and someone sees another user’s session?

None of these were unsolvable. I could always write more code, add more monitoring, and build more safeguards.

But that’s when it hit me: I didn’t have a code problem. I had a decision problem.

The real answer took an afternoon

The real question was never “how do I build a unified platform?” It was “where should my content live?”

Once I actually sat down and thought about it, the answer was obvious.

Substack handles content. That’s what it’s good at. Sending emails, managing subscribers, handling spam complaints, dealing with deliverability. All the stuff I was about to become responsible for.

My website is a business card. A list of my services, an about page, and links to everything else. Simple, static, and practically zero maintenance.

That’s it! No code required. Just a decision about what goes where.

I could have made that decision in an afternoon. Instead, I spent two weeks building something I didn’t need.

Without AI, I would have quit at 20%

If I had tried to build this myself, without AI, I probably would have quit at 20%. It would have been too much work with too many moving parts. Just… not worth it.

But Claude got me to 90%. I was cranking out features, knocking off todos and shipping tons of code. I felt productive.

And that’s the trap. AI removes the friction that used to make us stop and ask “is this even worth building?” You can get so far down the wrong path that you forget to check if it’s the right path.

Building is easy. Building the right thing is hard.

A few weeks ago I wrote about building something real, almost entirely with AI. My takeaway was that code isn’t the bottleneck anymore.

But here’s what I didn’t fully appreciate: that cuts both ways.

If building is easy, building the wrong thing is just as easy. You can spin up a working prototype in a weekend. You can add features faster than you can decide if you need them.

The constraint is no longer “can we build this?” It’s “should we?”

And that’s a strategy question, not a code question.

If I had spent an afternoon thinking through what I actually needed, I would have ended up exactly where I am now. Content on Substack, everything else on my website. No code. No maintenance. No “what ifs” keeping me up at night.

Instead, I learned it the expensive way. Two weeks of work, deleted.

Strategy before code

Before you start prompting Claude, ask yourself: what problem are you actually solving?

Not “what would be cool to build?” Not “what can I build?” What do you actually need?

The answer might be a decision, not a feature. Maybe a conversation instead of a codebase. Or like me, an afternoon of thinking, not two weeks of “shipping”.

Don’t let the ease of building trick you into skipping the strategy. It’s more expensive than it looks.

This is a big part of why I now help teams figure out what to build before they start building. The decision, not just the code.

and I just launched a new podcast, Permission Not Required.

Colleen builds developer tools and helps businesses figure out the intersection of coding and marketing. You probably know her from Software Social or Simple File Upload.

And I help Rails businesses ship mobile apps. But you’re reading my newsletter, so you probably knew that already!

We’ve been chatting about our businesses every week for years. Literally. We talk strategy, product ideas, client drama, wins, losses… all of it.

Those calls have been so valuable that we figured it was time to share them with everyone. Plus, I’ve always wanted to host a podcast. 😅

So here it is. Real conversations about building independent businesses without asking for permission. And trying to stay relevant in the age of AI.

Subscribe on your favorite podcast player:

For the past few weeks I ran an experiment: build something real, almost entirely with AI. Here’s what I learned, what’s shifting in how I think about code, and what I’m honestly terrified about.

I’m Joe Masilotti, author of Hotwire Native for Rails Developers. This newsletter is where I share weekly thoughts on Hotwire Native, indie consulting, and doing great work while staying present at home.

Subscribe now

Building a real product with AI

I just launched PurchaseKit, my take on in-app purchases for iOS and Android apps. And I built more than 90% of it with AI.

This isn’t a trivial product. It has multiple moving parts: an iOS package, an Android package, a Ruby gem, and a hosted SaaS that coordinates between all the pieces. I built out the original iOS and Android proof-of-concepts, then let AI rip on pretty much everything else. I took a very iterative approach, having it build small features one at a time. Not too different from how I would build it by hand.

And to my shock (and horror) it did so with amazing ease.

I had to hold its hand a bunch, sure. There were a few hallucinations here and there, mostly related to Hotwire Native (which makes sense since there probably isn’t a lot of content on that out there, besides from yours truly!). But the Rails stuff? The boring CRUD of managing users, teams, billing, even webhooks… it churned those out without much editing or even review on my end. It was pretty darn close to perfect.

There have been bugs, sure. I only launched this earlier this month. But the fixes aren’t too far from copying a Honeybadger stack trace and dropping it into Claude Code. I can have a fix done in a few minutes without ever needing to know the context (which maybe isn’t actually a good thing).

I make sure a regression test is created first, then the AI can verify the fix by making sure that test passes. I like this approach because I can practically guarantee the issue will be fixed, instead of false positive test runs.

Code is no longer the hard part

Folks are always saying that code was never the hard part. And, as a developer, I always dismissed that. “They don’t know what they’re talking about, of course code is hard!”

Well, I think I’ve flipped on that.

Writing code is no longer the bottleneck. Coming up with what to code and how to get it into the right people’s hands is relatively harder than ever.

My 2026 mindset is to value code a little less. Like giving more stuff away for free. The iOS, Android, and gem for PurchaseKit are all MIT licensed, even though I originally planned a custom license that wouldn’t allow you to use it outside of a PurchaseKit integration.

Code is cheap now. Knowing what to build, how to piece it all together, where to host it reliably, how to provide support when things eventually break… all the business stuff is the hard part. It always has been, but code just took up so much of my time that it was hard to realize that.

What this means for my consulting business

For the past 10+ years I’ve helped businesses bring their Rails apps to iOS and Android with Hotwire Native. I’ve shipped 25+ apps to the App Store and Google Play this way.

So what does this mean for a consultant like myself? Where I “sell” code to businesses for money?

Honestly, I’m not quite sure.

I’m still going to offer “Zero to App Store” services. I think there are lots of businesses out there that don’t want to do this on their own, even with the help of AI. They value someone with a track record. They know what they get will be top quality, will work, will be reliable… and most importantly, if something goes wrong they know exactly who to call: me.

I’d be lying to myself if I said that this will continue to be 100% of my consulting business forever.

I’m going to need to shift to something that vibes better with agent-first coding. Am I offering a “Joe AI” that has all of my 10+ years of experience distilled into a GPT? Or a starter kit that is so well documented that AI can’t possibly mess something up? Or just offering more advisory contracts where teams continue to build and I watch over their shoulder, review PRs, and make sure they don’t shoot themselves in the foot?

I’m not sure yet.

What happens when I’m not typing

Here’s something I didn’t expect: I’m slowly becoming re-addicted to social media.

Every time Claude does work I have the urge, and usually give in, to checking on something. Sometimes I fool myself and pretend that checking email for the 100th time is “productive”. But who am I kidding? And don’t get me started on how often I’ve refreshed Twitter…

I need to figure out something to do in the “down time” when an agent works. I’ve been experimenting with kicking off a new agent in another terminal tab. But I find that I lose context too quickly if the projects aren’t closely related. I also absolutely cannot write anything of substance or value in 30 second increments so that’s off the table.

Maybe I’ll just bring a book to my coworking space… and be that psycho who reads with his laptop open right behind the pages.

I’m not sure if this is how I’ll work forever. This was an experiment, and I’m still processing what it means.

Are you feeling this weird mix of excitement and dread too? Leave a comment, I’d love to hear what you’re grappling with.

And if you want to try AI-assisted coding yourself, here are a few free Claude Code invites.

Side note: If you’re selling to US or EU customers, Apple now allows linking to external payment providers like Stripe. But they show a scary warning screen that tanks conversion. For most apps, native IAPs are still the better path.

This article walks through the full flow: triggering a purchase from your HTML paywall, handling it in Swift, processing Apple’s webhooks, and updating the UI in real-time with Turbo Streams. I’ve built this for a bunch of clients over the past 10+ years, and the approach here is exactly how PurchaseKit works under the hood.

The in-app purchase flow

Here’s what we’re building:

A heads up that these code examples are abbreviated to fit. Reference the downloadable source code below for the full implementation.

1. Trigger the purchase from HTML

A button fires a Stimulus controller, passing the product ID and a token to identify the user from the HTML.

<div data-controller="bridge--paywall">
  <button
      data-action="bridge--paywall#subscribe"
      data-product-id="com.example.pro.annual"
      data-user-id="<%= Current.user.id %>">
    Subscribe for $4.99 per month
  </button>
</div>

2. Send the request to native

The bridge controller extracts the data and sends it to the iOS bridge component.

export default class extends BridgeComponent {
  static component = "paywall"
 ​
  subscribe(event) {
    const productId = event.currentTarget.dataset.productId
    const userId = event.currentTarget.dataset.userId
    this.send(”purchase”, { productId, userId })
  }
}

3. Call StoreKit

iOS receives the message, fetches the product from StoreKit, and initiates the purchase with the user’s identifier.

class PaywallComponent: BridgeComponent {
    override class var name: String { "paywall" }
​
    override func onReceive(message: Message) {
        let id = message.data["productId"]
        let userId = message.data["userId"]
​
        let product = Product.products(for: [id]).first!
        product.purchase(options: [.appAccountToken(userId)])
    }
}

4. Handle Apple’s webhook

After a successful purchase, Apple POSTs a signed JSON Web Signature (JWS) to your Rails server. This is decoded to find the user via the identifier and their subscription is updated.

class AppStoreWebhooksController < ApplicationController
  def create
    payload = decode(params["signedPayload"])
    info = decode(payload["data"]["signedTransactionInfo"])
    user = User.find(info["appAccountToken"])
 ​
    case payload["notificationType"]
    when "SUBSCRIBED"
      user.subscription.update!(
        product_id: info["productId"],
        expires_at: Time.at(info[”expiresDate”] / 1000),
        status: :active
      )
    end
 ​
    head :ok
  end
end

5. Broadcast the update

When the subscription saves, a Turbo Stream is broadcasted to replace the paywall with a success message.

class Subscription < ApplicationRecord
  belongs_to :user
 ​
  after_commit :broadcast_update, if: :active?
 ​
  def broadcast_update
    Turbo::StreamsChannel.broadcast_replace_to(
      user, :paywall,
      target: "paywall",
      partial: "paywalls/success"
    )
  end
end

The key insight is the appAccountToken. When iOS makes a purchase, it can pass a UUID that Apple will echo back in every webhook related to that transaction. We use this to correlate purchases to users: embed the user’s ID in the token, and when Apple’s webhook arrives, extract it to know who just subscribed.

Which means there’s no session cookies, callback URLs, or “pending purchase” records to clean up.

The product ID (like com.yourapp.pro.monthly) is how you identify what’s being purchased. You’ll hardcode these in your HTML buttons and receive them back in webhooks.

This approach has a bunch of benefits.

• You can design and iterate on your paywall in Rails. And that means you can run pricing experiments or complete redesigns without having to submit new binaries to the App Store.

• Subscription data lives in your Rails database, not on Apple’s servers. That means you can use your usual user.subscribed? instead of having to do a round-trip to the device.

• Listening for webhooks ensures that your subscription data is always kept in sync, even if the user never opens the app again. This is super helpful when someone subscribes in the app - you’ll want to give them access on web, too.

If this looks like a lot of moving pieces, well… you’re right. PurchaseKit handles all of this (plus Android, error handling, and edge cases) so you can skip the complexity. But if you want to understand how it works under the hood, or build it yourself, read on.

Paid subscribers get the complete implementation: every line of Swift, JavaScript, and Ruby explained step-by-step, plus a downloadable demo app with working StoreKit code you can run on your device today.

Read more

Who showed up

• A successful founder shared something wild: They shipped 80+ iOS apps and 90+ Android apps, all powered by a single Rails backend. The apps are for different organizations using their platform, each with their own branding. A great example of Hotwire Native’s power for white-label solutions.

• A Rails developer demoed their social app and asked about some UI quirks after upgrading to Liquid Glass.

• Someone building a note-taking app was looking for advice on icon creation and asset management.

• A developer using Claude to generate Rails code for their Hotwire Native app sparked a discussion about where AI shines (CRUD, boilerplate) and where it still needs human oversight (Hotwire Native integrations).

What we covered

Here’s what we covered in the hour-long, private Zoom session.

Flashing screens during navigation

One question was about a flash occurring when navigating between pages. The app has a web-based toolbar shown on every screen and when it disappears then reappears, it is jarring.

Unfortunately, this is a limitation of how view controllers and fragments work on iOS and Android. When Hotwire Native navigates, it covers the whole web view and shows a spinner while loading.

I offered two ways to solve this:

1. Move your toolbar to native so it stays persistent during navigation

2. Use Turbo Frames to update parts of the page without triggering full Hotwire Native routing (essentially creating a single-page app experience for that section)

Switching tabs from a link

Another developer wanted links to automatically switch the tab bar. For example, clicking “See all Posts” from the Home tab should switch to the Posts tab.

You need to build this yourself using path configuration. Add a property like tab_identifier to your path configuration rules. Then in your NavigatorDelegate handle’s function, check for that property, find the matching tab, and switch to it before accepting the route.

if let tabIdentifier = properties[”tab_identifier”] as? String {
    // Find and switch to the correct tab
    tabBarController.selectedIndex = tabIndex(for: tabIdentifier)
}

Stopping audio when leaving a page

We also discussed stopping audio playback when navigating away from a page.

A few options here:

1. Subclass the Hotwire Native view controller and override viewWillDisappear

2. Use a Stimulus controller that listens for disconnect and pauses the audio

3. Use a native audio player instead (bonus: you get background playback and lock screen controls)

The native player approach is often the best solution if you are playing more than simple sound effects. But the Stimulus controller offers the least native code, it should be deployable with only changes to the Rails codebase.

Icon creation and app assets

A developer asked what I use for icons. Here’s my go-to stack:

• SF Symbols for iOS-only apps (almost 7,000 symbols to choose from)

• Material Symbols for Android or cross-platform (download SVGs)

• Bootstrap Icons or Heroicons for web-focused icon sets

• The Noun Project for app icons (~$5 per icon, varying quality)

The Noun Project is my sleeper pick and is perfect for something slightly unique without breaking the bank by hiring a designer for a fully custom design.

Modal buttons with Liquid Glass

Someone noticed users were tapping the checkmark in the top-right corner of modals instead of his custom Post button. This started happening after the Liquid Glass update.

This is occurring because Hotwire.config.showDoneButtonsOnModals = true will automatically add the “done” button to the upper right of every modal. But on iOS 26+, this becomes a check mark!

The best solution here is to implement a FormComponent that adds a native button that disables while the form is submitting.

PurchaseKit questions

Someone asked about PurchaseKit, which I launched earlier this month.

The short version: iOS and Android packages plus a Ruby gem that handle in-app purchases. You write your paywall in ERB, the native packages handle StoreKit and Play Billing, and webhooks keep your Rails database in sync.

It is free for up to 10 paying subscribers, then $99/month. If you are interested, check it out! Oh, and if you create an account in January, I’ll personally onboard you.

What’s next?

Next month’s office hours is on Thursday, February 5. Paid subscribers get access to the live call and can ask questions in real time.

If you have a topic you would like me to cover, leave a comment or reply to this email!

Say hi to PurchaseKit: in-app purchase infrastructure for Hotwire Native apps.

You can now add subscriptions to your Hotwire Native app without writing any native code or worrying about keeping your database in sync with Apple and Google.

I’ve been adding some version of this to client apps for years. And every single time, it’s a huge pain for me and my clients. StoreKit on iOS. Play Billing on Android. Webhook verification. Receipt validation. Subscription lifecycles…

And the worst part? Keeping your Rails database in sync with what Apple and Google think the subscription status is.

I’ve talked to so many developers who don’t go native specifically because they don’t want to deal with this stuff. Apple and Google require in-app purchases for certain apps, and the complexity just isn’t worth it.

So I finally built something generic that everyone can use. I’ve launched over 25 Hotwire Native apps. This is the billing infrastructure I use.

How it works

Native packages for iOS and Android (bridge components) handle the purchase flow. StoreKit 2 on iOS, Play Billing on Android. Your Rails app never touches the native payment sheets directly. And you never touch the native code.

You write your paywall in ERB. Style it like the rest of your app. And because it’s server-rendered, you can deploy pricing experiments without pushing new binaries to the app stores.

<%= purchasekit_paywall customer_id: current_user.id do |paywall| %>
  <%= paywall.plan_option product: @annual, selected: true do %>
    Annual - <%= paywall.price %>/year
  <% end %>
​
  <%= paywall.plan_option product: @monthly do %>
    Monthly - <%= paywall.price %>/month
  <% end %>
​
  <%= paywall.submit “Subscribe” %>
<% end %>

Webhooks are normalized and forwarded to your Rails app. Apple and Google send completely different webhook formats. PurchaseKit normalizes them into one consistent structure before forwarding to your server.

Your subscription data lives in your database. Not on Apple’s servers. Not on Google’s servers. In your database, right next to everything else.

PurchaseKit keeps everything in sync via webhooks. When a subscription renews, cancels, or expires, your database updates automatically. If you’re using Pay, it creates and updates Pay::Subscription records. If not, use event callbacks to handle it however you want.

PurchaseKit.configure do |config|
  config.on(:subscription_created) do |event|
    user = User.find(event.customer_id)
    user.subscriptions.create!(...)
  end
end

Your current_user.subscribed? checks just work. No API calls. No stale data.

Pricing

I’m launching PurchaseKit with a free tier so you can try it out and validate your idea before paying anything.

Free - Up to 10 paying customers for 1 app. No credit card required. This is enough to build your paywall, test the full flow in sandbox, and launch to real, paying users.

Pro ($99/mo) - Unlimited paying customers for up to 3 apps. For most indie developers and small teams, this is the plan.

Business ($399/mo) - Unlimited everything, plus concierge onboarding where I personally help you get set up.

January launch offer

I want to make sure early adopters have a great experience. So here’s the deal:

If you create an account in January, I’ll personally onboard you. We’ll do a video call to set up your iOS, Android, and Rails code. We’ll walk through App Store Connect and Google Play integration. You’ll walk away with a working paywall in your app.

This is normally a Business tier perk ($399/mo). For January, it’s free. Even on the Free plan. Just reply to this email to get on my calendar.

Next week I’m publishing a deep dive on in-app purchases: all the moving pieces, the gotchas, and why this stuff is so tricky. It’ll give you a much better sense of what PurchaseKit handles under the hood.

For now, check out PurchaseKit and let me know what you think.

Questions? Just reply to this email. I can’t wait to see what you build!

Join me this Thursday, January 8 at 10am PT, for Hotwire Native office hours.

These sessions are only available to paid newsletter subscribers.

Bring your questions, share what you’re working on, or just drop by to say hi.

They’re a great way to connect with other developers building with Hotwire Native.

Last month I held office hours at a special time for our friends in Australia, and it ended up being one of the most fun, wide-ranging sessions we’ve had all year. We dug into everything from Bluetooth sleep trackers to tab reloading strategies to whether going “fully native” is actually worth it.

I’d love to see you there! Zoom and calendar links below for paid subscribers.

Read more

Sometime this fall, I noticed something I hadn’t planned: money was coming in that had nothing to do with my calendar.

Not a lot. Consulting still pays the bills. But for the first time in my career, it wasn’t the only thing. A book sale here. A library purchase there. A few paid newsletter subscriptions trickling in.

None of it was life-changing on its own. But together? It felt like proof that maybe, just maybe, I could build things that work without me. Here’s what each one taught me.

Creating is easy. Polishing is the real work.

My book taught me that creating is easy but polishing is the real work.

Writing came naturally. I could bang out chapters without much friction. But editing? Revising? Working with my editor to turn rough ideas into something actually publishable? That was brutal.

I’m so grateful to the team at Pragmatic Programmers for pushing me through it. But wow, the gap between a draft and a finished book is enormous.

People will pay for solutions, not just my time.

My Bridge Component library taught me that people will pay me for solutions, not just my time.

This was my first paid product for developers, and people are actually buying it! What I love most: it’s a one-time purchase, not a subscription. And so many of the ideas come from client projects. There’s something deeply satisfying about packaging what I learn into something the whole community can use.

My words have value beyond code.

My paid newsletter taught me my words have value beyond code.

This one surprised me the most. I knew people would pay for my consulting. But paying for my writing? For my perspective on building apps, running a business, being a parent while doing all of it? That still feels a little surreal. And it’s pushing me to explore more business, parenting, and solopreneur content in 2026.

Visibility creates its own momentum

My keynote at Rails World taught me that visibility creates its own momentum.

Mind-blowing is the only word for it. Giving a keynote at Rails World opened doors I didn’t know existed. Huge thanks to Amanda and the Rails Foundation for the opportunity. And honestly? I kinda love being on stage. But it’s a lot of work.

Looking back

A book people buy. A library people purchase. A newsletter people subscribe to. A keynote that lives on YouTube. What??

I didn’t plan any of it. I just kept saying yes to things that scared me.

And now, finally, I have the foundation of a business that can bring in revenue while I’m playing LEGO with the kids.

What about you?

What did you say yes to this year that scared you? I’d love to hear about it, leave a comment and let me know.

Here’s to more showing up in 2026! 🥳

Here’s a recap with the highlights and the lessons you can apply to your own apps.

A real-world Bluetooth integration with Hotwire Native

Adam Pallozzi kicked things off with a deep dive into a feature from SleepHQ: a pulse-oximeter ring that streams data through the phone overnight. It’s one of the most complex Hotwire Native integrations I’ve seen, a native Bluetooth service working alongside a Rails UI.

But there’s one issue Adam hasn’t been able to figure out just yet, iOS keeps killing the process during long background sessions, breaking the Bluetooth connection.

We talked through a few possible approaches:

• Enabling the “Acts as a Bluetooth LE accessory” background mode

• Using background processing or silent push notifications to keep the app alive

• “Playing audio” to keep the web view from sleeping

This last one is interesting. Have you ever locked your phone to see audio playing on your Lock Screen? Even though you weren’t actually listening to anything?

Turns out, this is a trick hack to keep the web view alive! If done correctly, with all the right background modes, continuously playing audio can sometimes leave the web view alive indefinitely. Of course, it isn’t documented, and definitely not recommended, but it is an interesting idea for this scenario.

It was a great reminder that Hotwire Native doesn’t magically eliminate all native challenges. But it gives you flexibility to mix native services with a mostly Rails-driven UI. All five steps of the Bluetooth connection processes were rendered with HTML!

The tab refresh problem after authentication

Shawn asked one of the classic Hotwire Native questions: What’s the best way to refresh tabs after someone logs in or signs up?

Right now we have a few options:

1. Call load() again on the HotwireTabBarController

2. Ideally, iterate through each Navigator and manually reload them

   1. Sadly, HotwireTabBarController (yet?) doesn’t expose that

3. Add a “stale” flag so the tab refreshes the next time it appears

Adam shared how Sleep HQ tackles this by reloading the entire path configuration when users switch between “patient” and “clinician” modes. It works, but it’s heavy-handed. On Android, there’s an additional constraint: you simply can’t have an unlimited number of tabs.

For Jumpstart Pro, we’ve moved away from path configuration for tabs entirely. Instead, we send a dynamic JSON structure down to a bridge component, the same approach I outlined in my authentication deep dive. It gives you control without rebuilding the whole navigation stack.

“Do you have a starter kit for new apps?”

Jesse asked whether there’s a Rails + iOS + Android template that people can use as a starting point.

And I’ve tried… many times. Six, at least. Templates are great until they aren’t! They fall out of date the moment Rails or Hotwire or Xcode moves forward.

The pattern that has consistently worked for me is:

• Keep a repo with multiple branches representing different “starting points”

• Write generators that you run after creating a new Rails app

This gives me 90% of the value of a template without locking into something brittle.

Going “fully native” vs staying with Hotwire Native

I also shared a little experiment I’ve been working on: I rewrote the hiking app from my book in pure SwiftUI. The goal was to compare the experience head-to-head.

Here’s what I learned:

• Visually, the difference is tiny, in many cases you couldn’t tell which is which

• The native version requires significantly more code

• Error states and loading transitions are easier to customize natively, but not enough to justify the effort unless you truly need it

• Mixing in native screens when necessary (e.g., Bluetooth, camera, biometrics) is still the sweet spot

In other words: if you’re building an app whose UI comes from Rails anyway, Hotwire Native continues to be the fastest path, even if you know SwiftUI well.

We also talked about custom loading and skeleton screens. You can do this by inflating JavaScript-driven views early, or by putting the whole app inside a Turbo Frame remote and swapping in real content after it loads. Adam shared a clever technique where he checks whether a page is cached before showing the skeleton, avoiding the “flash” when navigating back.

A great way to wrap up the year

This session had everything I love about office hours: real problems, real apps, and everyone openly sharing what’s worked (and what hasn’t). Huge thanks to Adam for the Bluetooth demo, to Shawn and Jesse for great questions, and to everyone who joined from far-off time zones.

The next session is scheduled for January 8, 2026. I hope to see you there!