Add the shell only for a named requirement
Keep a progressive web app when the core journey works reliably in the audience's browsers and direct web access is sufficient. Add Capacitor when a specific native integration or distribution requirement justifies maintaining mobile projects alongside the web application. An icon on a phone is not enough to decide.
A PWA enhances a web application with capabilities such as installation and offline behaviour; implementation and browser support still matter. Google's PWA learning guide treats these as separate design and engineering concerns, not a single switch that makes a website equivalent to every installed application.
Separate the browser limit from the interface problem
Before adding a container, identify the requirement that fails in the browser. A poor mobile form, confusing navigation or slow startup is not necessarily a browser limitation. Moving the same interface into another container can preserve the same problem.
Capacitor provides a native runtime for web applications and a plugin interface for accessing platform capabilities, as its official documentation explains. It is a bridge between the web application and native functionality, not an automatic redesign into platform-specific interaction patterns.
A plausible fit is an existing web product with a bounded native need. A less convincing fit is a product whose essential interaction requires extensive platform-specific behaviour throughout. In that case, compare a broader mobile architecture rather than assuming a shell will remain a small addition.
Test the lifecycle, not just the plugin call
An illustrative scanning workflow does not end when the camera returns a result. The app may be interrupted, permission may be denied, connectivity may disappear and an unfinished operation may need recovery. These states matter whether scanning is implemented through browser APIs or a native plugin.
For the PWA, test the intended browsers and installed modes on actual target devices. For Capacitor, verify the chosen plugin's supported behaviour on each target platform and establish who will maintain native changes. Documentation for a capability is not proof that the complete workflow meets the requirement.
Offline handling needs the same discipline. A cached interface cannot settle conflicting edits or guarantee that a queued action was accepted by the server. Define the product's recovery behaviour before choosing the container.
Count the additional release surface
A native shell introduces mobile project configuration, signing, store submission and platform-specific testing into the operating model. Those responsibilities need owners even if most interface code remains shared. Confirm the applicable distribution rules rather than assuming every web change can bypass review.
The web application also needs maintenance: browser changes, service worker updates, storage behaviour and authentication must be tested. The comparison is between different operating surfaces, not a maintained application and a maintenance-free alternative.
Our earlier web app or native app guide covers whether the product needs native capabilities in the first place. Clodron's app engineering work should use that decision to keep the native boundary explicit and proportionate.
Run a capability gate this week
Write the failing browser requirement as an observable acceptance test. Include permission refusal, interruption, reconnection and an application update wherever those affect the task. Run the same journey in the PWA and a small Capacitor prototype using realistic devices and accounts.
Keep the PWA if the required behaviour passes without the shell. Choose Capacitor if the native route closes a real gap and the mobile release responsibilities are accepted. If native work expands across the whole experience, reopen the architecture decision. The right container is the one that makes the difficult journey dependable without hiding its maintenance contract.