What is a native app? Twenty questions, answered in one sentence each

A native app is a program compiled for one operating system, installed on the device as a package (an .ipa on iOS, an .apk or .aab on Android), that draws its screens with the platform's own interface components and calls the platform's APIs directly, instead of running inside a browser engine.

That is the definition; the test is three questions. First, does it install as a package? Android’s documentation: “the Android SDK tools compile your code along with any data and resource files into an APK or an Android App Bundle”, and the APK is “the file that Android-powered devices use to install the app” (developer.android.com, read 19 September 2026). On Apple platforms, distributing “through the App Store” means joining the Apple Developer Program and uploading builds to App Store Connect (developer.apple.com, read 19 September 2026).

Second, what draws the screens? Apple describes WKWebView as “a platform-native view that you use to incorporate web content seamlessly into your app’s UI”, presenting “HTML, CSS, and JavaScript content alongside your app’s native views” (developer.apple.com/documentation/webkit/wkwebview, read 19 September 2026). An app whose every screen is one of those passes the first test and fails this one.

Third, does it reach the hardware through the platform, asking for “permission to access device data such as the device’s location, camera, and Bluetooth connection” itself rather than through whatever a shell passes on? Apple’s review guideline 4.2 is the same test written as a rule: an app should “elevate it beyond a repackaged website” (developer.apple.com/app-store/review/guidelines, read 19 September 2026).

The long version, with performance numbers and the ways builders hide a web view, is in native code versus web view apps, explained for people choosing a builder.

A native app is installed from a store and runs as compiled code against the operating system; a web app is a website that runs in a browser tab and is never installed, and the three differences that decide anything are distribution, device access and offline behaviour.

Distribution. A native app goes through App Store review and Google Play, behind a $99 a year Apple Developer Program membership (developer.apple.com, read 19 September 2026) and a $25 one-time Google Play registration (support.google.com, read 19 September 2026). A web app is a URL, live the moment you deploy, reviewed by nobody.

Device access. A native app calls the camera, Bluetooth, NFC and notifications through platform APIs, with the permission prompts that implies. A web app gets what the browser exposes, and on iPhone that browser is WebKit, which lists Web Bluetooth, Web NFC, Web USB and thirteen other APIs as features it has “decided to not yet implement due to fingerprinting, security, and other concerns” (webkit.org/tracking-prevention, read 19 September 2026).

Offline. A native app’s code is on the device, so offline is the starting point and only the data needs a plan. A web app reloads from the server; it can cache itself with a service worker, but Safari deletes “all of a website’s script-writable storage after seven days of Safari use without user interaction on the site” (webkit.org, 24 March 2020), unless the site was added to the Home Screen.

The full comparison, PWAs included, with cost and performance tables, is native apps vs web apps vs PWAs: what to build.

A native mobile app is a native app narrowed to phones and tablets: a package built for iOS or Android, installed from the App Store or Google Play, and drawn with UIKit or SwiftUI on Apple devices and the Android View system or Jetpack Compose on Google's.

The word “mobile” changes the contrast, not the definition. On a laptop the alternative to a native program is a website in a tab, and the difference is mostly an installer. On a phone the alternative is the same product opened in Safari or Chrome, and the difference decides whether the thing can sit in a store, reach the phone’s radios, wake you with a push, and open with the network off. Those are the tells in the strip above, and they are why the phrase gets searched far more often than “native desktop app” ever was.

The line is drawn by rendering, not by language. A React Native or Flutter app is a native mobile app by Apple’s and Google’s packaging rules and by what it draws; a wrapped website is not, whatever it was compiled with. The next question takes that distinction one level down.

How the rendering difference shows up in real apps is covered in the native code versus web view guide.

No. As of 19 September 2026 Glide's own help centre says its apps are progressive web apps and that "publishing directly to the App Store or Google Play is not supported" (help.glideapps.com, article dated 22 July 2025).

Glide is direct about this in two places. Its article on app stores says the platform “is built using Progressive Web App (PWA) technology” and that “its apps cannot be published in traditional app stores like Google Play or Apple App Store” (help.glideapps.com, 3 December 2024, read 19 September 2026). The newer article adds that third-party tools which package a PWA for the stores exist, but “Glide does not endorse or support this practice” (help.glideapps.com, 22 July 2025).

