In the initial App Store land rush, success could come by simply being in a niche early. I was out in San Francisco during this period and in the echo chamber I had everybody telling me that the App Store was great for discovery. It was.
For the first few years of the App Store, early adopters were excited about installing apps. Futher, the Android interface guidelines were…bad and web apps were slow. The Apple core fandom along with the easy monetization meant the App Store was the place to be for independent app development and you wound up with a feedback loop of the best apps showing up on iOS first where they got picked up by the early adopters. The iOS customer base proved much more willing to spend which further drew developer interest.
After a couple years, however, the land rush was over. The niches occupied, later adopters stop installing new apps constantly, and the Tyranny of Choice rears its ugly head (i.e. people don't scroll more than a page or two). The normal power law of markets comes into play so if you aren't on a top installed/grossing app list somewhere, you aren't making money.
The native developers, of course, managed to figure this out and blogged about it a lot. The solution, as far as I can tell, is to use some out-of-store channel to juice your downloads to get high enough on a list to get traction. I don't keep that much track of it since I'm not a native dev but it doesn't sound that fun.
Once people discover the app, there's the install process. It's pretty simple on wifi or LTE but mobile apps tend to be orders of magnitude larger than web apps and that can be pretty painful on slower connections. In either case, you still have to make a decision to download and that's one more step in the acquisition funnel. I know the Android team announced a way to try apps without installing them to try to reduce this hurdle. I've never seen it but my device may be too old for the API.
In the meantime, web discovery is the same it's always been. You can link directly to an app on the social networks, on the news aggregators, in advertisements. You can put the app on the landing page as a demo if you want, it's just the nature of the platform.
I don't pretend to be an expert on this part of app development but from my (admittedly web centric) point of view this seems like the web's largest sustained advantage.
Consistency / Productivity
I forget where I got the idea but I believe that when comparing the effect of somethig on creative work (e.g. quality of paper for calligraphy) it's more representative to compare the median work instead of the best or worst. I think of the median app as a set of screens, most of which are list + detail. You don't see it much in apps that win design awards since there's frequently a better design for a problem but it fits a lot of information architectures and is fairly easy to implement. Toss in a top level tab navigation and you have the common language of mobile app design.
If you're making this type of UI, native toolkits are really good. The widgets are pre-built, the examples show you exactly what to do, the IDEs are set up to support you. Further, even if you're going to build out custom parts of the UI, getting an early dogfood list + detail prototype lets you start getting feedback early in the design cycle. I sincerely believe (argument from authority!) that more design cycles are the primary driver of app quality.
That's a powerful set of advantages. When I started going through why the initial batch of iOS apps were so much better than the web apps that had been on iOS for the previous year back in 2009, I settled on the widget advantage. The problem with building web apps is that there's an expectation for building a fully custom UI for every project. Every serious attempt I've seen at building out the widget framework, usually based on years of native desktop experience, has foundered on the shoals of custom UI on its way to market dominance. The ones that have had more success (e.g. Bootstrap) are less toolkits and more predefined styles that you can apply to the widgets you create and thus fit into this pattern. I think the main reason for the failure to develop a generalized widget set is that CSS doesn't abstract and that screws everything up but the other reason was that components didn't compose.
Happily, Jordan Walke figured out the trick to building composable components: uniform component UI with a direct projection of UI from defined state. There's a reason the React model is winning and that's because it solves a significant fraction of the problem with UI, mostly around the diffusion of state in widgets and the difficulty testing it. The web developer tools also seem to be best in class of all the ones I've tried. After the component model, the next problem was application architecture. It looks like the Elm architecture (TEA, redux is the hacky js version) is more or less winning there. The last pieces are state synchronization across the network (graphql, json-api) and a widget set. I've seen attempts at the widget set but nothing's won so far. I know how to do the widget library but lack confidence in my ability to complete a project that large.
So in the meantime, the native devs have figured out that developing for two platforms is bad and that the Android API is meh.
The first major effort on this front is React Native. I last poked at it years ago and I know it evolves rapidly so I'll avoid writing too much about it other than to note I also found RN to be fine. I've been meaning to look into it more because there's the awkwardly named React Native for Web that's used in high traffic real world apps but it hasn't worked its way to the top of my research stack.
The Dart guys took TEA and put a lot of work into re-creating native looking/feeling widgets to come up with Flutter. Good on them for disrupting themselves and salute to the Dart team for justifying their existence beyond being the pet project for AdWords. I've gone through the basic tutorials (Dart is the world's most boringly designed language and thus easy to pick up) and found it fine.
I don't think Flutter does anything particularly special from a technical level but there are a lot of developer hours in the widget cloning so I can see it possibly getting traction if nothing special comes out of the web in the next two years or so. I could also see a lower level rendering framework done the same way using the game APIs (a la juce or sciter) but the effort in emulating native widgets in a non-terrible way is a huge barrier to entry. Maybe have a non-js bridge to react native or something.
I don't really have a conclusion here, just that the consistency arguments seem to be undercut but the shifts towards cross-device APIs. I don't think web apps have a particular advantage here but I think the disadvantage is reduced by the shift of the average app to being less remarkable.
For the productivity, I think web projects have improved in the last decade but I also think there's a big gain to be had for basic apps and starting design cycles if someone can come up with the once and future set of widgets. For full-custom comparisons I've found that the time frames quoted by native guys seems high to me compared to the times I'd expect a web app to take but my number of samples for that is really low.