Types of Apps: Native, Cross-Platform, Hybrid, PWA and Web

There are five main types of apps: native apps, cross-platform apps, hybrid apps, progressive web apps (PWAs) and plain web apps. Native and cross-platform apps are installed from an app store and run on the device itself. Hybrid apps are web pages packaged inside an installable shell. PWAs and web apps run in the browser. Which one to build depends on how much device access and performance the product needs, and how much you can afford to build and then maintain.

People also use "types of apps" to mean categories such as games, social or finance apps. That is covered near the end, because the technical type is the decision that sets your budget.

The five types of apps compared

The sections after the table explain each row.

Type	Build cost	Performance	Device access	Distribution	Updates
Native	Highest for two platforms: each is its own codebase	The best the device can offer	Full, including new operating system features as soon as they ship	App stores	A new store release, with review, for every change
Cross-platform	Lower than two native apps, since most code is shared	Close to native for most products	Nearly full, through plugins or small pieces of native code	App stores	A store release; some frameworks can also push limited updates to the shared code
Hybrid (web view)	Low, especially if a web app already exists	Limited by the web view; fine for forms and content, weaker for heavy animation	Good, through plugins	App stores	A store release for the shell; the web layer can sometimes be updated separately, within store rules
Progressive web app	Low: one web codebase for every device	Good for most interfaces, within what the browser allows	Partial, and narrower on iPhone than on Android	A link, with optional install from the browser	Immediate, when you deploy
Web app	Lowest	Good, given a reasonable connection	Only what the browser exposes	A link	Immediate, when you deploy

Read the table as a slope. Moving up it buys you performance and device access. Moving down it buys you lower cost, faster releases and wider reach. Most of the skill is working out how far up you actually need to go.

Native apps

A native app is written with the platform's own language and tools: Swift for iPhone and iPad, Kotlin for Android. Each platform is a separate codebase, usually built by people who specialise in it.

What you get is everything the device can do. Native code has direct access to the camera, Bluetooth, sensors, background processing, widgets, watch apps and in-car screens, and it can adopt new operating system features on the day they are released. The interface uses the platform's own components, so it behaves the way users of that phone expect without extra effort.

What you pay is duplication. If you need both iPhone and Android, every feature is designed once and built twice, by two sets of skills, and the two versions have to be kept in step for as long as the product lives.

Suits: products where the device is the point. Camera, video and audio processing, augmented reality, heavy Bluetooth or sensor work, wearables, and anything that depends on deep operating system integration. It also suits a product that only needs one platform. A single native app is usually no more expensive than a cross-platform one, and people often overlook that. Our native app development page describes the approach.

Cross-platform apps

A cross-platform app is written once and shipped to both app stores. The two frameworks you will hear most are React Native, which uses JavaScript or TypeScript and renders the platform's real interface components, and Flutter, which uses Dart and draws the whole interface with its own rendering engine. Kotlin Multiplatform and .NET MAUI are the other names that come up.

These are real installed apps. They are not websites in a wrapper, although people often lump them in with hybrid apps. Performance is close to native for the screens most products are made of: lists, forms, maps, payments, chat and media.

The saving is real but smaller than the pitch suggests. You still test on both platforms, still handle the places where iOS and Android behave differently, and still write a little native code when no plugin exists for the device feature you need. You also take on a dependency: when a new operating system version lands, you wait for the framework and its plugins to catch up.

Suits: most business and consumer apps that need to be on both platforms. Marketplaces, booking apps, delivery apps, fintech front ends, membership apps and almost any first version of a product. I have written up the fuller argument in native vs cross-platform apps, and the framework choice in React Native vs Flutter, so I will not repeat either here.

Hybrid apps (web view)

A hybrid app is a web app, built with HTML, CSS and JavaScript, packaged inside a thin native shell. The shell opens a web view, which is a browser component embedded in the app, and the whole interface is rendered inside it. Plugins give the web code access to the camera, files, push notifications and other device features. Ionic with Capacitor is the common modern toolset, and Apache Cordova is the older one.

The appeal is that a web team can ship to the app stores without learning a new stack, and an existing web app can be reused almost whole.

The weakness is feel. Scrolling, gestures and animation run in a browser engine, and getting them to match what users expect from an installed app takes deliberate work, particularly on older Android phones. There is a store risk too: Apple's review guidelines have long discouraged apps that are little more than a website in a wrapper, so a hybrid app needs to offer something a bookmark does not.

Suits: content and form-driven apps, internal tools, and companion apps for an existing web product. Our hybrid app development page goes into when it holds up and when it does not.

A warning about vocabulary: some agencies say "hybrid" when they mean React Native or Flutter. The trade-offs are different, so if a quote says "hybrid app", ask whether the interface runs in a web view.

Progressive web apps

A progressive web app is a website built to behave like an app. It can be added to the home screen, opens in its own window without the browser's address bar, keeps working on a poor or absent connection by caching what it needs, and can send push notifications. There is no app store involved unless you want one.