So a Glide app is installed from a link or a QR code, opens in a browser-derived shell, and on an iPhone inherits every web limit in the PWA question further down: push only after a Home Screen install, no Bluetooth or NFC, storage that Safari can clear. For an internal tool where you hand people the link, that is fine, and Glide is genuinely quick at that job.

There is no export button, so there is no conversion. The route to a store is a rebuild of the same screens in a tool that outputs a native project, with the Glide app as the specification. That is less work than it sounds, because the hard part, deciding what the app does, is already done.

The step-by-step version of that rebuild is how to convert a Glide project to a mobile app.

Native mobile apps are the category of phone apps that ship as compiled packages through the App Store and Google Play and draw their screens with the platform's own components, as opposed to the two web kinds: a web page wrapped in an app shell, and a progressive web app installed from the browser.

The category is wider than “written in Swift or Kotlin”. React Native’s documentation says its “primitives render to native platform UI, meaning your app uses the same native platform APIs other apps do” (reactnative.dev, read 19 September 2026). Flutter’s says that “for release, Flutter apps are compiled directly to machine code, whether Intel x64 or ARM instructions”, drawing its own widgets through the Impeller engine (docs.flutter.dev, updated 24 August 2026). Both produce an .ipa and an .aab and both pass the three-question test above.

What sits outside the category is anything whose screens are a browser engine, however it is packaged. The strip at the top of this page is the whole taxonomy: native binary, wrapped web view, PWA, and the tells that separate them.

For how to spot which category a builder's output falls into, read how to identify native apps and native builders.

React Native. Bubble's mobile page says it builds "true native apps on React Native, not web pages in a wrapper", and a Bubble engineering manager wrote on 18 February 2026 that the mobile engine had moved to React Native's new architecture, on React Native 0.81.5 (bubble.io/mobile and forum.bubble.io, both read 19 September 2026).

Two caveats, both from Bubble’s own pages. The mobile builder is still labelled BETA on bubble.io/mobile today, and the forum post on the new architecture (forum.bubble.io, 18 February 2026) notes that live apps stay on the previous engine until you make a new build. And Bubble does offer a WebView element for reusing web pages inside a mobile view; its quick start guide warns that “native features like location, camera, or push notifications will not work inside a WebView” (manual.bubble.io, read 19 September 2026). So a Bubble mobile app is native by default and becomes a web view only screen by screen, where you choose to embed one.

The trade you make is ownership. Bubble’s manual states that “Bubble apps can only be run on the Bubble platform; there’s no way of exporting your application as code” (manual.bubble.io, read 19 September 2026). The React Native project exists, but it stays inside Bubble. Store costs are the usual ones and Bubble lists them itself: $99 a year for Apple, $25 once for Google Play.

What that means if your app already lives in Bubble and you want it in the stores is Bubble versus Newly for mobile apps.

A native mobile app is an app compiled for iOS or Android, installed from the App Store or Google Play, with its interface drawn by the platform's own components rather than a browser engine.

The useful version of this question is how to read a builder’s marketing. Phrases that mean native: React Native, Expo, Flutter, Swift, SwiftUI, Kotlin, Jetpack Compose, .ipa, .aab, TestFlight, App Store Connect. Phrases that mean a web app is involved somewhere: PWA, “installable”, “app-like”, “native-like”, “works on any device”, Capacitor, Cordova, “wrapper”. Lovable’s FAQ is a clean example of the second kind: Lovable “builds web applications”, and its route to the stores is a PWA or a wrapper such as Capacitor (docs.lovable.dev, read 19 September 2026). Nothing wrong with that, as long as you know which one you bought.

The checklist for telling the two apart before you pay is in how to tell whether a builder produces real native code.

Native app development is building an app against a platform's own SDK so that it compiles to a package for that platform, and in 2026 it happens at three levels: the platform languages (Swift with SwiftUI or UIKit on iOS, Kotlin with Jetpack Compose on Android), cross-platform frameworks that still produce native packages (React Native, Flutter), and AI builders that write the React Native or Flutter project for you.

