A huge nod to Equipe for making this possible. They recently migrated their 10+ year-old Hotwire Native app to Ruby Native. And with close to a million downloads over the last decade, they started contributing the majority of the active devices running Ruby Native apps.

This milestone feels a bit surreal for me. The first commit to Ruby Native was only in February of this year. Back then I just had a lofty dream of making mobile apps easier for Rails developers. But now? Real businesses are trusting Ruby Native. Equipe is no side project. It’s a profitable business supporting a huge portion of the equestrian events across Europe.

Right before I went on leave, I published a case study on how and why Equipe migrated. Check it out on Ruby Native. Jon, the founder of Equipe, went from having to hire contractors for every native update to running native builds and deploys himself. He even said “The app has never felt so good on Android. Love this.”

One of the big reasons Jon, a self-described “Rails guy,” is able to do this himself is thanks to Herb. Bundled with the Ruby Native gem is a check command. It traverses your views looking for Ruby Native calls like native_navbar_tag and native_haptic_data. Because Herb can process/analyze ERB, the check command can actually walk the AST and find bugs before you deploy. For example, having multiple “navbars” doesn’t make sense, but isn’t exactly a compilation error.

➜ bundle exec ruby_native check
app/views/books/index.html.erb
  17:  warning 2 elements carry `data-native-navbar`; only the first one is used.
​
Checked 18 templates: 0 errors, 1 warning.

The most important check is that if you hook up your Ruby Native account, it can tell which native version you last deployed with. So if you try to add a Ruby Native feature that your users don’t yet have access to, it will spit out an error to update your native version.

➜ bundle exec ruby_native check --deployed
app/views/books/new.html.erb
  5:   error   `data-native-keyboard-toolbar` needs 0.15.0, your ios build is 0.14.2
​
Checked 18 templates: 1 error, 0 warnings.

This takes a huge amount of stress off of Rails developers’ shoulders. It means they can reliably and safely adopt Ruby Native features without worrying about breaking things, backwards compatibility, or accidentally using unsupported features. You can even hook it into your CI pipeline as a step to ensure it blocks a release if the check fails!

And the proof? Equipe is reporting less than 0.01% of users experiencing crashes across both platforms.

My long-term goal is to make mobile development easier and more accessible for Rails developers. And it’s hard to find a better example than this. A Rails founder is now running their mobile apps without stepping outside of Ruby. And doing it with confidence.

I’m proud of where Ruby Native has gone and I’m even more excited about what’s next. Being a finalist in the Ruby Runway at RubyConf was where it started to feel real. But now it’s like I have proof.

Enjoy Rails World later this month if you’re going. I wish I could be there!

One of the biggest trade-offs of working for myself is that I can take as much time off as possible for life events like this. The downside? It’s unpaid. Most of my income is from active engagement with clients: building apps, advisory work, or maintenance retainers. Which means, if I’m not working, I’m not making money!

Yes, there’s an exception with the “passive income” products I run. Most notably, Ruby Native. But those are annual plans, so I’m not seeing any recurring revenue until mid 2027. Unless, of course, someone signs up for an account! Speaking of, I just went through a huge audit on the codebase, hardening it for me not being around for a little while.

So, what does that mean for the newsletter? In short, you probably won’t hear from me until 2027. So I’ve gone ahead and paused paid subscriptions for now. This means that if you are a paying subscriber you won’t be charged a renewal. I’ll make sure to let everyone know in advance before I turn them back on, so you’ll have time to decide if you want to continue your subscription or not.

What about outside of the newsletter?

• Ruby Native cloud builds and deploys run without me, that was the goal and it’s achieved!

• Bridge Components buyers have everything but updates pause while I’m out.

• The Discord stays up but I’ll be slow to respond to individual messages. I’m grateful for folks in the community stepping up and helping others.

• General support waits until January.

• Urgent requests (e.g. “production is down”) will be addressed as quickly as I can manage. Just be aware I might have a screaming baby on the call with me. 😅

What can you expect from me, and this newsletter, when I return in January? First up will be an honest review of my 2026. This was the hardest year of my consulting business since I went independent in 2020. And I’ve had to adjust a lot in the past six months. I think I’ve found some things that might work in the future but I’d be lying if I said I have it all figured out.

The next four months are going to force me (in a good way!) to go on a lot of walks. I’m hoping to use that time to really figure out what I want next from my business. And which direction I want to take it. Most importantly, how can Masilotti.com go back to being a sustainable business, instead of always cramming an entire year of work into two months.

