r/cscareerquestionsCAD • u/HypeKingFred • Aug 03 '26
ON Is iOS Development Losing Demand in Canada, or Am I Missing Something?
I'm genuinely looking for some honest perspectives from people in the Canadian tech industry.
I've been searching for an iOS Developer role for the past several months, but I haven't received a single interview call. I've applied through LinkedIn, Indeed, company career pages, referrals, and several other job portals. Despite countless applications, nothing has worked.
What makes this even harder is that I've spent 10 years specializing in iOS development. Walking away from a decade of experience isn't an easy decision.
Lately, I've been hearing the same thing from many people, mobile app development is losing demand in Canada, and that opportunities for iOS developers are becoming very limited.
Some have suggested that I should pivot into areas like Data Engineering, Cloud Computing, Full-Stack Development, or even Business Analysis.
I'm at a crossroads and honestly don't know what the right move is. Is there still a healthy demand for experienced iOS developers?
•
u/Racepace Aug 03 '26
I have similar experience with iOS, not looking for a job but still keeping an eye on things and I’m also seeing this as well. It’s ok to let go of iOS imo, software development is always changing. I’m seeing a lot of AI engineer positions so that’s another option
•
u/HypeKingFred Aug 03 '26
how many YOE do you have? Are you still working with iOS Swift, or have you transitioned into AI or another tech stack?
•
u/Racepace Aug 03 '26
11 YOE, about 10 of that in Swift. I've been learning as much as I can in AI recently in case I get laid off
•
u/Rude-Panic-8001 Aug 05 '26
I am react native dev . There is one dude from my company is a swift guys with 10 years experience are forced to learn react native cause the clients want new stack to save their money for both ios and android app 🤣
•
u/Tripdubcs Aug 06 '26
I find this reasoning makes less sense nowadays.
With AI the code and maintaining two codebases is no longer as big an issue as before. So cross-platform stuff like RN, flutter and KMP/CMP doesn’t make that much sense when you can augment devs with AI.
And it will keep getting easier as AI gets better. Anecdotally, I’m seeing way less cross-platform positions and more demand for native.
At my F500 KMP is loathed and we’re trying to move away from it. It’s only some people at the top who are KMP evangelists who forced it on everyone but it’s shown little value since we adopted it.
•
u/transmillion Aug 03 '26
Have you looked into Kotlin? As a former native iOS dev I found the syntax similar when I tinkered with it on the side, but it can be used for backend and is interoperable with the Java ecosystem. I haven’t gone this route though personally. Ended up taking a Flutter role previously and am currently working with a React Native stack, hybrid has gotten quite popular because of performance improvements and it’s far easier to find and hire roles for it from my perspective.
•
u/makonde Aug 04 '26
Anecdotal but we used to have an Android and iOS team 3-4 devs each, shared designer, both slowly got eliminated and now we have neither, Android app completely rotting away, iOS makes a bit of money so once in a while someone jumps in to fix or add features, focus is more on web.
•
u/AiexReddit Aug 03 '26 edited Aug 03 '26
Oh, good timing! I have honest perspectives on this!
I lead a team of ~10 devs at a tech company with a pretty wide area of ownership. We've got iOS and Android apps, desktop, web, some backend stuff.
The team is an eclectic mix of skills and personalities. Two seniors, two juniors, the rest mostly mid level. We all collectively own the implementation of a specific business domain across those surfaces, but obviously some are much more skilled in areas than others.
There's a lot of web devs. A couple C++ focused. We've got one "Android dev" and one "iOS dev" who work on those clients pretty much exclusively. And they really know their stuff, it's very impressive.
There's one more type of dev on the team though, I'd say maybe 2-3 of them fit into this category. They have their preferred stacks, and that's where they usually stay when working on new features.
The big difference though is when a bug report comes in. Or when someone is on PTO. Or when someone needs a PR review and their usual reviewers are busy. Or when something goes really wrong and an incident is spun up, social media is lighting up with angry users, and we need to figure out how to mitigate it now.
The devs that are "Android devs" or "web devs" will see this happening, see reports coming in from the iOS client and their first instinct is to say "hey iOS dev, this looks like an iOS thing, can you handle it"
Those other 2-3 however... they will stay say "FYI iOS dev you might want to check this out"... but as they are saying that, they are already neck deep in logs and diagnostic reports and poking through Swift code they've never seen before trying to figure out what's going on.
When something goes wrong, their first thought is "something my team is responsible for isn't working" and they try to fix it. Platform and programming language inexperience might turn out to be an obstacle they can't overcome, but they're not going to assume that's the case until they actually hit that obstacle and are unable to find a way around it without handing the entire investigation over to the iOS dev.
If the bug was caused by an undocumented breaking change to an Apple system API between version 28.2 and 28.3, yeah, you're probably gonna need the iOS guy that lives and breathes that stuff. And if that was the majority of bugs, you'd need to be hiring a lot more dedicated iOS devs.
Obviously your mileage may vary here from company to company, but in my experience, those are the minority of bugs. The majority of bugs are driven by errors that we ourselves write based on mistaken assumptions, poor abstractions, untamed complexity of state, and the intersection points of multiple teams code converging in the same area to disastrous results (race conditions ahoy).
The funny thing is, for this more common type of bug, even in the iOS code and Swift app the "not iOS devs" are often able to trace and identify the problem before the full time iOS-only devs are. Because Swift language and Apple ecosystem familiarity are only one piece of that puzzle, and not even necessarily the most important one. The devs who don't limit themselves to a platform tend to be much better at running the log parsers or navigating Datadog or Sentry dashboards looking for clues and traces of paths to find root cause.
Well that was a lot longer than I meant to go. Anyway, all this to say, even if our iOS app starting seeing an increase in the number of issues and errors, aligned hopefully with growth of the userbase of the app itself, and I had to start looking at hiring another dev to supplement the team;to be totally honest with you as long as I already had at least one iOS dev with deep knowledge of the ecosystem on the team (or even if not, ready access to ask others in the company)...
Given the choice, no question; I would always go with the "proficient and capable" dev who treats every backlog bug ticket the team has, and even planned project on their roadmap, as a potential problem they could help solve.
So my advice to you is to consider what kind of barriers and limitations you might be carrying around that exist only because you have placed them there yourself. It's a bit concerning to see someone with 10 years of software development experience suggest that developing in a different language for a period of time is "walking away". Are they really so different?
I don't write Swift much personally, I actually write a lot of Rust, but every time I read Swift code I'm amazed at how little I have to shift my mental model. They have more in common then they do different. I feel like if I had to, I could probably go heads down for a couple of weeks with the docs and SwiftUI standards, and probably absolutely fail spectacularly on my first few PRs.... but with some friendly and "hey did you know you can just do X instead" PR reviews, coupled with an assumption that our tests in CI will stop me if I do anything really stupid, and I'm pretty sure I could be up and merging some small scoped but also non-trivial iOS work within a couple of weeks.
I've also been doing this for about 10 years, and I'm not suggesting your experience or time frame would be the same. I was fortunate to make this shift in mindset about 5 years ago, so that confidence in the ability to tackle unknown problems comes with a lot practice, and a lot of lessons learned through failure. But I can say without any doubt that no other single shift in thought process comes anywhere close to this one in terms of what's helped boost the potential of my career options and scale.
Even regardless of hiring demand in the country, are you not more broadly concerned with hedging your entire software engineering career on a single company's ecosystem?
Sure the biggest company in the world, can't argue that, but when you consider that many devs of all skill levels out there are marketing themselves as "software developer", you suddenly realize that despite being the biggest company in the world, that's an incredibly tiny slice of the pie when competing for roles with folks whose tech stack apples to "every company in the world" and you can see why a tightening market and weakening of overall developer demand would naturally hit those folks who limit themselves to only being willing to work in one small slice.
Our iOS app is important, but when push comes to shove our team owns a product domain, so the less you can contribute to the really big picture cross-platform impactful initiatives we want to land this year, the less likely I'm going to be to hire you.
TL;DR if you want to learn Data Engineering to improve your marketability.... great! Do it. But don't pivot into it. Supplement the strong existing identity you already have.
You are now the data engineer that can can do something that no other data engineer on your team, or maybe even your company can do: wire that data pipeline into a world class mobile app that doesn't fall apart when you tap on the wrong part of the screen
Heck, sprinkle some light "business analysis" on top of that you learned from an out-of-date Udemy course you plowed through on a weekend, and before you know it you've got a meeting request from your manager's manager's director one morning, wanting to know how much time and dev resources you'd need to turn it into a real product and get it in customer's hands as soon as possible.
Obviously getting way ahead of things here, but I've found a lot of devs I've worked with an mentored over the years already had all the skills and technical experience to make this transition, and all they needed was the nudge.
Ironically one of the most recent mobile devs I gave a version of this rant to, dove deep into one of the most infamous backend services we have that nobody else wanted to own for the next six months, and after making a few really fantastic improvements to its stability... promptly peaced out to go work at Apple lol. Not jealous at all of course (but actually seriously super happy for him)