I’ve been thinking about mobile for Explore.

Not because every product needs an app. And not because “launched a mobile app” looks nice on a CV.

The more interesting question is: what would mobile teach me about the product, and what would it teach me about the factory?

Explore is a Rails product. My dark factory is also primarily Rails-focused. That’s useful, but it doesn’t automatically mean the model is portable.

A factory that works inside one Rails repo is useful.

A factory operating model that can survive across different stacks and surfaces is much more interesting.

That’s why mobile appeals.

I’m interested in three paths:

Ruby Native

Swift + Hotwire Native

Full native Swift

Each one answers a different question.

Ruby Native is the speed path. It looks like the fastest way to get Explore into a real mobile surface and learn whether app distribution even matters here.

Hotwire Native is the bridge path. It keeps some of the leverage of the Rails app, but introduces more native structure and more realistic mobile complexity.

Full native Swift is the independence path. That’s the real test of whether the factory can survive outside its current home and operate in a genuinely different stack.

The important thing is that I wouldn’t want three random experiments. I’d want the same constrained use case across all three. Something like: browse a profile, ask grounded questions, sign in, perform one lightweight owner action.

That would make the comparison meaningful.

So for me, this is not really about “should Explore have an app?”

It’s about what each path teaches.

Ruby Native would prove speed.

Hotwire Native would prove the hybrid path.

Full native Swift would prove stack independence.

That feels like a much better way to think about mobile.