If you have thoughts, or ideas, or things to share… hit reply. Seriously! I would love to hear them. 👋

1. Reusable base project that can be pointed to any Rails app

2. App styling, tabs, and navbar buttons driven from the server

3. Handle both authenticated and unauthenticated users

4. All logic and functionality contained in a single Swift file

5. No need for other developers to write any Swift code

I was excited enough at the time to leave a comment: “Amazing work here! EVERYTHING is configurable via the Rails code without needing any Swift.”

First, take a look at the cute little avatar. Remember my Mii? 😅

But that was five years ago, and I haven’t stopped thinking about that list. Four of the five goals describe what I’ve been building. Honestly, almost exactly.

The one I’d change is number four. All the logic and functionality shouldn’t live in a single Swift file. It should live in your Rails app, and you should never have to look at the Swift at all.

I’m the Hotwire Native guy

I’ve been Hotwire Native’s biggest advocate since the day it was released. I wrote Hotwire Native for Rails Developers for The Pragmatic Bookshelf and I’ve built more than 30 apps with it.

But I still think it asks too much of a Rails developer. Working through the book means writing Swift and Kotlin, keeping a Mac configured with Xcode, and debugging in the simulator. Every sharp edge that Rails spent two decades removing from web development comes right back.

Which is a fair price… if your goal is to learn mobile development. But for most Rails developers, the goal is to get in the App Store!

Those 30+ apps taught me a few things, but most importantly, they all come down to the same 95%:

• a native tab bar

• a nav bar with a button or two

• push notifications

• a little native UI on top of the web views you already have

The last 5% is real custom work. But in my opinion, that 95% shouldn’t require writing any native code at all.

Everything driven by your Rails app

Ruby Native is what I wish Hotwire Native actually was. No mobile experience, Mac, or Xcode required. Everything is driven by your Rails server.

And by everything, I mean everything. New pages, new content, native buttons, push notifications, deep links, in-app purchases, and more. You deploy your Rails codebase like you always have and the native app picks up the changes immediately. The goal is for the iOS and Android apps to never need an update again.

Because native UI is rendered by your views, it follows your business logic. Here I’m adding a native button based on the user’s role in the system:

<%= native_navbar_tag “Orders” do |navbar| %>
  <% if current_user&.admin? %>
    <%= navbar.button “Export”, icon: "share", href: export_orders_path %>
  <% elsif current_user %>
    <%= navbar.button “New order”, icon: "plus", href: new_order_path %>
  <% else %>
    <%= navbar.button “Sign in”, href: sign_in_path %>
  <% end %>
<% end %>

Admins get an Export button, signed-in users get New order, and everyone else gets Sign in. None of this business logic lives in the native codebase. It stays in Rails, instead of being split across iOS and Android, or React and React Native.

But… AI writes Swift now

So if AI writes native code, who cares what language the native layer is in?

Honestly… fair. Point Claude at my book and it will scaffold a Hotwire Native app that isn’t far from what I’d write by hand.

But writing the code was never the hard part. It’s all the other stuff. AI can hand you a working Swift codebase, but it can’t get that codebase onto the phone in your pocket.

Then come signing certificates, App Store Connect, version numbers, screenshots… Don’t forget to do it all over again for Google Play! My book barely touches that part, because each app store could be its own 200+ pages.

Ruby Native handles all of this for you. Connect your App Store account with one API key and Ruby Native signs, builds, screenshots, and distributes your app for you. Everything that’s a pain in the butt for a Rails developer is just, well, handled.

Keep writing Ruby

I don’t want a Rails developer to have to learn Swift to launch in the App Store, or Kotlin to launch on Google Play, or to maintain three codebases when one has been paying the bills all along. I want them to keep writing Ruby, push to production like they always have, and watch their app update itself.

That’s what I wish Hotwire Native was. So I built it: rubynative.com

v0.12 officially brings Android out of beta. If you already have a working iOS app with Ruby Native, then you’re ready for Android. Few to no changes are needed in your Rails codebase to support the new platform.

With the exception of in-app purchases, Ruby Native on Android can now do everything the iOS version can do. This includes cross-tab links, back-button history, share buttons, form handling, and push notifications.

Outside of Android support, a bunch of other improvements have launched in the past few weeks.

Securely sign out users

Add the following line to your layout and Ruby Native will securely reset the app when your users sign out:

<%= native_identity_tag current_user&.id %>

Check out the full authentication documentation for how this behaves in different scenarios and how to configure it if you have accounts or teams (and not just users).

