Native vs hybrid app: which approach meets your requirements?
Buyers often call every non-Swift, non-Kotlin app hybrid, but there are four approaches: native, WebView hybrid, cross-platform frameworks that render native views, and web apps or PWAs. The fastest way to choose is to list your hard requirements and check which approaches can meet each one, and at what cost in native code.
Which approach can meet each requirement?
Quick answer
Native vs hybrid app is decided by your hardest requirement: Bluetooth medical devices, HealthKit, background work or offline PHI push you toward native or cross-platform code, while content and forms fit a WebView hybrid or web app if it meets App Store rules. Agnotic Technologies tests each requirement against each approach before choosing.
| Criterion | Native | Hybrid |
|---|---|---|
| Bluetooth LE medical devices | Native: full platform BLE APIs. Cross-platform: through native modules | Hybrid: only through a native plugin. PWA on iOS: not available in Safari |
| HealthKit or Health Connect | Native frameworks; cross-platform through native modules | Hybrid: through a native plugin. PWA: no access |
| Background location and background tasks | Platform background modes, subject to store review | Hybrid: through native plugins with care. PWA: not available |
| Push notifications on iOS | Apple Push Notification service | Hybrid: native plugin. PWA: Web Push for Home Screen web apps since iOS and iPadOS 16.4 |
| Offline encrypted PHI storage | Keychain, Keystore and encrypted databases | Hybrid: needs a native secure storage plugin. PWA: browser storage only; avoid PHI |
| App Store minimum functionality (4.2) | Rarely an issue for a real native app | A repackaged website risks rejection; the app needs app-like features |
| Downloaded code (2.5.2) | No downloading code that changes features | Same rule; over-the-air web bundles must not add or change features |
| In-app web browsing (2.5.6) | Must use WebKit on iOS, unless entitled otherwise | Built on WebKit on iOS already |
| Interface rendering | Native views | Web views inside a native shell, or the browser |
| Moving later | Already native | Wrap web screens in a native shell first, then replace screens feature by feature |
What they are
What is Native
A native app is written with the platform's own toolkits, Swift or Objective-C on iOS and Kotlin or Java on Android. Cross-platform frameworks such as React Native sit on the same side of the line: React Native's documentation says it creates the corresponding Android and iOS views at runtime, so the interface is made of native views.
What is Hybrid
A hybrid app runs web code, HTML, CSS and JavaScript, inside a native WebView container, with plugins for device features; Capacitor describes itself as a native runtime for web apps with a plugin API for Swift on iOS and Java on Android. A web app or PWA runs in the browser and can be added to the home screen.
Key differences
Is React Native a hybrid app?
Not in the WebView sense. React Native's documentation states that at runtime it creates the corresponding Android and iOS views for its components, so the user sees native views driven by JavaScript. A WebView hybrid renders HTML inside a browser view. Treat React Native and Flutter as cross-platform native, and compare them with native on device and performance needs, not with WebView apps.
What do App Store rules mean for a hybrid app?
Apple's App Review Guideline 4.2 expects features, content and interface that make an app more than a repackaged website, and 4.2.2 says apps should not be primarily web clippings or a collection of links. Guideline 2.5.2 bars downloading code that introduces or changes features. A hybrid app passes when it has real app features and ships feature changes through review.
Can a web app or PWA replace a native app?
For some products. WebKit added Web Push for Home Screen web apps in iOS and iPadOS 16.4, which removed one long-standing gap. Device access is still the limit: a PWA cannot read HealthKit, run reliable background work or reach most Bluetooth medical devices on iOS. If the requirements list is all content, forms and video, a web app plus later native shells is a sound start.
Native vs web app in healthcare: what changes?
Healthcare adds three hard requirements. HealthKit and Health Connect are native frameworks, and Apple's guidelines say HealthKit should be used for health and fitness purposes and integrate with the Health app. Bluetooth medical devices need native BLE access. Offline PHI needs encrypted storage the platform protects. Any one of them moves at least that feature into native or cross-platform code; for the two health data APIs side by side, see HealthKit vs Health Connect.
Should you build the web app or the mobile app first?
Build the web app first when users do the work at a desk, need no device features, find you through search and you ship changes often; build the mobile app first when users work on the move, need the camera, Bluetooth or health data, or return daily from a home screen. Agnotic Technologies weighs six factors before choosing. Where users do the work decides most cases. Device features needed push toward mobile. How users find you matters because search sends people to web pages, while app stores need a listing and a reason to install. How often you ship changes favors web, since a web release goes live at once and every mobile release passes store review. Who pays and signs up matters too: business buyers usually sign up and pay on the web, while consumer subscriptions often start in the app. Both versions talk to one API, so the second client reuses the backend, and the steps for moving to native later are listed below.
When to use each
When to use Native app
- You connect to Bluetooth LE medical devices or wearables.
- You read or write HealthKit or Health Connect data.
- You need background tasks, background location or reliable notifications.
- You store PHI offline and want the platform's encrypted storage and keychain.
When to use Hybrid app
- The app is mostly content, forms, scheduling and messaging.
- You already have a web app and want a store presence quickly.
- Device needs are light and covered by existing plugins.
- One web team must ship to the browser, iOS and Android.
How do you move from a hybrid or web app to native later?
1. Keep the backend and API the same. Every approach talks to the same API, so the move is a client change, not a platform rebuild.
2. Move device features first. Put Bluetooth, health data and background work in native modules behind a small bridge while the rest of the app stays web.
3. Replace screens by traffic. Rebuild the screens people use most in native or cross-platform code, one release at a time, and leave rare screens in the WebView.
4. Keep store rules in view. Ship each change through review rather than as downloaded code, in line with Guideline 2.5.2.
5. Retire the WebView once the remaining web screens are few, or keep them where content changes often and device access is not needed.