Progressive web apps, native applications, and hybrid WebView containers each make different trade-offs. A PWA can reuse web delivery and browser capabilities. Native code can access platform APIs directly. A hybrid container combines a web interface with selected native integrations, but also introduces a boundary between the two runtimes.
Define the workload before measuring
List the user journeys that matter: cold start, sign-in, opening a large list, uploading media, receiving a notification, working with intermittent connectivity, and returning to the app after it has been backgrounded. The right test depends on those journeys, not on a synthetic benchmark alone.
Use the same backend, data set, device class, network profile, and account state for each candidate. Record operating system version, browser or WebView version, build type, and test conditions so results can be reproduced.
Compare lifecycle and background behavior
Background work is constrained by mobile operating systems. Browser service workers are not equivalent to an always-running native process, and a hybrid wrapper does not bypass platform scheduling rules. Test notification delivery, resume behavior, queued changes, and recovery after process termination on the devices that matter to the product.
For workflows that must continue reliably outside the foreground, evaluate platform APIs and system policies early. Do not promise continuous background execution based solely on the choice of app shell.
Measure memory and battery responsibly
Capture memory across a sequence of real screens, not only immediately after launch. Include image-heavy views, long sessions, navigation back and forth, and periods of inactivity. Note whether memory is retained, released, or reclaimed after the app is backgrounded.
Battery use should be measured over a controlled duration with the same brightness, radios, and foreground tasks. Network polling, location updates, rendering frequency, and wakeups can dominate the result independently of whether the interface is native or web-based.
Use a comparison matrix
- Startup: cold and warm launch time, and time to an interactive screen.
- Rendering: scroll smoothness and responsiveness under the target data volume.
- Memory: peak, steady-state, and post-navigation use.
- Battery: energy over a consistent user journey and idle period.
- Lifecycle: resume, offline behavior, push delivery, and process recovery.
- Delivery: release cadence, review requirements, and rollback path.
Choose by constraints, not fashion
A PWA may suit a product with frequent iteration and modest platform integration. A Kotlin-based native app can be a better fit when Android platform APIs, lifecycle control, or a more deeply integrated mobile experience are required. A hybrid WebView shell is another option, but its bridge and memory costs should be measured as part of the complete application—not treated as free.
Publish measured numbers only with the tested device, OS, build, workload, and methodology. Without that context, a percentage comparison is not actionable and can mislead more than it helps.