Level one, platform languages. One codebase per platform. Apple’s SwiftUI “helps you build great-looking apps across all Apple platforms with the power of Swift” (developer.apple.com/swiftui, read 19 September 2026); Jetpack Compose is “Android’s recommended modern toolkit for building native UI” (developer.android.com/compose, read 19 September 2026). Day-one access to every new OS feature, and two teams.

Level two, cross-platform frameworks. One codebase, two packages. React Native renders the platform’s own views from JavaScript; Flutter compiles Dart to machine code and draws its own widgets.

Level three, AI builders. These write a level-two project. Newly and Replit output React Native with Expo (docs.newly.app, docs.replit.com, both read 19 September 2026; Newly v2 projects are Expo projects too, with an app.json the TestFlight step requires, docs.newly.app/publish/testflight); Bolt “automatically uses Expo” when you ask it for a mobile app (support.bolt.new); Bubble’s mobile builder is React Native; FlutterFlow projects run with the Flutter SDK. One builder reaches level one: Rork Max writes SwiftUI compiled with Xcode and Kotlin with Jetpack Compose (rork.com/faq, read 19 September 2026). The level decides who can maintain the app in a year, so know it before the first prompt.

The level-two trade-offs, including how testing differs, are in cross-platform app development without coding.

Two ways, depending on what changed: a fix to the JavaScript layer of an Expo or React Native app can ship over the air in minutes through a service such as EAS Update, while anything that touches native code, permissions or the SDK version needs a new binary submitted to the stores, which on iOS means Apple review, typically one to three days according to Newly's own submission guide (docs.newly.app, legacy guide, read 19 September 2026).

Expo’s documentation draws the line. EAS Update lets an app “update its own non-native pieces (such as JS, styling, and images) over-the-air”, and cannot make a “change to native code or native dependencies” or “anything that requires a new app binary version”; for those, “use EAS Build to create and submit a new app binary” (docs.expo.dev, read 19 September 2026).

Apple permits the first kind within limits. Guideline 2.5.2 says apps “may not download, install, or execute code which introduces or changes features or functionality of the app” (developer.apple.com, guideline 2.5.2, read 19 September 2026). A bug fix to the same app’s JavaScript is the accepted use; a new feature slipped in over the air is not.

For the no-code tools, read the vendor’s page and check which product it describes; Newly has had two since 15 September 2026 (docs.newly.app/whats-new). Classic builder: a new build from Launch > Deploy, iOS compiled in 5 to 15 minutes and submitted to App Store Connect automatically, Android as an .aab you upload in Play Console (docs.newly.app, legacy guide, read 19 September 2026). Newly v2: the agent builds and uploads the iOS app to TestFlight and App Store Connect, you submit for review yourself, and “Newly v2 doesn’t produce Android release builds (APK or AAB), signing keys or Google Play uploads” (docs.newly.app/publish, read 19 September 2026). Neither documents an over-the-air channel, so budget review time for every fix.

What else needs doing after launch, and roughly what it costs a year, is in the app maintenance guide.

A native app is installed from a store and compiled for the operating system, with direct access to the device; a web app is a URL opened in a browser, with no install and only the access the browser allows.

The decision usually comes down to a single question: do you need the store, a push notification, or the app to work with the network off? If the answer to all three is no, the web app is the better product, because it costs less to change and reaches everyone with a link. If any of them is yes, you are building native, and the only remaining choice is which framework writes it.

The blur comes from the icon. A web app can be added to the Home Screen and look installed, and a native app can be nothing more than a web view in a package, which is why the strip at the top of this page tests behaviour rather than appearance.

The three-way comparison with numbers is native apps vs web apps vs PWAs.

"Native" means built for the platform it runs on: compiled for iOS or Android, drawn with that system's own interface components, calling its APIs directly. It does not mean fast, good, or downloaded, which is how the word gets stretched in marketing.

