When I worked at Uber as an engineering manager, this was partially the case: at Uber’s scale, there was a path to grow to Staff-level just with pure mobile, but it was a crowded place and difficult to get to as a mobile-only engineer expert in one platform only.
I encouraged native engineers wanting to get to that next level to go broader - venture into areas like iOS or web or backend, to become a more well-rounded engineer and ultimately someone who can lead and influence wider groups.
If you don’t work at a company with large mobile platforms, switching stacks to eg backend typically has more path for growth.
I also wrote a book called Growing as a Mobile Engineer where my advice is basically the above: to grow beyond the senior level, either you’ll need opportunities to work at places with large enough mobile scale - typically ones with mobile platform teams -, or leave native mobile to further your career.
Also you need to choose MVC, MVP, Viper, MVVM, AAC, RxJava, and now Jetpack Compose which completely is different compared to other architectures.
But nonetheless I am excited with Jetpack Compose.
Insofar as MVC, MVP, Viper, and MVVM - the vast majority of places I know of use MVVM. I can't think of many using MVC or Viper (a form of clean), and MVP is mostly used by older apps. Some places use clean architecture, which MVVM can work in conjunction with since the concentration is on different things.
Also most new projects I know of use coroutines and flow over RxJava, and plenty of RxJava projects are migrating to this as well.
Just like Clean can work with MVVM, so can Jetpack Compose - you just have a StateFlow (or LiveData) in a ViewModel with the UI model of the screen to display. So Jetpack Compose can work with MVVM, it is just a shift in thinking - and unidirectional data flow is being picked up for non-Compose Android projects too as it can make testing easier - instead of needing to fully rely on Espresso to test UI features, you can complement those tests with lots of JUnit unit tests on the UI model feeding into lean lifecycle components. Compose isn't different than MVVM, it can work with MVVM, it just modifies how MVVM is used.
Compose is also similar to reactive UI that other (non-Android) platforms use.
Clean Architecture is a terribly written book with generic, inactionable advice, and where it makes sense, it makes sense for server-side environments in Java, but would result in over-engineering for mobile OSes which have only become more and more tightly integrated over time, therefore encouraging necessary tight couplings in code (e.g. lifecycles of applications, views, and background and concurrent tasks). I’m afraid I don’t think that mobile developers who are advocating this approach are thinking very critically, and are instead imposing a silver-bullet architecture on problems, instead of letting the right solution or architecture emerge from the right problem.
MVVM is also just an augmentation of MVC but it is still inherently MVC—and especially in iOS, the “view model” is really just a model- instead of a view-controller—so I really don’t understand why there are ever programmers who talk about MVVM as if it is different from MVC.
Haven’t yet tried Compose but it seems promising.
> And honestly speaking, the skillset you develop are of lesser value for principal / staff software engineer positions in most companies.
As a principal engineer with experience in all of those areas, I don't think it's true. I actually think that the average backend development role is far less technical than app development. Most people there are just gluing together a database and an application framework on top of a webserver to build mostly stateless services. There's far less interactivity on the frontend, less concerns about multithreading, etc - which makes it actually easier. Same as on the frontend, the world's favorite framework also changes over the years and now some people use Go and Rust instead of Java servlets.
Both roles will have options to go deeper and wider. E.g. depth-wise, on the backend side some people might write their own webservers and databases, which requires an extensive amount of domain knowledge. On the frontend, some engineers might build libraries for realtime audio or videoprocessing. All roles will benefit from knowledge about debugging (and potentially debugging remotely and at scale).
There's also plenty of things to explore in terms of breadth. Backend developers usually need to understand the how dozens of backened services interact with each other, (continuos) deployment, metrics, alarming, operations, failure modes of distributed systems, etc. A lot of that also makes sense for Frontend/Apps.
And both sides obviously need to understand how the complete system works, and how it fulfills actual customer and business needs. The skillset for a staff/principal role is a lot about the latter: Helping the business and the team, by identifying gaps in and improvements for the product, and helping other engineers to implement it. It will in most cases be a wide role, with a bit more depth in one or the other area - and I would assume that can be either frontend, backend, security, or even something completely different. But it will almost never be a role which is purely about contributing code towards a small subset of the system.
This really depends on a particular project a lot. Sometimes (often?) it's backend that does all the actual work, while frontend is just a glue for the user.
This is fairly contradictory. The reason gluing APIs together can be easy is because APIs are (usually) documented, mostly deterministic, have a limited set of operations, are designed to be glued to, and various other complexity-mitigating characteristics that don't apply to humans. "Gluing" with a human is intrinsically complex, so the way we use the word "glue" doesn't really apply.
I've been a "sysadmin" for 20 years, and just recently released my first iOS and Android app using React Native. Highly recommend it for cross-platform and code sharing, and it was quite enjoyable to do.
Is this true?
As a principal engineer, my greatest impact was selling stake holders on large projects which created a vacuum for people to level up on.
However, so many companies are highly constrained by either lack of resources or unimaginative leadership.
At those levels, it isn't about technical depth but organizational understanding and strategy to deploy resources.
At least Chrome gets more updates than the underlying Android version.
Also in 2012 there was just gcc support, and by 2015 gcc was deprecated for Clang, creating a lot of extra work for app developers due to that (technical? commercial?) decision.
The iOS devs I've talked to don't use SwiftUI because it's bundled with OS releases, so they have to use the lowest-common denominator of features for their minimum target. This is less of a problem as time goes on and the framework matures, but it has definitely slowed adoption as I see it.