Scan barcodes

Another big feature available on iOS and Android is barcode scanning. Add some markup to your form to trigger a native, platform-specific barcode scanner flow:

<%= form_with url: lookups_path do |form| %>
  <%= form.text_field :isbn, id: "isbn" %>
  <%= native_scan_button_tag "Scan", target: "#isbn" %>
<% end %>

Add submit: true to submit the field’s form automatically after a successful scan, for example when scanning a book’s barcode and running a search against it on your server.

Customize the navigation bar

You can now further customize the navigation with title menus, segments, and branding.

Turn the native title into a dropdown menu with position: :title. Tapping the title opens the menu, and the selected item shows a checkmark.

<%= native_navbar_tag "Inbox" do |navbar| %>
  <%= navbar.button position: :title do |menu| %>
    <%= menu.item "Inbox",
        href: inbox_path,
        icon: "tray",
        selected: true %>
​
    <%= menu.item "Archive",
        href: archive_path,
        icon: "archivebox" %>
  <% end %>
<% end %>

Add native segments with navbar.segment to quickly switch between contexts without leaving the current screen.

<%= native_navbar_tag do |navbar| %>
  <%= navbar.segment "Today", href: today_path, selected: true %>
  <%= navbar.segment "Upcoming", href: upcoming_path %>
  <%= navbar.segment "Anytime", href: anytime_path %>
<% end %>

Or completely customize the branding of the navigation bar with a background color and logo.

appearance:
  navbar:
    logo: "<%= image_url(’logo.png’) %>"
    background_color: "#3B3F54"
    foreground_color: "#FFFFFF"
    status_bar: light

What’s next?

Up next is building in-app purchase support for Android. From there, I’m planning on doing a bit of experimentation. Without giving away too much, what if Hotwire Native worked with Inertia?

Hit reply if you want a sneak peek! Until then, you can start building your own mobile apps with Ruby Native.

And that’s just for iOS! Here’s the stuff that matters, including the breaking changes you’ll need to accommodate in your app to upgrade today.

iOS

iOS saw the majority of the work this release, mostly focused on adding customization options to the included native pieces and reaching API parity with Android.

Lazy loading native tabs

Native tabs can now be lazy-loaded, meaning launching the app won’t hit your server with 5+ network requests. When enabled, each tab’s content loads the first time the user opens it. Note that this is a breaking change, as it was moved from Hotwire.config.lazyLoadTabs.

HotwireTabBarController(lazyLoadTabs: true)

Search tabs

For users running iOS 26, you can use the new UISearchTab to show a floating tab off to the right. Tapping this opens the tab’s content as usual. The only difference is the special placement.

HotwireTab(
    title: “Search”,
    image: UIImage(systemName: “magnifyingglass”),
    url: URL(string: “...”)!,
    isSearchTab: true
)

Large titles

A long-awaited fix for “large titles” was also merged, enabling proper behavior when customizing the navigation controller used by Hotwire Native.

class CustomNavigationController: HotwireNavigationController {
    override func viewDidLoad() {
        super.viewDidLoad()
        navigationBar.prefersLargeTitles = true
    }
}
​
Hotwire.config.defaultNavigationController = { CustomNavigationController() }

Custom error views

Native error views can now be fully customized, even with SwiftUI.

Hotwire.config.makeCustomErrorView = { error, handler in
    AnyView(MyErrorView(error: error, onRetry: handler))
}
​
struct MyErrorView: View {
    let error: Error
    let onRetry: ErrorPresenter.Handler?
​
    var body: some View {
        // ...
    }
}

Also, TurboError is gone, replaced by a structured HotwireNativeError (HTTPError / LoadError / WebError), and a retry handler is now always supplied. So if you referenced those directly in your codebase you’ll need to update them.

There were also a bunch of bug fixes that were finally merged, including commits from six new contributors! Check out the full release notes for all the details.

Android

Android’s big improvement was the addition of lazy-loaded tabs, to match the behavior on iOS. There were also a lot of under-the-hood bug fixes and cleanup, including resolving some weird crashes that one of my clients was experiencing.

The only breaking changes for Android are around HotwireDestination.customRouteDecision() and some logging cleanup.

Hotwire.config.debugLoggingEnabled is removed, replaced by a pluggable Hotwire.config.logger. Set logger.logLevel = HotwireLogLevel.DEBUG for debug output. See the full release notes for more.

Demo app

The Hotwire Native demo app was improved to work with the new changes across both platforms and now acts as a test bed for reproducing bugs. This should make it a bit easier for me and the other maintainers of Hotwire Native to identify and fix issues faster.