Two stretches to watch for. “Native-like” is a web app styled to look installed. “Native wrapper” is a web view inside a store package, which is exactly what Apple’s guideline 4.2 is aimed at when it asks for “features, content, and UI that elevate it beyond a repackaged website” (developer.apple.com, guideline 4.2, read 19 September 2026). React Native, despite the confusing name, is the honest case: its own tagline is “Written in JavaScript, rendered with native code” (reactnative.dev, read 19 September 2026), and the rendering is what the word refers to.

For the performance side of what the word buys you, see why native code beats web view apps.

Yes. As of 19 September 2026, Newly, Replit, Bolt (through Expo), Rork and Bubble's mobile builder (beta) all output native projects rather than web apps, and FlutterFlow outputs Flutter; Lovable does not, by its own FAQ ("Lovable builds web applications").

The one question here where Newly is the direct answer, so once: Newly writes a React Native and Expo project, “standard React Native/Expo code that any developer can understand, modify, and maintain” (docs.newly.app/legacy/concepts, read 19 September 2026). How much of the store work it does depends on which Newly you are on, and there have been two since 15 September 2026. The classic builder compiles the iOS build, submits it to App Store Connect itself and produces the Android App Bundle you upload to Play Console; it exports code to GitHub or a ZIP. Newly v2 builds and uploads the iOS app to TestFlight and App Store Connect, leaves the review submission to you, produces no Android release builds, and hands you the code through its CLI with no GitHub sync (docs.newly.app/publish, docs.newly.app/code, both read 19 September 2026).

The others, from their own pages on the same day. Replit builds with React Native and Expo, “renders platform-native UI components, not a webview”, and guides you to the App Store, but “publishing to Google Play is not yet supported by Replit” (docs.replit.com). Bolt “automatically uses Expo” for a mobile app and leaves theeas buildstep to you (support.bolt.new). Rork Pro exports React Native and Expo, Rork Max a SwiftUI Xcode project (rork.com/faq). Lovable’s store route is a Capacitor wrapper around web output (docs.lovable.dev).

To verify any of them in an afternoon: export the project and look for an app.json, an ios or android folder, a pubspec.yaml or an Xcode project; a web app gives you an index.html. Install the build through TestFlight or an APK, switch on airplane mode and open it. The prompt we used for that test is below.

Build an employee management app for a small team. Managers see a roster of employees, open an employee to see their details and shifts, assign shifts for the week, and approve or decline time-off requests. Employees see only their own shifts and can request time off.

The full field, sorted by native or web output, code ownership and bundled backend, is AI app builders that build native apps, compared.

Nobody publishes reliable price data for React Native apps specifically; the $30,000 to $150,000 figures in agency blogs are marketing estimates, so here is what can be sourced: freelance React Native developers on Arc's marketplace "typically charge between $60-100+/hour (USD)" (arc.dev, read 19 September 2026), the stores cost $99 a year (Apple) and $25 once (Google), and an AI-builder subscription that emits a React Native project starts at $25 a month (newly.app/pricing, checked 19 September 2026).

A freelance or agency build is hours multiplied by a rate, and only the rate is public. On Arc’s own figure (arc.dev, read 19 September 2026), a 400-hour build, a plausible first version with a login, a few screens and a backend, comes to $24,000 to $40,000; a 1,500-hour build to $90,000 to $150,000. The hours are the number every quote hides, and they depend on the app, not on React Native.

The subscription route replaces the hours with your own. Newly’s entry plan is $25 a month on both the classic builder and v2 (newly.app/pricing, docs.newly.app/billing, both checked 19 September 2026; the two count credits differently, so we print the price and not the credits), and the employee management app in the prompt above took two Build prompts on 10 September 2026. Add the same store fees everyone pays: $99 a year for the Apple Developer Program (developer.apple.com) and $25 once for Google Play (support.google.com), both read 19 September 2026. What $25 does not buy is someone else’s judgement about what to build, which is most of what the 400 hours are for.

Either way the recurring cost is maintenance, not the build: an OS release every autumn and a review cycle per fix, for the life of the app.

The wider cost picture, hourly rates by region and a three-year comparison, is in how much it costs to build an app without coding.