The strengths are reach and speed. One codebase serves phones, tablets and desktops. Every release is live the moment you deploy. Pages can be linked to, shared and found through search, which no store-only app can match.

The limits are set by the browser. A PWA can only use the device features the browser exposes, and that set is narrower on iPhone than on Android. On iPhone, installing is a manual step through the share menu, and web push only works once the app has been added to the home screen. There is also a habit problem: many users look for apps in the store and nowhere else.

Suits: e-commerce, content, booking, loyalty and business tools where reach matters more than device features, and audiences who are reluctant to install anything. The progressive web apps page covers the build side.

Plain web apps

A web app is software that runs in the browser: you open a link, sign in and use it. Nothing is installed and nothing works offline. Most SaaS products, dashboards, admin panels and customer portals are web apps.

It is the cheapest type to build and the easiest to change, and a responsive web app works on a phone without a separate build. It can also be turned into a PWA later at modest cost, which makes it a low-risk place to start.

Suits: anything used mainly at a desk, most business-to-business software, and the first version of an idea you have not yet proven.

Native vs web vs hybrid apps: which type suits your product?

I would ask these four questions in order. The first one that gives a firm answer usually settles it.

1. Does it need to be in an app store at all? If your users will arrive by link, search or an email invitation, a web app or PWA is enough and will be far cheaper.
2. Which device features does it need, specifically? Write the list. A camera for a profile photo is available to every type. Continuous background location, Bluetooth accessories or real-time video processing point towards native.
3. Who will maintain it? A team of web developers will keep a PWA or hybrid app healthy. Asking them to maintain two native apps will not end well.
4. How often will it change? If you expect to release weekly, the store review step becomes a cost you feel on every release.

As a rough guide:

• Device-heavy product, or one platform only: native.
• Standard screens on both iPhone and Android: cross-platform.
• Existing web app and a web team, with a need to be in the stores: hybrid.
• Reach, search visibility and frequent releases matter most: PWA.
• Desk-based tool or an unproven idea: web app.

How the app type affects budget and maintenance

The build cost follows the number of codebases. Two native apps mean two builds. A cross-platform app is one build plus platform-specific work. A web app or PWA is one build with no store overhead. I am not going to put figures on these, because the feature list moves the total far more than the app type does. The piece on the real cost of custom software explains where the money goes.

Maintenance is where the app types really separate, and it is the part buyers tend to underestimate.

• Operating system releases. iOS and Android each ship a major version every year. Store apps of every kind need testing against it, and sometimes changes.
• Store requirements. Both stores update their policies, and Google Play requires apps to keep targeting a recent Android version. An app left alone for long enough cannot ship an update until it has been brought up to date.
• Framework upgrades. Cross-platform and hybrid apps add a layer that has its own release cycle, plus plugins maintained by third parties. Budget time for upgrades each year.
• Store overhead. Developer accounts, review, privacy declarations and the rules on in-app payments for digital goods apply to anything distributed through a store. Those rules vary by region and keep changing.
• Web upkeep. Web apps and PWAs avoid nearly all of the above. Browsers update themselves and rarely break working sites.

One piece of advice applies whichever type you choose: keep the business logic in the API on the server, and keep the app itself thin. Then changing type later means rebuilding screens. It does not mean rebuilding the product.

The other meaning: different types of apps by category

If you came here for the categories you see in the app stores, these are the main ones, with the technical type each tends to use.

• Games. Usually built in a game engine such as Unity, with native code where performance demands it.
• Social and messaging. Native or cross-platform, because they lean on push notifications, the camera and background activity.
• Shopping and marketplaces. Cross-platform apps and PWAs, often both.
• Finance and banking. Native or cross-platform, for biometric sign-in and secure storage.
• Health and fitness. Often native, because of sensors and wearables.
• Productivity and business tools. Web apps first, with a mobile app added when people need it away from a desk.
• Media, news and education. PWAs and cross-platform apps, where content matters more than device features.

If you would like a second opinion on which type fits your product before you commit budget, that is part of what our mobile app development team does.

Frequently asked questions

What are the different types of apps?

By how they are built, there are five: native, cross-platform, hybrid, progressive web apps and web apps. By what they do, the stores group apps into categories such as games, social, shopping, finance, health, productivity, media and utilities.

What is the difference between native vs web vs hybrid apps?

A native app is written for one platform and installed from its store. A web app runs in the browser and is not installed. A hybrid app is a web app packaged in a native shell, so it can be installed from a store while still rendering its interface in a web view.

Which of the app types is cheapest to build?

A plain web app, followed by a PWA. Hybrid and cross-platform sit in the middle. Two separate native apps cost the most, although a native app for one platform alone is comparable to a cross-platform build.

Is a progressive web app a real app?

For the user, largely yes: it has an icon, opens in its own window and can work offline. Technically it is a website with extra capabilities, which is why its access to device features is narrower than an installed app's, especially on iPhone.

Can I change app type later?

Yes, and many products do. A web app can become a PWA cheaply. Moving from hybrid or cross-platform to native means rebuilding the interface, but a well-designed API and backend carry over unchanged.