If you upgrade to v1.3 and run into any issues please let me know. I’m sure v1.3.1 isn’t far behind!

P.S. Who’s heading to RubyConf next week? I’m hosting a Ruby Native workshop on Wednesday and I’d love to meet you IRL! Hit reply and let me know so we can grab a beverage together.

I’m feeling the same with Ruby Native right now.

Aaron’s point is that the list of things to build never ends. But the part he didn’t get into is that reaching the end was never the goal. Knowing what to skip is.

Last week I signed a Concierge client to take their Rails website to mobile. I’m in charge of everything, from setting up Ruby Native to tweaking their design to work better on mobile, to adding native components when it makes sense, to submitting to the App Store and dealing with App Store review. Essentially, they are paying me to do 100% of the “get us in the App Store” work.

This isn’t too different than what I’ve been doing for 6+ years for Hotwire Native. With those clients, they’d have the exact same need: get in the App Store. But back then, every single client was a unique, bespoke build. If they wanted specific native components, then those would be built on the fly, just for them.

Sometimes I could abstract or borrow from my bridge component library, but oftentimes they were just different enough that I had to build something from scratch. But as always, the code was never the hard part. It’s always about the other stuff: what to build, where to integrate it, and how to get it live (App Store approval is still no joke!).

Seeing this client go through the process, and me slowly tweaking their app to look and feel better (which I can’t wait to share as a case study when they go live!), has expanded the Ruby Native roadmap even more. From just three days of working with them I’ve noticed some common patterns that would make their app feel so much more native. And could easily be abstracted to work with other customer apps.

But every one of those patterns I abstract is one more thing to build. As I work with more folks, and as more developers get their hands on the Ruby Native apps, the feature requests and obvious niceties are growing. My public roadmap hasn’t shrunk since I announced it. 😅

There’s a point where Ruby Native can do almost the entire native stack, entirely driven by HTML. The decision stops being “is this custom enough to go Hotwire Native?” and becomes, just go Ruby Native, it will (almost) always be enough.

And maybe that’s OK! Sure, it gives me a bit of anxiety to never close out a todo list. But it also means there’s always something new and exciting to work on. And with AI? It makes the what even more important. I could technically build every little thing a (potential) customer asks for. But at what point does it start to dilute the primary purpose of Ruby Native? At what point does it become such a complicated tool that it’s hard to add new code? Or worse, that it becomes confusing to the developer trying to build with it?

That’s a tough call. And a lot of folks online will say it’s where someone’s taste comes into play.

I like that word, but I also think it’s a bit loaded. I prefer to think of it as a solid product vision. Knowing exactly what your product or service does is almost as important as actually doing it. For me, that means having a north star that I build everything around: making it easier for Rails developers to get in the app stores.

Following this for every new feature almost makes the decisions easier. Someone recently asked if Ruby Native could be a package, like Hotwire Native, that you drop into your own codebase. It’s a fair question, but it runs against the whole point of Ruby Native: I never want a Rails developer to have to touch native code.

But a new API just dropped on iOS that makes it easier to do something? Obvious yes! Wire it up to some HTML-powered API and boom, every Ruby Native developer gets it for free the next time they deploy.

Perhaps the expanding road isn’t the problem I made it out to be. The north star doesn’t make the list shorter, it tells me which items to ignore. And that, as a solo-run business, is the most important thing.

But there’s one question the north star can’t answer. Building new features doesn’t bring in customers. I know this and every developer “knows” this. The north star tells me what to build, but it can’t tell me when to build it. Or when to write a case study, or when to do cold outreach, or when to start paid advertising, or... well you get the idea: sales and marketing!

So, if the road expands before me, is that good? Is that bad?

If you know, please tell me. Because I sure don’t know yet!

Leave a comment

I used to religiously track where I spent my time when on my computer. Client work in one bucket, personal branding in another, and side projects/adventures in a third. Inside of those, I would then categorize which engagement/project I was working on.

At the end of the year, it was awesome! I had this huge breakdown of where all of my time went. I could even cross-reference it against what each thing made money-wise and figure out my effective billable rate. Which sometimes was super empowering. But for side projects? Super depressing. :P

I’ve launched more than a handful of “things” that made no money at all. And spent a ton of time working on them.

As time went on, I found myself taking a few seconds to pick which project to bill time to. “Ok, let’s go build this thing!” “Oh, let me track time first.” “Hmm, is this personal branding? Marketing? A side project that I haven’t solidified yet?”

