Web app vs mobile app vs native — what to build first
Build a web app first in 99% of cases. Cross-platform (React Native / Flutter) is the second stop. Native iOS and Android earn their cost only for specific, real reasons.
Start with a web app. It's cheaper, faster to ship, and reaches every device. Add a cross-platform mobile app (React Native or Flutter) once you have real users asking for it. Build native iOS or Android only when a specific capability or performance ceiling forces your hand.
The three platform choices in plain English
- Web app (PWA-capable) — Runs in the browser. One codebase, works on desktop, mobile browsers, and tablets. Can be installed to home screen and work offline with Progressive Web App tech. Stack: React/Next.js or Vue on the frontend, any backend. Time to build: shortest. Cost to build: lowest. Install friction: zero (paste a URL).
- Cross-platform mobile (React Native, Flutter, Expo) — One codebase compiles to real iOS and Android apps distributed through the App Store and Play Store. Modern versions look and feel native to 90% of users. Time to build: 30–50% more than web-only. Cost: 40–70% more than web-only, but far cheaper than two separate native apps.
- Native (Swift for iOS, Kotlin for Android) — Separate codebases per platform. Highest performance, deepest device integration, best fit for premium consumer apps and games. Time to build: 2x cross-platform. Cost: often 1.7–2.2x cross-platform, since you're maintaining two codebases with different teams.
Why we recommend starting with web in almost every case
It's not that mobile is worse — it's that web reduces every other risk in the project. You can validate the product hypothesis, iterate design weekly, and change your data model without going through an App Store review. Once the product concept is proven and users are begging for a mobile app, that's the right time to build one. Doing it in the other order (mobile first, then adding web later) is 2–4x more expensive and slower to iterate.
- Fastest path to real users — Send a URL, they use the product. No install, no review process, no push-notification setup.
- Cheapest to iterate — Deploy 5 times a day if you want. Every change reaches every user instantly. Mobile apps have to wait for App Store review (often 24–72 hours) and user updates (never — some users never update).
- Reaches every device — Desktop, laptop, iPad, iPhone, Android, Chromebook, Windows tablet. One codebase, all surfaces.
- SEO and shareable URLs — Web content is indexable and linkable. Mobile app 'deep links' technically exist but are a fraction as valuable for growth.
When mobile actually is the right first platform
- Camera-first products — Consumer apps built around photo, video, or AR (think Snap, TikTok, VSCO). The web can access the camera, but the UX friction is real. Mobile-first wins here.
- GPS and location-heavy apps — Ride-hailing, delivery, running-tracker, geo-social. Web can approximate but mobile is the natural home.
- Push notifications as core loop — If push is the primary retention mechanism (messaging apps, dating apps, some fitness apps), mobile is required. Web push exists but has 3–10x lower engagement.
- Distribution advantage via App Store — For certain consumer categories (games, kids apps, wellness), App Store discovery still drives measurable installs. Rare but real.
- Enterprise field workers — Delivery drivers, field service technicians, warehouse ops — offline reliability and hardware-scanner integration are worth the mobile-first cost.
When native (not cross-platform) actually earns its cost
React Native and Flutter cover 90% of mobile use cases. The remaining 10% justifies the cost of native. If you're not in that 10%, native is a premium you're paying for nothing.
- Games and heavy graphics — Anything with real-time 3D rendering, physics engines, or 60fps gameplay. Native Metal/Vulkan or a game engine (Unity, Unreal) beats cross-platform decisively.
- Deep hardware integration — Real-time audio processing, low-latency Bluetooth peripherals, HealthKit / SensorKit, ARKit / ARCore, specialized Apple Watch or WearOS surfaces.
- Premium consumer brand — If your brand promise is craft and polish (banking apps for wealth management, luxury retail, high-end fitness), the last 10% of feel that native delivers is worth the 2x cost. Users can tell.
- Regulated apps requiring platform SDKs — Certain financial and healthcare integrations require Apple/Google's platform-specific SDKs. No cross-platform workaround.
How to sequence platforms if you know you'll need multiple
The path we recommend and see work in ~80% of engagements: (1) Web app with responsive mobile web, validate the hypothesis, get to 500–5,000 users. (2) React Native or Expo app sharing the same TypeScript backend, ship to iOS and Android from one codebase, get to 20,000+ users. (3) Only if a specific platform capability or performance ceiling becomes a real blocker, migrate that specific surface to native — not the whole app. Most products never reach step 3 and that's fine.
Common questions
Isn't a mobile app more 'professional' than a web app?
That was true in 2016. In 2026, a well-built web app on a well-branded domain is fully credible for B2B and prosumer categories. The consumer categories where 'must have an app' still applies (dating, social, games) are increasingly narrow. Ask what actual user problem the mobile app solves — if the answer is 'because we should have one', don't build it yet.
Is React Native production-ready in 2026?
Yes, decisively. Meta, Shopify, Coinbase, Microsoft, and Discord all ship React Native at scale. Expo has closed most of the remaining developer-experience gaps. The engineers who told you it wasn't production-ready in 2019 were partially right then; they're wrong now.
What about Flutter vs React Native?
Both are legitimate. React Native wins when your team is already TypeScript-native (share code with the web app, hire from the same pool). Flutter wins when you want a single UI toolkit across mobile and want pixel-perfect rendering identical across devices. Neither has a decisive technical advantage at this point; hire in whichever your team can support.
Can I convert my web app to a mobile app cheaply?
Capacitor and Tauri wrap your existing web app in a mobile shell — think 'web app in a container that ships to the App Store'. That's often 2–4 weeks of work for a working iOS/Android app. Users can tell it's not native, and some features (push, deep integrations) don't work as well. Fine for internal enterprise apps; usually not enough polish for consumer products.
How much more does maintaining two native codebases cost vs one cross-platform?
In our data, running iOS + Android native is 1.7–2.2x the total cost of running React Native or Flutter for the same feature velocity. That's the cost of two separate teams (or one team switching contexts constantly). The exception is when your product genuinely benefits from platform-specific UX — in which case the 'two codebases' isn't waste, it's the product working correctly on both platforms.
Have a specific situation? Talk to an engineer at NextGen — we do free 30-minute scoping calls with a senior developer, not a salesperson.
Keep reading
Start your project request
Tell us what you're building — engineering capacity, AI, QA, cloud, or a fixed-scope software engagement. Our NYC team responds within one business day.
- Response within 1 business day
- 30-minute discovery conversation
- Recommended engagement model & pricing
- NYC-focused — in-person available
Inbound sales only. All form information is encrypted in transit.