Yes, since 4 August 2026: Bubble's post "The Bubble AI Agent Goes Mobile" says the Agent can now "fully build and edit native mobile apps", still in beta and free while it rolls out (bubble.io/blog, read 19 September 2026).

What it produces is the React Native mobile app described in the Bubble question above, publishable “directly to the App Store and Google Play from the Bubble editor” (bubble.io/blog, 4 August 2026), with the same two conditions: the mobile builder is in beta, and the code cannot leave Bubble.

The part that is new in the August post is the workflow rather than the output. The Agent builds the mobile screens, workflows and data, can be given screenshots of an existing web frontend to replicate, and works against the same backend as the web app, “one database and one set of workflows”, so a Bubble web product gets a mobile app extended from what already exists rather than started again. Treat the beta label literally: build something small first and take it through TestFlight before committing a real product to it.

How that compares with a builder that hands you the project is in Bubble to mobile app: what your options are.

A native application is any program compiled for the operating system it runs on, so the term covers a macOS or Windows program as well as a phone app; on mobile it means the same as native app: an .ipa or .aab installed from a store and drawn with the platform's components.

The desktop history explains the word. On a computer the alternative to a native application was a website in a tab, and later a browser wrapped up as a program. Phones reproduced the same three-way split, native binary, wrapped web view, installable web app, and added the two things that make it matter more: a store with a review process at the door, and hardware the browser is not allowed to touch. The same test applies at every size: compiled for that OS, calling its APIs, drawing with its components.

For the mobile-specific consequences, read native code versus web view on phones.

Web apps win on reach, on the cost of shipping a change and on having no gatekeeper; native apps win on device access, on offline reliability and on notifications and store presence. The table gives three of each, with the source each row can be checked against.

That is the native app vs web app pros and cons list in six rows, and two things it cannot show. The rows where web wins are about your cost and speed; the rows where native wins are about what the user gets. And the third row cuts both ways: no gatekeeper also means no listing, so a web app has to be found by search or by link, never by browsing a store.

The version of this table with hybrid apps as a third column is native vs hybrid vs PWA, compared.

A progressive web app is a website with a manifest and a service worker that a browser can install to the Home Screen; on iOS as of 19 September 2026 it still cannot use Bluetooth, NFC or USB, receives push notifications only once it has been added to the Home Screen (iOS 16.4, February 2023), and cannot be listed in the App Store; the first two limits come straight from Apple's WebKit documentation.

Notifications. “Now with iOS and iPadOS 16.4, we are adding support for Web Push to Home Screen web apps”, WebKit announced on 16 February 2023; the site must ship a manifest with display set to standalone or fullscreen, the user must add it to the Home Screen, and permission must be asked “in response to direct user interaction” (webkit.org, 16 February 2023). A PWA opened in a Safari tab gets no push at all.

Hardware. WebKit’s tracking prevention policy lists sixteen features it has “decided to not yet implement due to fingerprinting, security, and other concerns”, among them Web Bluetooth, Web NFC, Web USB, WebHID, the Serial API and the Battery Status API (webkit.org/tracking-prevention, read 19 September 2026). A native app reaches all of that through the platform, behind a permission prompt.

Storage and the store. Safari deletes a site’s script-writable storage after seven days without a visit, though “web applications added to the home screen are not part of Safari and thus have their own counter” (webkit.org, 24 March 2020). And a PWA has no App Store listing, which is why Glide, whose apps are PWAs, tells its users the stores are “not supported”. What the PWA keeps is real: no review, instant updates, one codebase.

The decision framework for choosing between the three is in the native, hybrid and PWA comparison.

Five apps whose makers document how they are built: Signal (Swift on iOS, Kotlin and Java on Android), Duolingo (Android "100% Kotlin" since 2020), Uber (Swift and Kotlin on its RIBs architecture), Discord (React Native, on Android since 2022) and Shopify ("we have migrated all our apps to React Native", January 2025); and one famous wrapped web view, Facebook's 2012 iOS app, rebuilt natively that August because "our iOS app was falling short".