That additional context switch (on top of the actual one) could often kill the idea I had in my head. Before I even started working, I all of a sudden had an admin task to take care of.

And sure, I could do it after the fact. So I started just clicking “start” without assigning a project in my time tracker. Which worked pretty well! But then I would forget entirely. Or even worse, switch tasks and now had to make two decisions (old work and new work).

I eventually realized that it was costing me more time and, more importantly, mental energy, to keep this up than the payoff was worth.

So in 2026, I completely stopped tracking my time. And it has been the most freeing thing I’ve ever done for my business.

When an idea sparks, I just... do it. When I want to context switch, well, I context switch!

And with AI-assisted development? It means I can bounce around like all freaking day working on whatever I want without any repercussions!

Except… not exactly.

Now I’m bouncing around all the freaking time. Why work on one thing when I could work on ten things?! Why limit my creativity to a single project that doesn’t make money when I could be building twenty things that don’t make money?!

And so on and so on.

Turns out, the friction I felt around picking one thing may have actually been beneficial. Perhaps it was actually helping me stay focused. Even if it cost just a bit of extra time before I sat down and worked.

I’m not sure if AI caused this or just threw lighter fluid on an existing fire. But whatever it is… damn is my brain fragmented.

I feel like I’m getting so much done. But also so mentally exhausted at the end of the day.

I also really want to work… more? It’s quite a feeling. And maybe all this is just my ADHD getting dopamine hit after dopamine hit when I’m working with Claude.

Or maybe this is just the new way of working?

Hey friends,

Ian Landsman posted something recently. And at first, I totally dismissed it. “Old man yells at cloud!” I was saying in my head.

He ripped every WebSocket call out of his app, moved to polling the server, and said everything just works better. “Sometimes the old ways are the best ways.”

But for some reason… it stuck with me. Probably because I’d been doing the exact opposite all over my own dashboard, and had been bitten by it twice.

A customer paid for a subscription and got dropped on a dead-end spinner that never resolved. The payment went through, Stripe was happy, but the page just never heard about it. A few days before that, someone breezing through onboarding missed a single broadcast and got stuck on a step that never advanced.

So I (begrudgingly) followed Ian’s lead and started deleting. Here’s the whole story, plus something I picked up only after the code was gone.

I was broadcasting everything with Turbo Streams

The dashboard for Ruby Native does a lot of waiting on background jobs. It validates your App Store Connect credentials, checks whether your beta testers got added, watches a build move through GitHub Actions, confirms an in-app purchase webhook, and validates a Stripe subscription.

Every one of those started the same way: a background job did its work then broadcast the result to the page over Turbo Streams. Add an after_commit on the model, a turbo_stream_from in the view, and the result appears without a refresh. It’s the default UX in Hotwire, and it feels great when you wire it up.

The problem is what happens when the broadcast doesn’t land.

Broadcasts are fire and forget

A Turbo Stream broadcast is a single message pushed down an open socket. If nobody’s listening at that exact moment, it’s gone. There’s no retry or catch-up.

There are two easy ways to miss one. The first is a race: the job finishes and broadcasts before the browser has finished subscribing to the channel, so the message goes out to an empty room. The second is simpler, and way more likely: the connection blips, the message is lost, and nothing ever asks for it again.

Either way the page sits there. And on a few of these screens the spinner was the default state in the database, so when the result never arrived, nothing ever replaced it. The page wasn’t mid-update, it was stuck, forever, behind a sad little “try refreshing” link I’d bolted on as a patch.

That patch is what bothered me. If the answer to “my real-time UI didn’t update” is “ask the user to refresh,” then the real-time part isn’t carrying its weight, no?

What if the dashboard just… asked?

So I asked myself a question I probably should have asked at the start. Is pushing just overkill for a dashboard?

A dashboard isn’t a chat app. The updates I care about land seconds (sometimes minutes!) apart, not milliseconds. Nobody needs sub-second delivery to find out their credentials validated. What they need is for the page to be correct, and to recover on its own when something goes wrong.

The database already knew the truth the entire time. Broadcasting was just trying to mirror that truth into an open socket and occasionally missing. So I flipped it around. Instead of the job pushing the result out, the page re-asks the server “what’s true now?” every few seconds, and stops asking as soon as it has its answer.

Move the transient state into a row

The first piece is giving each async step somewhere durable to record what happened. I added one small model, OnboardingCheck, with a row per app per step. It holds only the transient state of the last attempt: whether a job is in flight and the error if one came back. The authoritative “this step passed” signal stays where it always lived, on the parent record, App.

