The second issue is around the abstractions used to make apps - I'll speak for Android here but I believe iOS is quite similar in outline. In Android, abstractions are incredibly leaky and require you to understand much more about the internal workings than HTML does. I can build a site in HTML without worrying about how the browser implements the functionality - for example, I can make an un-numbered list, or create a list box and populate it with items, fairly easily, even doing so dynamically from JavaScript.
In contrast, on Android, you need to start understanding ListView versus RecyclerView (apparently the latter is better to use?). Then to understand Adapters. Then to figure out how to get content into that ContentAdapter. At some point invariably you'll discover issues with whether your code is running on the UI thread (and blocking the UI from updating while it runs, which is obviously bad), or running off the UI thread (and thus unable to update the UI elements)... You can't (at least in my experience) just get down to focusing on your business logic, without reinventing the wheel a fair bit here. You'll also need to discover the "de-facto go-to library" sometimes, where the built in API isn't good. Bluetooth springs to mind, where I believe most people would recommend using a third party library rather than the included one. That's a discoverability challenge.
I don't think we should take this level of control away from anyone wanting it, but I think it's important we recognise mobile development seems to favour the approach of "bring your own batteries, soldering iron, and flux, as we don't provide any", whereas web has some available batteries and equipment you are free to use, or alternatively to build your own. It would be nice to see some default "batteries" pre-installed, so people can get started without having to learn the details of all the leaky abstractions needed to understand how to get an app to show up and respond to input etc.