What makes each native. Signal’s iOS repository is about 98 percent Swift by volume, its Android repository Kotlin and Java (github.com/signalapp, read 19 September 2026): one codebase per platform, each against its own SDK. Duolingo: “Duolingo for Android was a Java app for its first five years of existence. Two years later, it’s now 100% Kotlin!” (blog.duolingo.com, 6 April 2020). Uber’s RIBs is “the cross-platform architecture framework behind many mobile apps at Uber”, Kotlin and Java on Android, Swift on iOS (github.com/uber/RIBs, read 19 September 2026).

The next two pass the rendering test with JavaScript logic. Discord: “Discord’s desktop and mobile clients are built with React & React Native respectively”, and it moved “our Android client to React Native in 2022” (discord.com/blog, 5 March 2025). Shopify: “over the past 5 years, we have migrated all our apps to React Native”, with “sub-500ms (P75) screen loads” and the warning that “100% React Native should be an anti-goal” (shopify.engineering, 13 January 2025).

The wrapped example. Facebook’s post “Under the hood: Rebuilding Facebook for iOS” says the earlier app leaned on HTML5 and was rebuilt in Objective-C because “people expect a fast, reliable experience and our iOS app was falling short” (engineering.fb.com, 23 August 2012). A current one, chosen on purpose: 37signals builds the HEY apps on what is now Hotwire Native, which “wraps a web view within a native shell and renders HTML from your server” (native.hotwired.dev, read 19 September 2026; dev.37signals.com, 20 September 2023).

The longer list, grouped by category, is on the native apps overview page.

Four frameworks cover almost every native app shipped in 2026: React Native (Meta, JavaScript or TypeScript, renders the platform's own views), Flutter (Google, Dart, draws its own widgets with Impeller and compiles to ARM machine code), SwiftUI (Apple, Swift, Apple platforms only) and Jetpack Compose (Google, Kotlin, Android only); AI builders mostly emit the first two.

React Native: “Written in JavaScript, rendered with native code”; “Meta released React Native in 2015 and has been maintaining it ever since” (reactnative.dev, read 19 September 2026). Flutter: “has its own implementations of each UI control, rather than deferring to those provided by the system”, and release builds are “compiled directly to machine code” (docs.flutter.dev, updated 24 August 2026). SwiftUI: “a declarative syntax, so you can simply state what your user interface should do”, for “all Apple platforms” (developer.apple.com/swiftui, read 19 September 2026). Jetpack Compose: “Android’s recommended modern toolkit for building native UI”, with “intuitive Kotlin APIs” (developer.android.com/compose, read 19 September 2026).

Which AI builders emit which, from their own pages on 19 September 2026. React Native with Expo: Newly, Replit, Bolt’s Expo template, Rork Pro and Bubble’s mobile builder. Flutter: FlutterFlow, whose projects run with the Flutter SDK and flutter run (docs.flutterflow.io, updated 22 May 2026). SwiftUI and Jetpack Compose: Rork Max, which “uses SwiftUI, Apple’s own native framework, compiled with Xcode” and produces “native Kotlin apps with Jetpack Compose for Android” (rork.com/faq). Web only, with a wrapper as the store route: Lovable.

The AI tools cluster on React Native for a practical reason: there is far more public TypeScript and React than Dart or Swift, so generated code needs less correction. That is a fact about the tools, not a verdict on the frameworks.

The two cross-platform frameworks compared head to head are in Flutter vs React Native, an honest comparison.

A mobile web application is a website designed for phone screens and opened in the browser; a native application is installed from the App Store or Google Play and runs as compiled code with direct access to the device. The web version is cheaper to change and reachable by anyone with a link; the native version can work offline, use the camera, Bluetooth and push notifications, and be found in a store. If you need none of those, build the web version first.

That is the whole answer, and the nineteen questions above are the evidence for each clause. “Mobile web application” also covers the responsive site you may already have, so the real question is whether the phone version needs anything the browser cannot give it. The one thing a mobile web app can never be is found in a store; the one thing a native app can never be is opened from a link by someone who has not installed it.

For the side-by-side tables, see native apps vs web apps vs PWAs, compared.