class OnboardingCheck < ApplicationRecord
  belongs_to :app
​
  # How long a stamped checking_at counts as “a job is in flight” before
  # the page assumes the worker died and re-runs the check on the next poll.
  CHECK_TTL = 2.minutes
​
  def checking?
    checking_at.present? && checking_at.after?(CHECK_TTL.ago)
  end
​
  def start!
    update!(checking_at: Time.current, error: nil, reason: nil)
  end
​
  def finish!(error: nil, reason: nil)
    update!(checking_at: nil, error:, reason:)
  end
end

The job calls start! when it kicks off and finish! when it’s done. Notice what that buys you: the error is now persisted. A failure survives a refresh, where before it lived for one broadcast and then vanished.

CHECK_TTL is the escape hatch. Since these checks should finish in a second or two, a checking_at older than two minutes means the worker died before reporting back, so the next poll re-runs the check instead of leaving the user stuck on a spinner.

A frame that reloads itself until it’s done

The second piece is a Turbo Frame that polls. While a job is in flight, the frame renders a small Stimulus controller that reloads the frame on a timer. When the result lands, the re-render simply leaves that controller out, and the polling stops on its own.

<%= turbo_frame_tag “subscription_status”, src: confirm_checkout_path(@app) do %>
  <% if @app.active_subscription? %>
    <%= render “checkouts/subscription_confirmed”, app: @app %>
  <% else %>
    <p>Waiting for payment confirmation...</p>
    <div data-controller=”poll” data-poll-interval-value=”3000”></div>
  <% end %>
<% end %>

The controller is about as small as it gets.

// app/javascript/controllers/poll_controller.js
import { Controller } from “@hotwired/stimulus”
​
export default class extends Controller {
  static values = { interval: { type: Number, default: 5000 } }
​
  connect() {
    this.timer = setInterval(() => {
      this.element.closest(”turbo-frame”)?.reload()
    }, this.intervalValue)
  }
​
  disconnect() {
    clearInterval(this.timer)
  }
}

This is the part I find genuinely tidy. The controller only exists in the DOM while there’s work to wait on. The moment the success partial renders instead, the controller’s element is gone, Stimulus fires disconnect(), clearInterval runs, and the polling ends. There’s nothing to remember to tear down.

I wrapped that pattern in a poll_frame helper so every surface shares it, but the mechanism is exactly the two snippets above.

Three things that bit me

If you try this, here are the gotchas I hit so you can (hopefully) avoid them.

A self-referencing src makes Turbo complain. A frame whose src points at the same URL it’s already showing gets rejected. On the polling re-render I leave src off and let the frame keep the one it was born with. The Stimulus reload() still re-fetches that original src just fine.

Polling isn’t free when a poll hits an external API. My build feed re-renders each app’s Google Play status, and that’s a real API call, not a database read. Left alone, polling would quietly hammer Google’s rate limit. To fix this, I cache that lookup for 30 seconds, and force a fresh read only right after a rollout so the result still shows up immediately.

Links inside a polling frame need an escape hatch. By default a link inside a Turbo Frame tries to navigate that frame, and any link to a page without a matching frame id throws Turbo’s “Content missing.” Set target: "_top" on the frame so links and forms do a normal full-page visit. The frame’s own reloading is unaffected.

And one decision worth making on purpose: what should a 500 do? I made errors during the flow bubble up and stop the polling, so the user sees that something broke and knows to refresh. A failure you can see beats a failure that hides behind a spinner.

The lesson wasn’t really “polling”

The reliability didn’t come from polling. It came from rendering off the database every single time.

A poll tick and a broadcast are both just “go show the current state.” The difference is that polling has no choice but to recompute from the source of truth, while a broadcast lets you push the rendered change and skip that step. That skip is exactly where the spinner bug lived!

Which means I didn’t strictly have to drop the socket. If each broadcast had only said “something changed, re-fetch” instead of carrying the result itself, the page would recompute from the database and heal the same way. That’s more or less what Turbo 8’s broadcast_refresh and morphing do: the broadcast says “re-render,” and the morph reconciles against fresh server HTML. You get push’s snappiness with polling’s self-healing.

I still went with polling, because a dashboard doesn’t need the snappiness and polling makes that recompute-from-truth discipline automatic instead of optional. But that’s the rule I’m keeping, and it’s the sharper version of Ian’s point: pick your transport for how fast and how wide you need to push, and render from durable state no matter what. Push a hint, not a delta.

