Mobile Engineers - You’re All Full Stack Now
Specialization used to be the thing—mobile, frontend, backend, etc. Now with AI we all can (and should) work on a higher full-stack level, which I believe mobile devs are best positioned for.
Back in the day I started my dev career by making MVP apps for entrepreneurs and startups in Silicon Valley. They were mobile apps, Android and iOS. I started with Android but as I would build the apps for my clients they would keep asking to make the same thing on iOS. So, I picked up a few books on iOS dev and built them the iOS apps they wanted.
I hit a wall pretty quickly. The apps I built could only do so much without a backend. My clients kept asking for more features that required a backend for my mobile apps, so I picked up the books again, this time on Ruby on Rails, and started to build backends and APIs for my mobile apps. On occasion I’d even have to build a dashboard or two in javascript (and dart) or a landing page for those projects so I’d even dabble in frontend a little bit (just enough to know I hate it).
Eventually, I specialized in iOS because building all of those things and being the jack of all trades spread me too thin and burned me out. I liked iOS development the most. This, in a nutshell, is the story of how I became an iOS specialist. But it is also a story of how I became a versatile generalist who doesn’t care what platform or language to work with (unless it’s javascript, ick) and builds things full-stack or with a full-stack mindset.
Years went by and two things that I observed struck me:
First, it seems like almost no one in the mobile community builds full-stack and/or touches or even understands backend development. Second, as far as I can tell, the mobile devs, on average, are better devs because they pay more attention to details and grow up within a constrained environment.
Let me expand on both of these points.
Mobile Devs Are Rarely Fullstack
It is common in the JS/TS world to be fullstack. You build the backend, you build the frontend for it. Often, if it’s JS/TS, even the same language is used in both. It is pretty normal and sometimes expected for devs to build entire features top to bottom maybe with an exception of design.
Now, you could argue that it is a good thing or bad thing whichever way and you probably would be right. Devs not specializing and having enough knowledge about each side is a bad thing. But at the same time, the same devs holistically solving a problem for the user and not making disjointed implementations by pointing fingers to the other side is a good thing as well.
But somehow mobile devs have avoided this over the years. They just sit in their own silo and make not just the mobile side without the backend, but get this, ONLY one platform at a time!? 😱
It’s probably, mostly or partially, due to the fact that the language, like in JS/TS case, is not shared between mobile and backend. But that said, I’ve seen plenty of Rails devs who are also perfectly comfortable making JS frontend stuff all in one go. I suspect that the difference is that mobile development has enough complexity for one engineer to dive deeply for their entire career. But, nowadays, the same thing can be said about both frontend and backend development I suppose.
And I think the lack of good and “fun” backend frameworks like Ruby on Rails written in Objective-C/Swift or Java/Kotlin is not helping either. Although, these days Kotlin,Ktor and Spring Boot are helping in that department.
Mobile Devs Are Best Suited To Be Fullstack
I would argue that mobile devs are the best suited to be fullstack engineers. Consistently I find that mobile devs have a higher attention to detail, polish, architecture, and design patterns than their frontend and backend counterparts. In general, they care more and want to do more.
I suspect that this is due to the constrained environment that we “grew up in.” Mobile development is a very challenging and constraining environment to be coding in. Yes, it’s not some low level middleware device optimization code, but since day one mobile devs have to think about memory constraints, network bandwidth, CPU utilization, battery, etc., where their frontend web JS dev counterparts are completely clueless about these things.
Heck, the intermittent internet connection alone forces mobile devs to pay attention and always ask—“what is the loading state for this feature?” and “what is the error/empty state if the internet connection is down for this feature?” and so on. These are the things that frontend devs, and a lot of backend devs, usually don’t have to worry about much (even though they should!).
Another big constraint that mobile devs have to work with is the screen real estate itself. It is much more forgiving to be working in a desktop-sized environment where there is a lot of room for design and feature arrangement and where you, perhaps, could display “all the things” at the same time in one single screen. Then you don’t have to worry about navigation and routing and relationship between your screens as much.
On mobile you simply can’t fit all that stuff on your screen at the same time so you have to be careful about how you arrange screens, how you navigate, how you present data, etc. Yea, yea, I know, you could say—“Alex, this is the designers’ problem” but in reality it’s the devs who need to take care of it and the ones who need to implement it dealing with the underlying code complexity. Non-mobile devs simply lack the appreciation (and skill/knowledge) for it.
I think all of these make mobile devs perfectly suited to not only “sweat the details” on mobile but also give the same care and attention to the backend (or maybe even frontend) implementations. Mobile devs are missing out and holding themselves back by not venturing outside of their mobile world into a wider fullstack development lane.
I believe (and have observed first hand) that mobile devs can shine building features end-to-end, starting with the mobile client side and then crafting the perfect backend API and implementation for them on the backend side. They would be keenly attuned to the challenges and demands of mobile such as backend API versioning that often (ahem, always) gets overlooked by the backend and frontend engineers (where the former don’t want to deal with the complexity and the latter don’t even understand the issue).
AI Can Help You Expand Your Scope
So, why am I bringing it up now?
AI gives us mobile devs a golden opportunity to move up and down the stack with ease. AI augmented development has been nothing short of magic for me lately. It’s enabled me to move between codebases, mobile, backend, frontend, whatever with even more ease now and utilize LLMs as a helper, aide, automation, and a crutch (haha) to fill in the gaps of my specialized knowledge, in addition to helping aid my overall high-level system understanding of the problem I’m trying to solve and of the code I’m working in.
Are you building a new mobile screen/feature? Great, you got the iOS or Android implementation done, now use the AI to help you craft specific, bespoke, highly optimized, VERSIONED, API endpoint/s for this feature. Hand it off to your backend counterparts and demand they build it this way, the right way, so that your mobile app works the best it can.
Better yet, just pull out Cursor (or your other favorite IDE/LLM) and start building out a PR with the implementation of that endpoint you want. Don’t know certain intricacies of backend development? Trust me, it is not as hard as some of the hardest stuff you had to deal with on mobile. Have LLMs help you. Open up a PR and ask your backend folks to review it, see what they say.
Or build the whole thing yourself end-to-end and integrate it all in one go. You know the constraints of mobile, you know what the API should look like, you know how to consume it, you know what needs to be done. Go for it!
Conclusion
AI opens up a golden opportunity for every mobile engineer to be “unshackled” and build things full stack.
Go for it, see how far you can get!
I firmly believe that you’ll be able to pick up all the intricacies of backend and frontend development much faster than the frontend and backend engineers can figure out how to build mobile apps properly!


I have been using Copilot to help me with a Firebase backend. The front end using KMP, so I don't have to do too much in Swift.