Why we build for iPhone first

Every Baran Labs app starts on iPhone. Android follows when — and only when — the Android version can meet the same bar. This is a practical position, not a tribal one, and since "iOS first" is often said and rarely explained, here is the actual reasoning.

One platform, full attention

We are a small team, and the math of simultaneous platform launches is unforgiving. Two platforms don't double the work; they roughly double the work and halve the attention each version gets. Every screen is designed twice, tested twice, debugged twice — and every bug report starts with "which version are you on?"

For a team our size, shipping on both platforms at once guarantees one thing: neither version is the best version. We'd rather ship one app we're proud of than two apps that are each 70% right.

Starting with a single platform also changes what we can promise. When Hometric shipped, one team had tested one capture flow against one platform's camera behavior — a focus that gets diluted with every additional platform in the matrix.

Why iPhone specifically

Three practical reasons, in order of weight.

First, our apps lean hard on the camera and on-device consistency. iPhone camera behavior is far more consistent across the model range than the Android matrix, which spans hundreds of devices with different camera stacks. For an app whose core loop is "photograph a room and trust the result," that variance is where quality goes to die.

Second, the apps we build are paid products, and iOS remains the platform where consumers most reliably pay for software. That isn't a moral judgment about either user base — it's revenue math for a studio funded entirely by its own products.

Third, one team, one toolchain. Going deep on a single platform's conventions produces better software than staying shallow on two.

What "the same bar" means

When we say Android follows when it can meet the same bar, concretely we mean: feature parity on the core job, camera capture that's been tested across the devices we claim to support, and performance we'd defend on a mid-range phone, not just a flagship. An Android version exists the day those are true, and not a day earlier.

What we will not do is ship a port — a translated iOS app with Android idioms bolted on, maintained at arm's length. Android users can smell a port instantly, and they're right to resent it. If we come to Android, it will be as its own properly built product.

What Android users should expect from us

Honesty, mostly. We won't announce Android dates we can't keep, and we won't say "coming soon" as a placeholder for "someday." Where we have a waitlist or a way to hear about it, it will be on the product's own site. If that costs us goodwill with people who want the app today, we accept that — the alternative is promising something we haven't earned the right to promise yet.

iPhone-first is how a small studio ships work it can stand behind. When that stops being true, we'll change the policy and write about that too.