I didn’t delete Action Cable

To be clear, I didn’t rip WebSockets out of the building. solid_cable is still mounted, and a couple of genuinely live surfaces still push. Polling isn’t automatically the better tool.

It’s the better tool here, on a dashboard where the database is the source of truth and “a few seconds late” is completely fine. If I were building live chat or a collaborative editor, I’d still reach for push without thinking twice.

The mistake wasn’t using broadcasts, it was using them as the default for everything. Like the checkout page where a single lost message left a paying customer staring at a spinner.

Thanks for the nudge, Ian. Turns out the old ways really are the best ways.

Where have you reached for a broadcast when a poll, or a plain re-fetch, would have done the job? Hit reply and let me know!

Anyone can upload a binary. Passing review in both stores, for a paid app, is the bar that says “this is a real app.” This is where most “we’ll get to mobile later” projects collapse, and it’s the bar Ruby Native had to clear if any of the pitch mattered.

pingrb isn’t the only one. Ender Ahmet Yurt shipped Foxance to the App Store with Ruby Native earlier this month. Two builders, three store listings, and absolutely zero native code between the two of us.

What pingrb does

pingrb buzzes your phone when something matters on the projects you run. A Stripe payment lands. A Hatchbox deploy fails in the middle of the night. Honeybadger catches an exception. cal.com books a meeting. I run a handful of side projects and I wanted a push notification when something worth knowing about happens. So I built the app I wanted but couldn’t find.

Here’s how

Here’s pingrb’s entire native configuration:

# config/ruby_native.yml

tabs:
  - title: sources
    path: /sources
    icons:
      ios: list.bullet
      android: format_list_bulleted
  - title: devices
    path: /devices
    icons:
      ios: phone
      android: smartphone

That’s it. Both platforms read the same file. The Rails app is the only place I wrote code; everything else is configuration.

For the native behaviors that need to live in a view, Ruby Native gives you Rails helpers. The navbar on the sources screen looks like this:

<%= native_navbar_tag title: “Sources” do |navbar| %>
  <% navbar.button icon: “gearshape”, path: settings_path %>
  <% navbar.button icon: “plus”, path: new_source_path %>
<% end %>

That renders a real UINavigationBar on iOS and a real Toolbar on Android. native_push_tag registers the device with APNs and FCM. There are a handful of helpers like these, and they go in your ERB the same way link_to does.

Here’s the part that still feels weird to say out loud:

Five days end to end, one Rails developer

Building the Rails app took a few days, which is where the actual product lives. Wiring it up to Ruby Native for iOS took three more, mostly icon-picking and getting push registration working. Android was a single morning of configuration. By that afternoon, the same Rails app was queued for review in the Play Console.

End to end, one Rails developer shipped a paid app to two stores. The “second codebase” problem doesn’t even apply, because it’s only a single codebase.

Speaking of which, the whole codebase is public. The Rails app, the Ruby Native config, and the view helpers all live at ruby-native/pingrb on GitHub.

Try it on your own Rails app

If you’ve been told a Rails app needs Swift, Kotlin, or a React Native rewrite to get into the stores, pingrb is the proof you don’t. So is Foxance. Two Rails developers, three store listings, in days not months.

Free TestFlight builds, no credit card, and you only pay when go live.

Try Ruby Native free →

Want to kick the tires first? Install pingrb from the App Store or Google Play, or read the full case study with the YAML, helpers, and tradeoffs.

A few weeks ago I wrote about how the hard part of my job moved. Less typing, more judgment. The work changed.

Here’s the part I didn’t say in that one: once the work changed, I had to change how I introduce myself.

The tiny niche

For years, my pitch was “I’m the Hotwire Native guy.” It was honest. I’d shipped 25+ apps on the framework. I wrote the book. I trained hundreds of developers. If you needed someone who knew Hotwire Native, it was me.

Owning a niche that small has a funny effect on your business. The leads are perfectly qualified. The conversion rate is high. Nobody else shows up in your inbox talking about the same thing. You feel like you have a moat.

You don’t.

The moat fills in

I published a book. That was good for readers and great for anyone who wanted to learn what I knew without hiring me. Fair trade. That’s the job.

I published free tutorials. Same deal.

Then AI showed up, and anyone could feed my content into Claude and generate 80% of what I used to deliver in a project. Not 100%. But 80% is enough for a lot of teams.

Turns out that moat was a puddle.

Jumping to a bigger pond

