How to Build a Mobile App in 2026 (A Web Developer’s Guide)

Most people asking me how to build a mobile app are really asking a budget question in disguise. They want to know if they can skip the $40k agency quote, or whether they need two separate apps for iPhone and Android. The honest answer is that in 2026 you have four real paths, and the right one depends far more on your app’s specific features than on which framework is trending on developer Twitter.

I’ve shipped apps on all of these. Here’s how I’d actually decide.

Path 1: React Native with Expo

If you already know JavaScript or React, this is where you start. React Native lets you write one codebase that compiles to real native UI on both iOS and Android. Expo is the toolchain around it: build service, over-the-air updates, and a library of prebuilt native modules so you don’t touch Xcode or Android Studio for weeks at a time.

The practical version of this in 2026 is Expo with the New Architecture enabled by default. You write components the same way you’d write them for the web:

import { View, Text, Pressable } from 'react-native';

export default function PayButton({ total, onPay }) {
 return (
 <View>
 <Text>Total: ${total.toFixed(2)}</Text>
 <Pressable onPress={onPay}>
 <Text>Pay now</Text>
 </Pressable>
 </View>
 );
}

That’s it. No Swift, no Kotlin. Push notifications, camera, maps, secure storage, in-app purchases: all wired up through Expo modules or community packages. When you need something genuinely custom, Expo supports native modules, and you can eject to bare React Native without rewriting your app.

Where it shines: CRUD apps, marketplaces, booking tools, internal business apps, anything with forms, lists, auth, payments, and API calls. That’s probably 80% of the apps businesses actually pay to build.

Where it falls down: heavy graphics, real-time video processing, complex background location, or anything that needs to squeeze the last 5% of performance out of the device. You’ll also hit occasional library gaps where a native SDK for a niche hardware device only ships Swift and Kotlin bindings.

For a Long Island app development project, React Native with Expo is what I reach for first unless there’s a specific reason not to. One codebase means one team, one release cycle, one bug tracker, and roughly half the cost of going native on both platforms.

Path 2: Fully Native (Swift and Kotlin)

Native means Swift for iOS and Kotlin for Android, two separate codebases, two teams (or one very busy developer). You get the best performance, the newest platform APIs on day one, and the exact look and feel of each OS. Apple and Google both push features through native SDKs first, and some things (WidgetKit, Live Activities, Android home screen widgets, deep Siri and Google Assistant integration) are native-only or painful anywhere else.

Choose native when:

• You’re building a game, an AR app, or something with heavy real-time rendering.
• You need to talk to unusual hardware: Bluetooth LE medical devices, custom cameras, industrial sensors.
• Performance is a product feature, not a nice-to-have. Think video editing, audio processing, high-frequency trading.
• You have the budget for two codebases and you’re okay maintaining them in parallel forever.

The real cost: every feature ships twice. Every bug gets fixed twice. Every design change gets implemented twice. For a small team, that’s the difference between shipping in four months and shipping in eight.

Path 3: Flutter

Flutter uses Dart and renders its own UI rather than mapping to native components. You get pixel-identical output on both platforms, excellent performance, and a strong widget library. Google uses it in production. It’s a legitimate choice.

Two honest caveats. First, Dart. If your team is a JavaScript shop, you’re adding a language and a hiring constraint. Second, the UI looks like Flutter unless you deliberately theme it to look like iOS or Android. For some apps that’s fine. For apps where users expect the platform conventions, it’s extra work to fake.

I’d pick Flutter if you have a design-heavy app with a custom visual identity and no existing JS/React investment. Otherwise React Native wins on hiring and code reuse with your web app.

Path 4: Progressive Web Apps

A PWA is a website with a manifest and a service worker. It installs to the home screen, works offline, and costs a fraction of a native app to build. If you already have a web app, you’re halfway there. This is a natural extension of custom web development work.

{
 "name": "My App",
 "short_name": "MyApp",
 "start_url": "/",
 "display": "standalone",
 "icons": [
 { "src": "https://i0.wp.com/www.kennykey.com/icon-192.png", "sizes": "192x192", "type": "image/png" }
 ]
}

The good: one codebase, instant updates, no app store review, no 15 to 30% commission on digital goods, and you can ship a fix in five minutes. On Android, PWAs are genuinely capable: push notifications work, install prompts work, file system access works.

The bad, and this matters: iOS. Apple limits PWAs on iPhone in ways that have real product consequences. Push notifications are supported now but require the user to add the app to the home screen first, which most users won’t do. Storage can be evicted by the OS. There’s no access to many native APIs, no background sync worth relying on, and no App Store presence, which means no discovery. If your users are mostly on iPhone, a PWA is a compromise, not a substitute.

