I was a mobile developer and moved away from it towards web development because of how uncertain the future looks for the tooling.
Investing hundreds of hours into the web framework of the week at least informs me on javascript/html/css in general. However, with mobile, your experience with Swift and AutoLayout might be totally irrelevant in the job market if most businesses want a Cordova or React Native developer, and vice versa, or the mood of the industry shifts.
Further, from a business POV, what do you do? 3 separate codebases (iOS, Android, Web) for native, and deal with a nightmare of hiring, maintenance, and disparate features? 2 separate codebases via hybrid native, and pray the platform continues to be supported while dealing with shaky native features? One codebase + extra for a Cordova application, having suboptimal performance + UX alongside another hiring nightmare? Or pray Apple decides to be benevolent, and hitch your app to iOS picking up support for PWAs?
People who complain about churn in front end have never done mobile.
It's not like the time spent learning it is wasted. The concepts are very transferable. I started a job last year, which involved working on a React Native app. I had zero experience with either React Native or React, but I could be productive pretty much right away, as I had lots of JavaScript and TypeScript experience so no problem with the language, and some experience with Angular, so could handle the concepts. My native iOS and Android experience meant I could write plugins too. Recently I had the slightly odd experience of helping to lead a class on React within a couple of days of using it for the first time. Aside from some fumbling with the styling, I could apply my React Native experience with no mode switching required.
Learning a new framework is rarely time wasted. Even my totally obsolete experience with Adobe ActionScript was really useful a decade later, as it's basically the same as TypeScript, while Flex shares a lot of concepts with React.
You make great points but mobile still favors native greatly- only React Native has made any significant challenge to it. Yes there are a lot of options but I suspect the tooling questions in mobile is about stuff like Objective-C/Java vs Swift/Kotlin or Autolayout vs. third party libraries, not native vs. cross-platform.
"People who complain about churn in front end have never done mobile."
This is as incorrect as it can get. There are these frameworks like RN, Cordova etc. but in the end these are and probably will be niche that don't really matter. Pretty much everything in mobile is done native and often with standard MVC etc.
The future is as certain as in any other platform.
Focus on OS vendor tooling and a specific platform instead of whatever pops up as alternative 3rd party tooling, with various degrees of integration with the platform APIs.
One of the best options I did after my delusion how Borland went under with their uncertainties where to focus next, was to always use OS vendor SDK for production code.
So far this option has worked out the last 20 years, and I bet it will continue to work out until I retire.
I’ve done native iOS dev as a freelancer since 2010 and I’ve never had even a hint of trouble getting work.
Third-party frameworks for cross-platform dev come and go, but RN is the only one that has ever felt like it might offer a challenge to native dev. A year ago I would have said maybe everyone was going to shift to RN, but then I actually tried it and I realized that it’s incredibly immature. I really doubt it’ll ever be more than a large niche, and most apps will continue to be built natively.
Regardless, I think you’re worried about changes that might possibly occur more than you are about changes that have already occurred. In iOS dev, the only major shift I’ve seen in the last eight years is Objectice-C to Swift, and even that wasn’t that painful because you can mix and match the code.
We recently began work on a mobile app version of our web-based kanban board application. We ended up spending a week on react native, then switching to Cordova, which I don't agree with 100% but you're dead on about the ups and downs. At the end of the day, a 2nd code base, even if its similar to our web react code base (and even if you can share all your state management code like we could), is still a 2nd code base.
I'm going the other direction - I've been in embedded/systems since forever, but focused mainly on mobile since forever .. and now I'm more and more convinced that the insanity of hell that is mobile development, is no different than the putrid festering cess-pool that is web, and the only way out is to write yet another host app, with its own ecosystem-supporting embedded script capabilities, turn the whole thing inside out and write all of my own damn GUI controls, subscribe to nobody's slippery gravy treadmill, and just say no: to all the things.
Like the DOS days, if you don't have your own GUI lib, gtfo... I know its an offensive position, but frankly I find the big web con, and all the fancy dancing of mobile, to be just as offensive.
Investing hundreds of hours into the web framework of the week at least informs me on javascript/html/css in general. However, with mobile, your experience with Swift and AutoLayout might be totally irrelevant in the job market if most businesses want a Cordova or React Native developer, and vice versa, or the mood of the industry shifts.
Further, from a business POV, what do you do? 3 separate codebases (iOS, Android, Web) for native, and deal with a nightmare of hiring, maintenance, and disparate features? 2 separate codebases via hybrid native, and pray the platform continues to be supported while dealing with shaky native features? One codebase + extra for a Cordova application, having suboptimal performance + UX alongside another hiring nightmare? Or pray Apple decides to be benevolent, and hitch your app to iOS picking up support for PWAs?
People who complain about churn in front end have never done mobile.