Most web teams that want an app in both stores look at hybrid first, because it skips Swift and Kotlin entirely. The usual picks are Apache Cordova and Capacitor, with Ionic Framework on top for the interface.
A hybrid app renders web code (HTML, CSS and JavaScript) in a WebView inside a native shell, and the same codebase installs on iOS and Android through the app stores.
The WebView is what puts an app in this category, not the shared codebase. React Native and Flutter share code across platforms too. The React Native documentation describes native views, though, and the Flutter architecture guide describes Flutter’s own rendering engine.
Apple adds a limit of its own. The App Review Guidelines (updated October 16, 2026) reject apps that are only a repackaged website, so the shell needs real app features.
What Are Hybrid Apps?
Take a web app, put it in a native container, and let a WebView draw the screens. That’s a hybrid app, and the same code installs on iOS and Android from the app stores.
The WebView is where the line sits. Sharing code across platforms isn’t enough, since React Native and Flutter do that without rendering web content in a WebView.
The web layer is plain HTML, CSS and JavaScript or TypeScript, so a web team already has the skills. It runs inside a native shell, which is an Xcode project for iOS and an Android Studio project for Android, and that shell is what actually goes to the stores. Plugins cover the hardware side, with JavaScript bindings to the camera, location, files and other device features.
Hybrid is one route into cross-platform app development, and the one closest to the web.
Compared with ordinary web apps, which live in a browser tab, a hybrid app installs from a store and reaches device hardware through plugins.
Vendors keep renaming the category. Capacitor’s documentation calls its output “Web Native apps” and presents it as the next step after hybrid apps.
How Hybrid Apps Work Inside a Native Shell
The app launches as a native app, loads a bundled web page into a WebView, and passes device requests from that page to native code through a JavaScript bridge. Users see one app. Underneath, a web page does the rendering.
Apache Cordova’s architecture guide describes the web app as a local file, index.html by default, that executes in a WebView inside the native wrapper distributed to the app stores.
What a WebView Does
On iOS, WKWebView displays HTML, CSS and JavaScript alongside native views, and it has replaced UIWebView since iOS 8 (Apple Developer Documentation). Android’s WebView extends the View class and runs on a Chromium-based engine (Android Developers documentation).
Android’s WebView ships with JavaScript turned off, so the shell has to switch it on before any web code runs.
The JavaScript Bridge
The bridge carries calls between web code and native features.
On Android, the platform documentation names addWebMessageListener as the recommended mechanism, with a minimum WebView version of 82.
One plugin call takes the same path on both platforms.
- Web code calls a plugin method, for example a camera capture.
- The bridge hands the call and its arguments to the native side.
- Native code (Swift on iOS, Kotlin or Java on Android) runs the request against the hardware or OS API.
- The result returns to the WebView as a JavaScript response.
The older addJavascriptInterface method carries a documented risk. It has no origin-based access control and is exposed to every frame in the WebView, including iframes, so untrusted content loaded anywhere in the WebView can reach the app’s native code (Android Developers documentation).
My habit here is simple. Load only your own bundled pages and restrict the allowed origins.
Frameworks and Tools Used to Build Hybrid Apps
Two runtimes package a web app as an installable native app, Apache Cordova and Capacitor. UI toolkits like Ionic Framework and Framework7 sit on top, and Quasar does the same job for Vue.js.
These tools belong to the wider field of cross-platform app development tools, minus the ones that don’t render in a WebView.
| Tool | Role | Detail from its documentation |
|---|---|---|
| Apache Cordova | Runtime | Plugins, even core ones, are added explicitly |
| Capacitor | Runtime | Native Xcode and Android Studio projects live in the repo |
| Ionic Framework | UI toolkit | Deploys natively through Capacitor or Cordova |
| Framework7 | UI framework | Targets iOS and Material Design only |
| Quasar | Vue.js framework | Mobile builds go through Capacitor or Cordova |
Web Languages and UI Frameworks
Ionic Framework integrates with Angular, React and Vue, and it also runs standalone through a script include (Ionic documentation, v9).
Those are the mainstream JavaScript frameworks a web team already knows, so the learning curve stays short.
Cordova brings no UI widgets and no MV* framework of its own, so the team picks one. Framework7 narrows the choice the other way and states that it is not compatible with all platforms.
PhoneGap, Cordova and Capacitor
Adobe ended development of PhoneGap and shut down PhoneGap Build on October 1, 2020, and ended its investment in Apache Cordova, according to SD Times’ coverage of the announcement.
Apache Cordova kept shipping. The latest releases are cordova-android 15.1.0 (July 22, 2026) and cordova-ios 8.1.1 (July 7, 2026), per the Apache Cordova release announcements, so claims that Cordova itself is discontinued do not hold as of October 2026.
The practical differences show up in the native projects. Capacitor’s migration guide treats the Xcode and Android Studio projects as part of the app, to be checked into source control, while the Cordova CLI overwrites platform code from shared web assets on each build.
Platform settings go straight into AndroidManifest.xml and Info.plist, and config.xml can be deleted once the migration is done. Capacitor also generates the JavaScript hooks for plugins automatically, so its own plugins need no deviceready wait, although a few Cordova plugins still expect that event.
Both runtimes put a WebView inside a native container and give web code a path to native APIs, as the Cordova overview and the Capacitor docs each describe. The real choice is workflow, generated native projects with Cordova or owned native projects with Capacitor.
Device Features Hybrid Apps Can Access Through Plugins
Plugins wrap native camera, location, notification and storage APIs behind a JavaScript interface, and that’s how a hybrid app reaches device features.
Capacitor’s v8 documentation lists 38 official plugin APIs, among them Camera, Geolocation, Push Notifications, Filesystem and Haptics.
Official, Community and Cordova Plugins
Official plugins come from the Capacitor team, and community plugins from the Capacitor Community. Cordova plugins get their own section in the Capacitor plugin docs.
Biometric login and Bluetooth have no entry in that official list, so they come from a community or third-party plugin.
Apache Cordova starts every new project with zero plugins, so even the core ones for camera, geolocation and file access must be added explicitly (Apache Cordova documentation).
When No Plugin Exists
A missing plugin means writing native code.
Capacitor’s plugin documentation says most plugins need only Swift or Objective-C for iOS and Java or Kotlin for Android, because the JavaScript hooks are generated automatically.
That keeps the work small, but it ends the web-skills-only promise, since someone on the team has to read Swift or Kotlin. A community plugin is also only as current as its maintainers, and every plugin you add is one more dependency to keep up to date.
Hybrid Apps vs Native, Web and Cross-Platform Apps
What draws the screen is the main difference. Hybrid apps use web content in a WebView, native apps use the platform’s own views, and web apps use the browser. React Native and Flutter apps use native views or their own rendering engine.
| Type | Draws the screen with | Written in | Reaches users through |
|---|---|---|---|
| Hybrid app | Web content in a WebView | HTML, CSS, JavaScript | App stores |
| Native app | The platform’s own views | Swift, Kotlin or Java | App stores |
| Web app | The browser | HTML, CSS, JavaScript | A URL |
| React Native or Flutter app | Native views, or Flutter’s own engine | JavaScript with React, or Dart | App stores |
Fully native apps are written in Swift or Objective-C on iOS and in Kotlin or Java on Android, which means two codebases and two skill sets.
Progressive web apps sit on the web side of the line, because they run in the browser instead of a native shell.
Where React Native and Flutter Fit
Sources disagree on whether these two count as hybrid. The platform documentation settles it.
React Native components map to real Android and iOS views at runtime, per the React Native documentation. Flutter draws its controls itself through the Impeller engine instead of using system widgets, according to the Flutter architecture guide.
Some agency guides still file both under hybrid. This article counts only WebView-based tools, because neither framework renders web content.
Are Hybrid Apps Slower Than Native Apps?
On animation-heavy screens, yes, and WebView memory needs careful handling. On ordinary screens the measured gaps are small.
Neither Apple’s nor Google’s WebView documentation publishes a hybrid-versus-native benchmark, so percentages in comparison guides deserve caution.
Memory is the first thing to watch. Android’s documentation says WebView renders in a separate isolated process on Android 8.0 and higher and allocates most of its memory natively, outside the Java heap, so unmanaged WebView instances can leak memory and cause out-of-memory crashes.
Then there’s interaction overhead. The Flutter architecture guide says frameworks that connect interpreted app code to platform UI libraries add overhead, and it calls that overhead significant where UI and app logic interact heavily.
Ionic’s own 2022 comparison blog measured a cold boot of about 1.5 seconds for both Ionic and React Native, with scrolling frames at or just under 16.67 milliseconds.
Ionic ran that test, and it compared against React Native, not Swift or Kotlin. It shows parity with another cross-platform tool, not with native.
Plan around the gap. Hybrid suits content and form screens, and it’s a poor fit for gesture-driven ones.
Cost, Development Time and App Store Publishing
A hybrid app replaces two native projects with one web codebase, which is where the time and cost savings come from. Store submission works like any native app, with one extra review risk for apps that are only a wrapped website.
Cost and Maintenance
One web team covers the interface, and Capacitor’s plugin documentation says native and web developers can split plugin work.
Hardware is a catch. Capacitor’s FAQ gives a flat no on building iOS apps without a Mac, since cloud builds cannot test on a device or simulator.
Upkeep never really stops either. Capacitor’s docs carry an upgrade guide for every major release from 2.0 to 8.0 (plus one for 8.5), and docs for v9 are already listed as next.
No official source publishes a savings percentage for hybrid builds, and the figures in vendor guides come without a stated method, so this article does not repeat them.
For a full budget picture, see how mobile app development cost adds up by feature and team.
Publishing to the Apple App Store and Google Play
Store review treats a hybrid app like any other app, with one trap.
Google Play requires new apps and updates to target Android 16 (API level 36) from August 31, 2026, according to its target API level requirements.
Apple’s guideline 4.2 says an app needs features, content and UI that go beyond a repackaged website (App Review Guidelines, updated October 16, 2026).
Guideline 4.2.6 adds that apps built from commercial templates or app generation services are rejected unless the content provider submits them directly.
Capacitor has dedicated guides for deploying to the App Store and to Google Play, so the usual app deployment steps apply. Build the signed package in Xcode or Android Studio, then upload it.
The fix for a guideline 4.2 rejection is product work, not packaging. Add a feature a browser tab can’t offer, such as push notifications or offline storage.
When Hybrid Apps Are the Wrong Choice
Skip hybrid when the interface has to match each platform’s own look, or when the product leans on gesture-heavy or graphics-heavy screens. Old WebViews on your target devices are the other deal breaker.
Ionic Framework emulates native UI guidelines with web components (Ionic documentation, v9). A design team that wants controls to follow Apple’s Human Interface Guidelines exactly gets an imitation, not the real views.
On older devices, Capacitor v8 officially supports iOS 15+ and Android 7+, and on Android it needs Chrome WebView 60 or higher. An Android 7 emulator without a newer WebView shows a blank white screen, according to the Capacitor FAQ.
Games split the sources. Capacitor’s games guide points to WebGL and canvas rendering through engines such as Phaser, while the usual advice files graphics-heavy apps under native.
Both can hold, because a canvas game draws pixels instead of laying out page elements. Test the game itself, not the category.
Run through these in order and stop at the first yes.
- Does the core screen depend on smooth gestures, long animated lists or graphics beyond a canvas game? Build native, or use React Native or Flutter.
- Does a required device feature have no maintained plugin? Build that feature natively.
- Must the interface follow each platform’s design language exactly? Build native.
- Is the app mostly forms, content and workflows, built by a web team? Build hybrid.
The wider comparison of native, hybrid and cross-platform apps covers the same three-way choice in more depth.
Hybrid Apps FAQ
Can hybrid apps work offline?
Yes, as long as the web code and assets are bundled inside the app instead of loaded from a server.
Capacitor’s official Network, Preferences and Filesystem plugins cover connection status and local storage, and its Storage guide compares the options.
Are hybrid apps secure?
Not automatically. A hybrid app carries web-content risks plus the bridge to native code, so security depends on what the WebView loads.
Cordova and Capacitor each publish a security guide, and reading it before adding plugins costs little.
Which well-known apps are hybrid?
Neither store labels the framework an app uses, so lists of famous hybrid apps need a primary source.
Maintainer showcases, such as the Apps Showcase on the Framework7 site, are the verifiable starting point.
How do you test a hybrid app?
On a physical device. Capacitor’s FAQ says to check the app on real Apple hardware.
For debugging, Android WebView content opens in Chrome DevTools. iOS web content opens in Safari Web Inspector once the app marks the web view as inspectable (iOS 16.4 and later).
Do hybrid apps support live updates?
Yes, through live-update services, but choose the provider carefully. Ionic’s Appflow service, which deployed live code updates to Ionic apps without a store release, stopped selling to new customers in February 2025 and is scheduled to end on December 31, 2027. Third-party live-update services for Capacitor apps exist.
Apple’s guideline 2.5.2 bars downloaded code that introduces or changes app features, so keep live updates to fixes and content.
What to Build First Before Committing to Hybrid Apps
Before committing, build a vertical slice. That means the most demanding screen plus the riskiest device feature, run on the oldest target phones before the full build starts.
Earlier failures cost more to fix, so the order matters. Start with the riskiest plugin integration. Then do the most animated or longest screen, and push a beta build through store review last.
A plugin gap changes the team and the schedule, while a slow screen only changes code. Apple’s guideline 2.2 says apps submitted for beta distribution through TestFlight should comply with the App Review Guidelines, so guideline 4.2 problems can surface before launch.
The slice gets rebuilt, not shipped, which still costs less than rebuilding the project.
Verified on October 21, 2026 against Capacitor v8 and Apple’s guidelines updated October 16, 2026. A Capacitor v9 release or a rewrite of guideline 4.2 would change this order.
- Protecting Users and Brand Standards Across Image-Driven Platforms - November 10, 2026
- Go Cheat Sheet - November 9, 2026
- Build or White-Label Software? How Software Teams Decide What to Resell in 2026 - November 9, 2026
