I think your approach is sound in what you'd typically do and this is a similar approach to what I take. However, it does cause some issues when trying to deploy an accessory like PostgreSQL because the private network is inaccessible from the outside. However, you can use a proxy which is what I do. I have a separate VM that is on the same network (could be the web server or another server that is accessible from the internet) and the Kamal deployment comments get tunneled through the proxy. This means that Kamal would have access to the PostgreSQL server through the proxy. I'll then allow-list/white-list the IP Addresses that can access the proxy server to prevent unauthorized access.
That can be a tough decision. It greatly depends on what the application needs to do (or have access to) on the phone's hardware and also availability if the user is not in cell/wifi range. If internet access is not a concern as it is a core requirement then a Turbo Native approach could be the easiest path. This way you wouldn't need to maintain the API as well as a full fledge mobile interface as the ActionViews would be used. Alternatively, if there aren't many requirements for the hardware of the device (no need for NFC, camera, GPS, etc), you may be able to get away with a PWA.
Honestly, I would explore these two routes first before jumping to a React Native approach.
Yea, I'm sure they have some pretty strict regulations with that kind of stuff. Turbo Native has come very far with integrating with hardware so you can use all of the hardware components that you need to, but you also would have to create the iOS app and Kotlin app. But it's still a lot less work than a React Native app or a standalone app. Hybrid is the current flavor of the "rails way". However, if that isn't an option to go hybrid due to requirements or policies, then React Native, Xamrin or similar could still be an easier route than a standalone Android and standalone iOS app.