Types of App Developers: Native, Cross-Platform or Web App?

There are three types of app developers you're likely to hire: native developers who build separate iOS and Android apps in Swift and Kotlin, cross-platform developers who build one app for both with React Native or Flutter, and web developers who build a web app or PWA that runs in the browser. The right type depends on two questions: does your app need the App Store and the phone's hardware, and how much can you spend keeping it alive after launch?

Full disclosure: I'm a web developer based in Denmark, building web apps and backends with Laravel and React, so I have a bias. I'll be just as clear about when a web app won't cut it and you should hire someone else.

The short answer: three types side by side

Here's the decision rule I use. First, ask whether the app truly has to be in the App Store. If it doesn't, a web app is almost always the cheapest and fastest route. If it does, start from cross-platform, and go native only when the phone itself is a big part of the product.

If you want the bigger picture of who does what in software, my guide to the different types of developers covers every role. This post sticks to apps.

Native developers: Swift and Kotlin

A native developer builds with the platform's own tools: Swift and SwiftUI in Apple's Xcode for iPhone and iPad, Kotlin in Android Studio for Android phones. Nothing sits between the app and the operating system, so it gets every capability the device offers and behaves like Apple's and Google's own apps.

The catch is that you're paying for two apps. iOS and Android are separate specialties, and plenty of native developers only work on one. In practice that means two developers or a small team, and every feature gets built, tested and released twice. The backend is shared, so it rarely costs exactly double, but the difference shows up on every invoice.

Native earns its price when the phone is part of the product: heavy camera or audio processing, wearables, sensors or Bluetooth hardware, games, and apps where smooth animation is a selling point.

When native is overkill

• When the app mostly shows data and forms from a server, as most business apps do. Your users won't notice the second codebase, but your budget will.
• When the budget only covers version one. Two native apps are costly to keep current, and an app that stops getting updates decays quickly.
• When you don't know yet whether anyone wants it. Validate the idea with something cheaper first.

Cross-platform developers: React Native and Flutter

A cross-platform developer writes one app that runs on both iOS and Android. The two big frameworks are React Native, which is built on JavaScript and React and maintained by Meta, and Flutter, which uses the Dart language and is maintained by Google. Both produce real store apps that feel native to most users.

For the majority of consumer apps, this is the best trade-off. One codebase, one team, and new features land on both platforms on the same day. React Native has an extra advantage if you already run a React web app: your web developers can contribute, and some logic can be shared.

The downside is an extra layer between your code and the phone. When Apple or Google changes something, the framework and its plugins have to catch up before your app can. Major framework upgrades can eat several days, and sooner or later a feature will need some native Swift or Kotlin code anyway. Ask any cross-platform developer whether they can write that code themselves, or who does it for them.

When cross-platform is the wrong call

• When the app leans so hard on hardware that large parts end up native anyway. You then pay for both approaches.
• When you don't actually need the app stores. A web app is cheaper to build and cheaper to run.

Web app developers: web apps and PWAs

A web app runs in the browser and works on phones, tablets and laptops from a single codebase. That's what I build. A PWA (progressive web app) is a web app that users can add to their home screen, where it opens full screen like any other app. Since iOS 16.4, home screen web apps can also send push notifications on iPhone, which removed one of the main reasons to go through the App Store.

The appeal is economic. No app review, no yearly store requirements, and no outdated versions lingering on users' phones: ship a fix and everyone has it on their next page load. A web developer usually builds the backend too, so one person can own the whole product. I've written about when one full-stack developer is enough if you're weighing that setup.

One EU detail matters here. In early 2024, Apple announced it would strip Home Screen web apps from iPhones in the EU as part of its Digital Markets Act changes, then reversed the decision weeks later after pushback from businesses and the European Commission. PWAs work in the EU today, but the episode is a reminder that every route onto an iPhone runs through Apple, store apps included.

Web apps do have hard limits. They aren't listed in the app stores, where many consumers still look first. Hardware access is narrower than in a native app, especially on iPhone, and things like long-running background tasks or some Bluetooth connections are difficult or impossible from the browser.

When a web app isn't enough

• When being discoverable in the App Store or Google Play is central to your marketing.
• When the app has to work fully offline for long stretches, or needs hardware the browser can't reach.
• When your users expect to find you in the store, for example because every competitor has an app there.

The part every app needs: a backend

