Is there a drop in native iOS and Android hiring at startups?
Fewer startups seem to be building native applications from day one. Why is this, and what does it mean for where native mobile engineering is headed?
Are startups changing their approach to hiring native mobile engineers? During the summer, I talked with a handful of startup founders, who all mentioned they see a move away from native engineering, taking place. Obviously, I wanted to gather more viewpoints, so shared this tweet:
In the following two months, I talked with around 15 startup founders and experienced native mobile developers about how they see the industry changing. In this issue, I share these high-level observers’ takes on this topic.
Today, we cover:
The challenge of hiring iOS and Android engineers
The cross-platform evolution
Continuing strong demand for experienced native engineers
The most common challenge when hiring native engineers
What mobile development agencies are seeing
Where is native mobile engineering headed?
This topic of how native mobile engineering may be changing, is one close to my heart. For one, I was building native mobile apps on Windows Phone from 2011, and later moved on to do native iOS at Skyscanner and Android at Uber. I also published the book, Building Mobile Apps at Scale in early 2021, which covers many of the native mobile challenges for large mobile apps.
Native mobile development is a relatively new field, compared to other parts of software engineering. Apple and Google both launched app stores in 2008, marking the start of native iOS and Android development, which grew more popular over the next decade. Countless startups have since developed from being a mobile app, to become full-fledged businesses. Fourteen years later, it’s interesting to check out how today’s startups approach it.
1. The challenge of hiring iOS and Android engineers
In some regions, there’s an imbalance of iOS and Android engineers. Startup founders in India shared that they are moving towards mobile apps with Flutter or React Native, simply because they cannot hire native iOS engineers. In India, Android is the dominant smartphone platform, and most native engineers specialize in Android. This means companies which want to ship on both iOS and Android are competing to hire from a smaller pool of iOS engineers.
Anup Cowkur, director of engineering at Groww, shares that a reason why Android is more popular in India, is the cost of a Mac. Many students in India cannot afford a Mac machine, so they use Windows or Linux machines instead, making Android the platform they pick up as a native mobile platform.
I also heard the same from a mobile agency owner in the Balkan region of Europe – Albania, Bulgaria, Romania, Serbia. They observed there’s more Android developers in the region, too. However, with the rise of iOS in these markets, the imbalance is not as skewed as in the past, they said.
Brazil has a similar issue. A software engineer shared how having a Mac and iPhone or iPad is out of reach for most of the population, thanks to the price of the devices. Many iOS engineers in Brazil are trained via the Apple Developer Academy proving this hardware: but this program is limited to small numbers.
Meanwhile, at Uber in Amsterdam and in the US, I observed the opposite problem: we somehow had more trouble hiring experienced Android engineers, while finding iOS folks was much easier. We ended up doing a hiring sprint in Brazil in 2017, hiring several Android engineers from the country, and relocating them to Amsterdam.
I’m a living example of Uber’s struggle to hire native Android engineers. Before working at Uber, I did native iOS development. For some reason, I ended up on a backend interview loop and was offered a backend engineer role. I took it; a good opportunity to return to backend, I thought. Two weeks before my starting date, my new manager sent me an email asking if I could do Android development. I did Windows Phone and iOS, and so I said I’d not, but that I’d learn quickly. This is why I arrived at Uber on day one with the ‘Big Nerd Ranch Android Programming Guide’ in my hand.
Turns out, the team really struggled to hire Android engineers and desperate times called for desperate measures. I needed help to get up to speed with some Android concepts not in the book – which the team around me were great sports about – and to this day some of my code is probably powering Uber’s PayPal integration on Android.
Until recently, more Android engineers were needed to build an app, than it took iOS engineers to do the same job. Android’s native ecosystem has more quirks than iOS; the biggest of which is device fragmentation. For one application, an Android team typically needs to do significantly more work to support the app working on a wide range of Android devices.
It’s not just the edge cases which can be complex when developing Android applications; testing on real devices also demands more varied testing. But over the years, Android fragmentation has come more under control – so long as you don’t target older OS versions.
The boom of remote working and the rise of elite jobs site, Toptal, has changed where experienced mobile engineers in lower cost regions work. Toptal is a freelancing platform founded in 2010, claiming to screen for the “top 3% of world-class talent.” It was one of the first platforms to build a well-balanced marketplace for native mobile engineers and attracted lots of US-based, VC-funded startups, as well as a large number of experienced native mobile engineers. In 2015, I registered on the platform – after passing several interviews – just in case I ever wanted to freelance, but never got work via the platform.
Mobile engineers working in lower cost regions like eastern Europe and Latin America told me that since 2020, Toptal and especially remote work have together changed the native mobile engineering market.
Experienced mobile engineers continue to be in high demand, and now they can work with higher paying clients in the US, or western Europe.
What this means is startups founded in lower cost regions are priced out of hiring local, experienced engineers. The only way they can attract these engineers is by raising more money in order to compete on compensation with the market’s “big beasts,” or use personal connections; convincing engineers to take a pay cut, in exchange for a great mission and a generous equity package.
But experienced iOS and Android engineers rarely entertain small startups. Several founders told me they don’t get responses from iOS and Android engineers on LinkedIn, but they do from those who list Flutter or React Native as being in their skill sets.
Their opinion on the cause of the lack of interest from experienced iOS and Android engineers is that most simply aren’t interested in working at small, unproven startups. There are a few potential reasons why not:
Money. Engineers command more earning power than they assume startups can afford. Many are contractors, used to charging high daily rates – especially if they have well-known projects on their CVs.
Career growth. Mobile engineers are in high demand and tend to climb the career ladder quickly. It’s not uncommon to see a native engineer with no formal CS education become a senior mobile engineer within 3-4 years. Once these engineers hit the senior level, they look for opportunities to grow further, which usually means they target Big Tech and large companies.
Specialists, not ‘jack of all trades.’ Startups typically look for mobile engineers with impressive breadth of knowledge, but not necessarily depth. More experienced mobile engineers often prefer to specialize in one – or a few – of the aspects of app-writing, so gravitate towards larger teams with the space to specialize.
Founders going native need to hire not just a single mobile engineer, but at least one each for Android and iOS.
And it’s not just obscure startups which struggle to hire native engineers. One reason Coinbase moved to React Native in 2021 was because since 2017 it had had issues hiring native engineers. As the company wrote in a 2021 blog post:
“By 2017, we had a small team of Android and iOS engineers working on these apps, but despite our best efforts, we were having a hard time scaling. Over the course of that year, we were only able to hire half as many mobile engineers as web engineers. Furthermore, while web engineers saw notable productivity gains, the average mobile engineer’s velocity remained stagnant.”
2. The cross-platform evolution
Today, Flutter and React Native are finally “good enough” for apps which don’t have high performance demands. Cross-platform approaches felt very wobbly in the early days, but they matured over the years and now pass as “good enough” for performance on high-end phones. The user experience usually leaves something to be desired – it often doesn’t feel “iOS native” or “Android native.” iOS engineer Kurt Guenther, who won the Apple Design award for the Butterfly iQ+ app, puts it like this:
“The performance of apps that do a bunch of custom drawing, have a heavy C++ core architecture, or need to marshal a lot of objects to the React Native JavaScript thread still suffers performance-wise, compared to native apps. All this comes from my personal experience.”
On the other hand, UX can be tweaked and some apps don’t require a high degree of polish.
Could have 2019 marked an inflection point for the popularity of cross-platform? According to the observations of senior Android engineer Volodymyr Buberenko, it was. Volodymyr worked at Ukraine-based mobile agency, UPTech Team until mid-2019. Most of its customers were US-based, the vast majority headquartered in California. He observed that 2019 was when more US-based customers started to choose cross-platform apps:
“Until early 2019, the discussions with clients on native vs non-native ended with roughly the same clients choosing native, as those choosing cross-platform. However, from the middle of 2019, something changed. From this point in time, more clients approached us with the decision that they’ll do cross-platform, and the only discussion they wanted to have with us was whether they should choose Flutter or React Native. Clients, from this point, seemed to have considered cross-platform approaches mature enough for their needs, based on the information they had, and the input they got from talking with other mobile agencies.”
React Native allows teams to leverage and cross-train React engineers. React is slowly but surely becoming the most popular web framework. According to The State of Frontend 2022 survey – the results of which I will share in a future article – 76% of web developers used React during the past year, many more than Next.js on 43% and Vue on 28%.
React Native promises engineers an easier transition and a codebase which is less disconnected from the web codebase. Though it naturally cannot fully deliver on these promises, founders whom I consulted are satisfied with having a similar enough technology on mobile, and their engineers being able to work between the mobile and web codebases, following some onboarding or training.
Flutter has a lower barrier to entry than native Android. Predrag Samardžić is a senior iOS engineer and team lead at Wireless Media, a digital agency in Serbia. He shared that he has recently encountered students with Android experience, who are starting to prefer Flutter:
“I recently interviewed a potential intern for our Android team. This person was in the last year of their Bachelor studies. They had some Android development experience, but were more proficient in Flutter. I asked this person, which technology do they like more? Native Android or Flutter? Their answer was Flutter, saying it is simpler, easier, and can get results more quickly.
Learning curve is something that can put non-native frameworks on top of native in some contexts. Flutter is simple to pick up for newcomers, and React Native is simple to pick up for web developers.”
Not going native circumvents a potential logistical nightmare as teams grow. Tito Sarrionandia is head of frontend at Babylon Health, a publicly traded health tech company headquartered in the UK. He shared that the company moved over to React Native, mainly to avoid having to hire both iOS and Android engineers for each product team:
Lewis Liu – formerly at Brex and Circle CI – chimed in, echoing a similar sentiment:
Product manager Andrea Sipos, whom I worked with at Skyscanner, added the product perspective:
As Tito summarized, moving to React Native has simplified coordination between product and engineering, by reducing a moving part:
As an important note, Babylon Health still has a small number of iOS and Android experts with a Kotlin/Swift background, who sit in the core platform team alongside TypeScript folks. This team is the only non-fully Typescript team in the frontend group. The team is currently 6 engineers: 4 with React or React Native background, 1 with iOS, and 1 with Android background.
It’s usually easier for startups to hire a team of cross-platform engineers. If a startup wants to put a small mobile team in place to build a first version of its app, it would need:
1-2 cross-platform engineers.
Or 2-4 native engineers: 1-2 native iOS and 1-2 native Android engineers.
Clearly, when getting started, hiring 1-2 cross-platform engineers is easier.
Anup Cowkur, director of engineering at Groww, shared that hiring for larger teams can make it more challenging to find cross-platform engineers:
“While finding 2 cross-platform engineers when you're small is easier than finding 4 native devs, finding 20 experienced cross platform devs when you're scaling is harder, since the overall pool of experienced cross platform devs is much smaller than experienced native ones.”
However, there’s evidence to suggest that even large, high-profile companies can struggle to hire for big native mobile teams. When Coinbase transitioned from a native app to a React Native one, one reason was the struggle to hire enough native engineers. As the company wrote in a blog post (emphasis mine) last year:
“By 2017, we had a small team of Android and iOS engineers working on these apps, but despite our best efforts, we were having a hard time scaling. Over the course of that year, we were only able to hire half as many mobile engineers as web engineers. Furthermore, while web engineers saw notable productivity gains, the average mobile engineer’s velocity remained stagnant. As our scaling efforts continued to yield disappointing results into 2018, it became increasingly clear that we needed to increase our rate of growth and speed of iteration on mobile platforms.”
The company also hypothesized that by moving from native development to cross-platform, it could reduce the size of a typical feature team of 8 engineers, comprising 2 backend, 2 frontend, 2 iOS, 2 Android, to a team of 5 with 2 backend and 3 frontend/React Native ones.
What I find surprising is that Coinbase had trouble recruiting sufficient native mobile engineers in 2017, despite being both high-profile and well-funded.
Some native engineers are switching to cross-platform. The best cross-platform engineers are those who deeply understand native development, and can get their hands dirty when required.
Volodymyr Buberenko is an example of a native engineer who switched to cross-platform. After five years as an Android engineer, Volodymyr moved over to specialize in Flutter, and now leads the mobile team on the Prematch app, which covers German amateur soccer.
I asked Volodymyr why he switched over to Flutter and he shared that he’s been interested in the technology since 2017, when he saw a demo of the alpha version at a conference.
3. Continuing strong demand for experienced native engineers
Experienced native engineers in metropolitan areas are still in high demand. I talked with two native engineers on the US West Coast. Both have ~10 years of experience working on native apps and impressive backgrounds and portfolios. Both have previously led mobile teams.
One shared the number of reach outs they receive via LinkedIn InMails, about native positions. They list their title as “Tech Lead” at a current unicorn – a company valued at $1B or more – and has extensive iOS experience. This is the number of reach-outs they’ve gotten per month, this year.
According to them, the distribution of these reach-outs is evenly split between:
Small places: Developer agencies with poor reputations, or small US-based regional contractor firms.
Non-tech companies: grocery chains, banks, telcos and other companies where tech is a cost center.
Big Tech: like Meta, Microsoft, Uber, Pinterest.
Amazon vs TikTok reach-outs was an interesting metric this engineer shared. In their words:
“Up to July, I used to hear from Amazon recruiters every 2-3 days. In July, this went down. In August, I heard from TikTok recruiters every 2-3 days.”
Interestingly, the number of reach-outs dropped steeply in September, even for this engineer.
And it’s not just the Bay Area where developers have such numbers of reach outs. I talked with a native iOS engineer based in eastern Europe who’s seen a similar trend in reach outs to them.
Experienced native engineers have more luck by joining high-growth companies investing heavily in mobile. Two native mobile engineers each shared that the best experience they’ve had of landing gigs that pay well and are enjoyable, was by joining companies which were web-heavy, but also investing in building native apps from scratch.
These are typically companies with a stable business model, for whom a first-class native app is expected to repay several times over the capital investment, via more sales, less churn and a superior customer experience, among other benefits.
A good example of a formerly web-heavy company investing in a native app is the note-taking platform, Notion. This company always had a mobile app which utilized web views, but its sluggish speed was a big complaint for customers. By June 2022, the company had removed web views and introduced native components. The app is now noticeably faster to navigate.
4. The most common challenge when hiring native engineers
Startups wanting to hire native engineers are still struggling to. Talking with five startup founders and engineering managers who want to hire native engineers, they all complained about how difficult it is. Here’s how one founder summarized the challenges: