Please Poke Holes into my strategy: Building a 100% Web-Code mobile app to avoid the need for constant app updates and faster QA times.

TL;DR: I want to build a Remote Fitness Coaching app using 100% web code (HTML/CSS/JS) wrapped in a native container. The goal is to test entirely in the browser and push UI/logic updates Over-The-Air (OTA) to bypass the 2-to-3 day App Store review cycles for minor changes.I'm using native plugins for HealthKit and Push Notifications, and offloading video calls to the native Google Meet app. Looking for veterans to poke holes in this strategy.

The context:
My team is re-building a mobile app for remote fitness coaching. We want to maximize our velocity. Instead of maintaining separate codebases and waiting for App Store approvals every time we tweak a layout or fix a typo, I want to deploy a 100% web-based UI. We will test the app in the browser, and then push updates Over-The-Air (OTA) so the mobile app silently and seamlessly updates its own HTML/CSS/JS.

The Proposed Architecture:

1. The Core: Standard HTML/CSS/JS web app wrapped in a Capacitor shell.
2. OTA Updates: All UI, business logic, and styling changes will be pushed via OTA updates. We will only submit to the App Store when we explicitly need to update the native container or a plugin.
3. Hardware Integrations: We will use native plugins for Apple HealthKit / Android Health Connect (to pull users' daily steps and heart rate for their trainers) and native Push Notifications.
4. Video Calling: Instead of fighting WebRTC inside a mobile WebView (which I hear is a battery drain and a background-state nightmare), we are offloading live check-ins entirely. We will use deep links (gmeet://) to seamlessly hand the user off to the native Google Meet app for their 1-on-1 coaching sessions.
5. App Store Reviews: Using an in-app review Capacitor plugin to trigger the native OS rating prompt so we can collect reviews without forcing users to leave the app.

My Defense Against App Store Rejection: I know Apple aggressively rejects "thin wrappers" and apps that are just "repackaged websites" under Guideline 4.2 (Minimum Functionality).My argument is that by natively utilizing Apple HealthKit to pull biometric data and using native Push Notifications, the app provides enough deep OS-level utility to prove it belongs in the App Store.

I’m trying to build a highly maintainable app where we develop the UI once and never have to worry about App Store delays, but I don’t want to build a house of cards. Any insights, warnings, or alternative suggestions are highly appreciated! Please poke holes.