The app on the phone is only the visible half. If users log in, see their own data, pay or get notifications, you also need a backend: a server with a database, an API (the connection the app uses to read and save data) and usually an admin panel where your team can edit content and help customers.

That backend is the same job whichever app type you pick, and it often makes up a large part of the total build. Many app developers are strong on the interface but would rather not build or host servers, which leaves you looking for a second developer halfway through. Ask early who builds and runs the backend, and if you have users in the EU, where their personal data will be stored.

This is also where the types combine well. A common split is a web developer who owns the backend, API and admin, and an app developer who builds the mobile front end on top. If you need design, two platforms and a backend all at once, a full team may fit better, and my honest comparison of freelancers and agencies can help you decide.

What each type costs to keep alive

Launch cost gets most of the attention, but the bigger difference between the three types is upkeep. A store app is never finished. Apple and Google ship new operating systems every year and require apps to keep pace.

A few concrete examples:

• Google Play requires new apps and updates to target a recent Android version. Since August 31, 2026, that means Android 16, and existing apps that still target Android 14 or older can no longer be installed by new users on newer phones.
• Apple regularly raises the minimum Xcode version that uploads must be built with. If an app has been left alone for a while, a quick bug fix can turn into a project upgrade first.
• Both stores charge for developer accounts: Apple yearly, Google once. The fees are small, but if your Apple Developer Program membership lapses, your app disappears from the App Store for new downloads and you can't ship updates.

When you set a budget, plan for that upkeep from day one. My rule of thumb: a store app needs paid hours every year, even in years without new features. For price ranges across web apps, PWAs and native apps, see my breakdown of app development cost.

How to choose the right type in five steps

1. List what the app has to do on the phone: camera, location, push notifications, offline use, Bluetooth, payments. If the list is short and standard, a web app can probably handle it. If it includes hardware the browser can't reach, you're looking at cross-platform or native.
2. Decide whether the App Store is a requirement or a habit. If strangers need to discover you there, it's a requirement. If your users are existing customers or employees you can email a link to, the store is often more habit than need.
3. Start with the smallest version you can test. A web app or PWA is usually the cheapest way to learn whether people use the product, and a well-built backend carries over if you add store apps later.
4. Budget for three years, not just the launch. Ask whether updates for new iOS and Android releases are included in the quote, and what they cost if not.
5. Pick the type first, then the developer. A native developer will tend to recommend native, and a web developer like me will tend to recommend a web app. Settle the type with steps 1-4, then find someone who has shipped that exact kind of app before.

Still unsure which kind of developer your project calls for? My decision guide by project type walks through the common cases.

Next steps

If your app is mostly logins, data and forms, there's a good chance a web app will do the job. That's the work I take on: customer portals, internal tools and web apps where one codebase covers phone and desktop. You can see how I approach these projects on my web apps and platforms page.

If you need a fully native iOS and Android app, I'm not the right person to build the app itself. I'm happy to help you make the call, though, and to build the backend behind it. For larger projects I start with a paid, fixed-price discovery phase, where you and I work out which type of solution fits before any code is written. I'm based in Denmark, so I work on Central European Time, the same working day as most of Europe.

Frequently asked questions

Can a web developer build an app for the App Store?+

Yes, with caveats. A web developer can wrap a web app with a tool like Capacitor and submit it to the App Store and Google Play. Apple rejects apps that are little more than a website, though, so the app needs features that make real use of the phone. If the app needs a lot of native code, a cross-platform or native developer is the better hire.

Should I start with a PWA and build a native app later?+

Often, yes. If the backend exposes an API, a later iOS or Android app can reuse the same server, database and admin panel, so mainly the interface gets rebuilt. Tell your developer about the plan from the start, so the API is designed for more than one client. The PWA also gives you real usage data before you commit to store apps.

Who should own the Apple and Google developer accounts?+

Your company should. Create the accounts yourself and give your developer access, so the app never depends on one person's login. Enrolling as a company with Apple usually takes longer than enrolling as an individual, because you'll typically need a D-U-N-S number for your business first. Set it up well before your planned launch date.

React Native or Flutter: which is better for a business app?+

Neither wins in every case. Both are mature and used for apps in both stores. React Native makes sense if you already have a React web app or JavaScript developers, because knowledge and some code can be shared. Flutter is strong when the app should look identical on both platforms. Choose based on your existing stack and the developer you trust, not the framework alone.