Do you actually need a native app?

More often than this category admits. If your product is any of these, stop reading and build for the web:

A tool people use at a desk. Dashboards, admin panels, internal tools, anything B2B where the phone is the secondary screen. The browser is where this software lives, and an app would be an obligation nobody asked for.

Something you are still validating. A link beats an install. You can put a web app in front of a hundred people this afternoon with nothing to download and no review cycle; changing it takes a deploy, not a resubmission. Almost every product should start here even if it ends native.

Content. Publications, catalogues, marketing, documentation. The web was built for this and remains better at it than any app.

Anything where installation is friction you cannot afford. Every install is a small ask. If your users touch the product once a month, the ask is larger than the product.

The web also gives you things native never will: one build for every device, instant updates, no store between you and your users, and links — the most underrated distribution technology there is.

The middle path is real and often sensible. A PWA installs from the browser to the home screen: its own icon, full screen, a place in the app switcher. A wrapper like Capacitor or a Trusted Web Activity packages the same web app for the App Store or Google Play, so you get store presence without a second codebase.

For a lot of products that is the correct stopping point. Be clear-eyed about what it is, though: the same website, in different clothes. The wrapper changes where the app appears, not what it can do. The capabilities in the next section stay out of reach, because the code inside is still running in a web view.

Two costs worth knowing before you take this path. Apple applies more scrutiny to apps that are substantially a website, and the risk lands hardest on exactly the simple wrapped apps most likely to try it. And the experience gap — scroll feel, gesture response, keyboard behaviour — does not close with wrapping; users cannot name it, and they notice it.

This is the list that decides the question. Each item is an operating-system capability a web view cannot reach, however it is wrapped.

Presence outside your app. Home-screen widgets. Live Activities on the Lock Screen and Dynamic Island. Watch-face complications. Siri and App Intents. The share sheet. These are the surfaces where an app keeps working for someone who has not opened it — and for many products they are worth more than the app itself.

Working when closed. Background sync, scheduled processing, acting on a push notification without being opened. A web app runs when its tab is open; that is the deal.

The device itself. Real camera control, Bluetooth peripherals, NFC, motion and health sensors, the secure enclave. Some of these have partial web APIs with uneven support. Most do not.

Genuine offline. Not a cached shell — a local database, full function on a plane, reconciliation when the network returns.

Feel. The interactive back-swipe that follows your thumb, the rubber-band at the end of a list, how a sheet responds when you drag it halfway and change your mind. This is the difference users report as "it feels cheap" without being able to say why.

And the store, as a feature rather than a gate. Presence where users look for apps, in-app purchases and subscriptions handled by the platform, and the credibility an installed icon carries that a bookmark does not.

If two or more of these describe your product, you need a native app. If none do, you were done two sections ago.

Write down your product's three most important moments — the things it absolutely must do well. Then ask of each one:

Does it happen when the user is not looking at the app? A reminder that fires, data that syncs overnight, a glanceable status. Native.

Does it touch hardware beyond the screen? Camera as a feature rather than an upload field, sensors, peripherals. Native.

Must it work with no connection? Not "degrade gracefully" — work. Native.

Is it read, filled in, or reviewed at a desk? Web.

Is the product younger than its first hundred users? Web for now, whatever the long-term answer.

Mixed results are common and have an honest resolution: most companies that need both end up with a web app for the desk and a native app for the pocket, doing different jobs. The mistake is not choosing one — it is building one and expecting it to do the other's job.

The reason this decision used to default to "web, obviously" was cost: a native app meant hiring iOS and Android developers or an agency, twice the codebase, twice the maintenance. That premise has aged.

Modaal builds native apps — real Swift and SwiftUI for iOS, real Kotlin and Jetpack Compose for Android — from plain-language descriptions, using the AI agent you already subscribe to, on your own Mac. The project is a standard Xcode project on your disk from the first build; there is no export step because there is nothing to export from.

For both platforms at once, Duet writes each feature's logic exactly once and renders it natively on each side, with the agreement between the two platforms enforced by tests rather than discipline — the build fails when they disagree. Android is in open beta, with general availability in September 2026.

The honest costs, so this page stays the page it promised to be: you need a Mac with Xcode 26 or newer and about 50 GB free, and you will see code even though you will not write it. And one thing worth knowing before you validate on the web first — a web codebase does not convert into a native one later. They are separate builds. Validating with a web app is still often the right call; just budget for the native app as a build, not a migration.

The Free plan does not expire: one active project, unlimited prompts, one platform, no card. If the five-minute test above came out native, that is a cheap way to find out if it was right.