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.
You can use the one postgresql instance and have multiple databases on that instance. You do not need to create separate instances (one for each database). If you have specific requirements because maybe a queue database or cache database has different infrastructure requirements, then you should be able to set up additional servers and use the accessories for each of those servers to host their own container of postgresql. But if we're talking a more simple setup (everything on one box/vm) then you would need just the one postgresql instance (even with multiple databases).
