My impression is also, that it has changed a lot on Android.
Personally, I also think that, in the beginning, many parts of iOS-development felt more modern than OSX, and that this was the platform where things were maturing faster.
I would say, that mobile development is like development on most other platforms these days. You have an increasingly larger choice of languages, and the Mobile CPUs are certainly powerful enough that you can build very complex apps, where elegant code is an advantage.
The challenge is to keep things simple from a user perspective.
It really is (still) a wonderful domain to develop in, and I doubt there is more debugging or trial-and-error than any other platform!
I worked for a company that embedded Linux on a custom device about 15 years ago. That was a horrible debugging, trial-and-error experience. The language was C. Chosen as a compromise because of the hardware specs, but not an obvious choice for the applications we built. Certainly not today. Most of the development team was frustrated with the development process, and I actually left the company before the product was put in production.
So I think, I understand your line of thought, but I don't recognize it in today's mobile development.
On the other hand, due to limited resources libraries tend to be as they should, light-weight and modular. None of these mammoth frameworks enterprise devs have to cope with. No AbstractSingletonProxyFactoryBean.
Though, I'm more motivated by what I could theoretically do [faster|more comprehensively|repeatably] with code than I am with it in of in itself, and occasionally I like acting on such. Having x number of beamformers targeting different brain regions that I can customize quickly without interfering with timing of processing a signal or buying/making more analog hardware nor completely wasting cpus/memory to my own tolerance is cool, caring whether I use structs vs this or that some class inheritance scheme vs this or that implementation of shared pointers vs tabs or spaces… I couldn't care less about in of in itself and find myself annoyed when I have to deal with such talk.
Personally, my typical web app is not CRUD, it's merely an R. And I don't write those daily. Much more often I write network or system daemons.
That's why REST and JSON are great. Very simple and perfect for many web use cases.
Indeed. To avoid the CRUD groundhog day, I'd stay away from both web and mobile.
Games, Desktop apps, Industrial, embedded, ...
Personally I do desktop applications and love it.
I simply don't believe that a domain (understood broadly, ie. desktop/mobile/web) in and of itself dictates whether projects are original and interesting.
Not until you work on something really specialized, like AI etc.
They are usually only interesting if they are desktop apps because they have to, like image editors, games, CAD.
My test for interesting work is the fraction of lines of code that relates to processing data and not just input/presentation/persistence/validation.
Other people have different definitions for "exciting". Don't knock someone else's idea of it just because you don't agree with it.
What I generally do is write web apps, and much of my enjoyment comes from figuring out how to creatively use other people's libraries and to write very DRY code.
The libraries I use abstract browser fragmentation away from my presentation layer, so I don't have to do endless run-debug-fix loops on the front end.
At this point, the code I write for each new project is 90%+ unique to the project and very thin, so I get to do the fun part of releasing and iterating it.