It's the third time I have to build the whole stack (web+ios+android). For the first time, I used a webapp and was hoping that the ios/android experience would

It's the third time I have to build the whole stack (web+ios+android). For the first time, I used a webapp and was hoping that the ios/android experience would be good enough. Unfortunately, It wasn't and it was a big mistake. I'd only recommend this for quick mvp knowing that it'll need to be rewritten or if your audience really understand what it means to have a mobile webapp compared to a native app. I.e. if there's an IT department in place that can install it on the devices and understand the limitations. For the second time, we went with ionic/phonegap. It was a huge improvement, but we hit too many limitations and scenarios where we wanted native tweaking for animations or handling the keyboard hiding fields or the topbar acting weird, etc. You don't see those issues at first.. but they start appearing as you start doing QA on more devices and with real users. And at that point, you've invested so much in trying to make it work that you can't just go back, so you start piling weird hacks on top of weird hacks. For the third time, we went with react-native. Overall it was a great experience and unlike ionic, it's a real native app, not just a webview. We could reuse a big part of the code between web, ios and android. The issues we faced were often related to weird edge cases that are buggy within react-native itself such as input fields not working correctly when dictating or a "pull-to-refresh" supposed to be stateless but in practice being stateful and buggy if you call "refresh" on it twice within 30ms. However, it's a good feeling to know that when we'll have the time, we have the flexibility to either fix the library itself or re-write it (compared to ionic where we couldn't do much and web apps where the solution to most our problems would be to "wait a few years until the browsers decide to improve it".) If I had to do it another time (a fourth time), I'd go with react-native again but I would make sure to stress test the libraries with real data on all the devices we'd want to support. Also, it's popular in the javascript ecosystem to have libraries that depend of another library that depends of another library that wraps another library.. in most cases, it's just better to write a quick wrapper for your app and only include the inner-most library that does most of the work anyway. Otherwise you're depending on too many authors and libraries quickly go out-of-sync and you're stuck with old versions that aren't compatible with new ones.