I had two options. Defend the niche by getting narrower (the Hotwire Native in-app purchases guy, the Hotwire Native push notifications guy), or expand what I sell.

I picked the second option.

I’m not the Hotwire Native guy anymore. I’m the person you call when your Rails business needs a mobile app.

That shift is small on the page and enormous in practice. Hotwire Native is how I do the work. It’s not what I sell. What I sell is everything around the code: deciding whether you even need a mobile app, choosing the right framework, mapping the App Store landmines, and knowing which tradeoffs will matter a year from now.

The code is a commodity. The decisions around the code are not.

What this looks like on a call

Last month a founder asked me for a mobile build. I told him he didn’t need a mobile app yet. He needed a mobile-friendly website, a working checkout, and six more months of product-market fit before he spent a dollar on anything native.

He didn’t hire me. He also didn’t spend $40k building the wrong thing.

That conversation isn’t one I could have had as “the Hotwire Native guy.” If your whole pitch is a framework and someone asks for an app, you say yes. If your pitch is “I help Rails businesses ship mobile apps,” sometimes the right answer is “not yet.” The clients I do take end up trusting me more because of it.

And that’s the work I actually want to be doing. A decade of pattern recognition, applied before a single line gets written.

For example, the engagement I’m most energized by right now is collaborating with a team on a hybrid mobile app that isn’t Hotwire Native. A year ago I’d have passed. Wrong framework? No thanks! Today it’s the most fun I’ve had on a client project in a long time. They aren’t paying me for Hotwire Native. They’re paying me for the 25+ apps that came before theirs, and the judgment of which decisions matter at their stage.

Why I’m telling you this

Two reasons.

First, if you’ve been reading this newsletter for a while, the shift will show up in what I write. Honestly, it probably already has. It means more business context, more strategy, and more “should you build this.” But a little less “here’s the Hotwire Native gotcha I hit on Tuesday.” Both still matter. The mix is different now.

Second, if you run a Rails business and you’ve been putting off mobile because you’re not sure what to build, that’s the conversation I’d love to have with you. Not a code review. The one before that.

If that sounds like the conversation you need, book a call. We’ll talk through what you’re building, what’s blocking it, and what the right next step actually is. No proposal slides, no fixed agenda. Just the conversation before the code.

And if you’re going through your own positioning shift, I’d love to hear where yours landed. Leave a comment and tell me what pond you jumped into.

Rewriting in Swift and Kotlin means two new codebases your team doesn’t know. Hiring an agency means $80k, six months, and an app that drifts out of sync every sprint. WebView wrappers feel like a chrome-less browser, and review rejects them without native components. React Native and Flutter add a third codebase in a third language that still doesn’t talk to your Rails backend natively.

You’re a Rails developer. Your team ships web features in days. Why does mobile take a year?

Hotwire Native is the closest anyone has gotten. It wraps your Rails views in a native shell, with native navigation and transitions between screens. I wrote the book on it. But it solves the rendering problem, not the shipping problem. You still have to open Xcode and Android Studio. You still have to learn enough Swift and Kotlin to be dangerous. And you still have to figure out everything that happens between “it runs on my simulator” and “it’s in the App Store.”

“But AI can write Swift now.” Sure. Claude will happily generate a UIKit view controller. It will not generate your Apple Developer account, your provisioning profile, your TestFlight build, or your review submission. And every time you ship a feature on the web, AI gets to write it three more times: once in Swift, once in Kotlin, once to keep the API in sync. A webview-based app gets all of that for free.

Whether you go fully native, hire it out, or use Hotwire Native, you still need Xcode and Android Studio. Apple Developer and Google Play accounts. Signing certs and provisioning profiles. A mobile CI pipeline. App Store Connect setup, TestFlight, beta groups. Swift and Kotlin bridge components. In-app purchases wired to your backend. Fresh screenshots, metadata, and review notes every release.

That’s the wall. It’s not the rendering, it’s the shipping.

Ruby Native is the layer that handles everything else. You add a gem to your Rails app, configure it with a YAML file, and run bundle exec ruby_native deploy. We build, sign, and ship the binary to TestFlight or the App Store. Native tabs, navigation, in-app purchases, and push notifications are all driven from your Rails views with a few helper tags.

Beervana is live on the App Store right now, and I never opened Xcode to ship it.

Today Ruby Native ships iOS apps. Android is in active development and coming next.

If you have a Rails app and customers asking for mobile then this is for you. Plans start at $299/year.

Use code LAUNCH100 for $100 off your first year. Expires in two weeks (May 18).

Get started today

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