PWAs are great for internal tools, customer portals, and apps where the web is already the primary product. They’re a bad fit for anything consumer-facing on iOS where push notifications or offline reliability drive retention.

The Decision Guide

Forget the framework debates. Answer these three questions.

By budget

• Under $15k: PWA, or a very narrow React Native app with a small feature set. Be honest about scope. One core flow done well beats five flows done badly.
• $15k to $60k: React Native with Expo. This is the sweet spot. You get a real app on both stores with a feature set that actually solves a problem.
• $60k to $150k+: React Native at scale, or native if the app demands it. At this level you’re paying for polish, integrations, and ongoing maintenance, not just the initial build.
• Ongoing: budget 15 to 25% of the build cost per year for maintenance. OS updates break things. Libraries get abandoned. This is not optional.

By team

• Solo dev or small JS team: React Native with Expo. No question.
• Web team with no mobile experience: React Native with Expo, or a PWA if the app is simple.
• Existing Swift/Kotlin engineers: native, if you have both, or native on the platform that matters most and React Native for the other.
• Design-led team with no JS: Flutter is worth a look.

By app type

• Marketplace, booking, e-commerce, social, internal tools: React Native.
• Games, AR, video/audio editing, hardware integrations: native.
• Content site or customer portal with light interactivity: PWA, or just a good responsive website.
• Anything where push notifications drive the business model on iOS: native or React Native. Not a PWA.

App Store Realities Nobody Warns You About

Whatever path you pick, the stores have rules and timelines that affect your launch.

• Apple review takes 24 to 72 hours, and rejections are common. Guideline 4.2 (minimum functionality) kills thin apps that are basically a wrapped website. Guideline 3.1.1 requires you to use Apple’s in-app purchase for digital goods, and Apple takes 15 to 30%. You cannot link out to your own payment page for digital content. Physical goods and services are exempt.
• Google Play is faster and more permissive, but the 15 to 30% commission on digital goods still applies, and Google has been tightening its own rules on external payments.
• You need a privacy policy, a data safety declaration, and increasingly an account deletion flow. Apple will reject you without account deletion if your app has account creation. This is non-negotiable in 2026.
• Both stores require you to keep up with SDK version minimums. If you don’t update your app for two years, it may stop being installable on new devices.
• Enterprise distribution exists if your app is internal-only. Apple Business Manager and Google’s managed Play can distribute privately without public review. For internal tools, this is often the right answer and it sidesteps the whole public store circus.

None of this is a reason to avoid the stores. It’s a reason to plan for a two-week buffer before launch and to read the review guidelines before you write code, not after you get rejected.

What I’d Actually Do

If you’re a business owner with an idea and a real budget, and your app is a standard product app (accounts, data, payments, notifications), build it in React Native with Expo. You’ll get to both stores faster, spend less, and keep more of your budget for the things that actually make the app good: onboarding, design, and marketing.

If you’re a developer, learn Expo. It’s the highest-leverage mobile skill right now. You can pick up Swift or Kotlin later if a project demands it, but you’ll spend most of your career shipping cross-platform apps, not writing two of everything.

If your app is fundamentally a website with a login, ship a PWA and see if it sticks. You can always build the native version later once you know people want it.

FAQ

Can I really build one app that works on both iPhone and Android?

Yes, with React Native or Flutter. One codebase, one build, both stores. The tradeoff is that you’re one layer removed from the platform, so the newest iOS or Android feature might not be available in your framework on day one. For 95% of apps that lag doesn’t matter. For the other 5%, go native.

How much does it actually cost to build a mobile app in 2026?

A simple app with login, a few screens, and one integration runs $15k to $30k with React Native. A real product with payments, notifications, admin tooling, and a backend runs $40k to $100k. Native on both platforms roughly doubles it. Anyone quoting you $5k for a full app is either building a PWA and calling it an app or planning to disappear after the deposit.

Do I need an app at all, or is a mobile website enough?

If your users only need to check information occasionally, a good responsive website is fine and much cheaper. You need an app when you need push notifications, offline access, camera or hardware integration, or a home screen icon that keeps you in front of the user. If none of those apply, spend the money on the website instead. I’ve told more than one client exactly that, and it saved them a lot of money.

Pick the path that fits your app, not the one that’s loudest online. Then ship it, measure it, and iterate. The framework matters far less than whether people actually use the thing.