Apps, on every screen

What "every screen" actually means

The phrase covers six places software can live: the web, iPhone, Android, Apple TV, macOS, and watchOS. I build on all of them. That is a capability statement, not a recommendation — almost no product should ship to all six, and a big part of what you are paying for is someone telling you which two or three actually matter.

Here is how I think about each one.

Web is the default, and it should be. It is the only platform with no gatekeeper, no review queue, and no install step between a stranger hearing about your product and using it. You ship a fix at 2pm and every user has it at 2:01. If your product is something people use at a desk, or something they will touch a handful of times, or something you are still figuring out, web is almost always the right first and sometimes only target. Most of the "we need an app" conversations I have end with a good responsive web app and a home-screen icon.

iOS earns its place when the product depends on something only the device can do, or when it lives in the pocket rather than at the desk. Camera and sensor access, background location, push notifications people actually act on, offline use, HealthKit, secure on-device storage, and — not a small thing — App Store distribution as a discovery channel. Grainy and Wanderlist are both iOS-first for exactly these reasons: one needs the camera pipeline in real time, the other needs to be there the moment you land somewhere new, including with no signal.

Android is the same argument at a different scale. If your users are outside the US, or in any consumer market where price sensitivity matters, Android is not the second platform — it is the first one. The trap is assuming iOS and Android are one line item. They are two builds unless we deliberately choose a shared codebase, and that choice has real costs I would rather talk about honestly than paper over.

Apple TV is a narrow but genuinely underserved target. It is worth it when the content is video or ambient, when the session is long, and when the audience is at home rather than in transit. The interaction model is the whole design problem: a remote with a handful of buttons, a focus engine instead of a cursor, and a user sitting ten feet away who cannot read your 14px body text. A tvOS app is not a resized iPad app, and anyone who tells you otherwise has not shipped one.

macOS makes sense for tools people keep open all day — anything with keyboard shortcuts, multiple windows, file system access, or a menu bar presence. If your users live in your product for hours, a real desktop app is a meaningful upgrade over a browser tab. If they visit for four minutes a week, it is not.

watchOS is the most over-requested and least often justified platform on this list. A watch app is worth building when the interaction is under five seconds and the value is in glanceability or a sensor on the wrist — timers, live activities, workouts, quick logging. It is not worth building because the roadmap deck had a watch mockup on slide nine.

Native versus web, honestly

The industry answer to "native or web?" is usually whichever one the person answering prefers to build. Here is the actual decision.

Go native when you need the hardware (camera, sensors, background execution, offline-first storage), when the interaction has to feel instantaneous under your thumb, when you want App Store distribution, or when platform conventions are part of the product's credibility. A camera app has to be native. A travel log people open on a plane has to work offline.

Stay on the web when the value is in the data and the workflow rather than the device — dashboards, admin tools, marketplaces, anything B2B, anything you will iterate on weekly. You get one codebase, instant deploys, no review queue, and no 30% platform cut.

And a lot of products want a hybrid: a web app for the real work, plus a thin native app that does the two or three things that genuinely need the device. That is often the cheapest correct answer, and it is the one that gets recommended least, because it is less exciting to pitch.

The over-engineering failure mode I see most: a team builds three native clients before they know whether anyone wants the thing, then spends the next year shipping every change three times. Platforms are a permanent cost, not a one-time one. Add them when the evidence justifies them.

How the day rate works for app builds

The rate is $1,000 a day, flat. Not hourly — you cannot build anything good in scattered hours, so you get a whole day of focus on your thing and nothing else.

For an app specifically, that day rate covers the parts that are usually separate invoices elsewhere:

• Design and interface. Wireframes through final screens. You do not need to bring a designer.
• The whole build. Frontend, backend, database, auth, payments — all of it, by me.
• Every screen it needs to run on. Whichever of the six we agreed actually matter.
• Live in production. Hosting, domains, SSL, CI. I put it live and keep it running.
• Store submission. App Store and Play Store review, metadata, screenshots, and the back-and-forth when they reject it. That part is included, and it is a real part of shipping a mobile app — the build being finished and the app being available are separated by a review process that has its own rhythm and its own rejections.

What this pricing model changes in practice is the incentive. Nobody is billing hours, so there is no reason to inflate the platform list or gold-plate a screen. The fastest correct build is the one that serves us both. I am quick with most things, so it usually takes fewer days than you would expect.

Proof

Two shipped iOS apps make the case better than a capability list.

Grainy is a vintage film camera for iPhone that renders grain, halation, and color response live in the viewfinder rather than as a filter applied afterward — a build that only exists as a native app, because the whole product is a real-time camera pipeline.

Wanderlist is a lifelong travel record: countries, cities, airports, and flights, a map that fills in as you go, and a journal for every trip. It is native because it has to work in an airport with no data.

Both write-ups go into the actual engineering decisions rather than repeating this page. If you are weighing a build and want to see how the tradeoffs land in a real product, start there — and if your app has a regulated angle, the HIPAA-compliant Next.js on Vercel guide covers what changes when the data is sensitive.