7 mobile eng industry predictions after months of research for my book, Building Mobile Apps at Scale:
1. Kotlin Multiplatform will become the de facto *native* way to share code between iOS and Android. KMM is maturing rapidly & is easy for iOS engineers to also pick it up.
2. Flutter will become the most popular way to build cross-platform apps.
The only downside is having to learn Dart. Otherwise, it's fast & tooling is solid. Google has gone all-in, building many of their own apps 100% Flutter. Cannot say the same with RN & other alternatives.
3. Full-native mobile development is not going anywhere with large apps with millions of users.
Having full control of the UX & the ability to immediately make use the latest APIs will be key for many apps and platforms.
Flutter, RN, and others will not take over all the space.
4. Tooling will keep being an issue, and a pain point for most mobile teams.
Teams will save lots of time using cross-platform vendors who bridge iOS and Android implementation details with clear abstractions. Examples: crash reporting, IAP, analytics, localization etc etc etc.
5. Mobile engineering done at scale will keep being siloed: so much more than e.g. on the backend.
Initiatives like mobilenativefoundation.org are great, but I keep being surprised at just how less of a mobile community exists, compared to web or backend.
6. "Mega mobile teams" of 20-50+ mobile engineers working on a single app will keep increasing the coming years.
Why? Native mobile apps are increasingly where the users and revenue are at. Businesses will be rational to keep hiring engineers to ship revenue-generating features.
7. VC funding for mobile engineering tools and vendors will remain low. But VCs that fund the right teams will see large returns in 5-10 years.
Everyone underestimates the complexity, impact and profits of mobile tooling done right. Except those with first-hand experience.
I see mobile engineering being at an inflection point, 13 years after the first iOS apps.
The rate of change is slowing. The top 50 apps in the app store will not change as rapidly in 3 years from now. And the innovative mobile vendors of today will be incumbents in 5-10 years.
For details in the challenges of the space, and the landscape of common solutions, check both my book (free until 31 May) mobileatscale.com and The Mobile Native Foundation discussion boards: mobilenativefoundation.org
If you're a mobile engineer, here are things that will likely give you an edge the coming years:
- Learn the "other" platform as well.
- Master Kotlin & KMM.
- Become familiar with Flutter.
- Aim to work on a mobile platform team: this expertise will be a lot more sought after.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The two-sided marketplace nature of job seekers/jobs, how you should use it to your advantage, and how the explosion with remote work (in software engineering) is changing this balance for juniors & seniors.
Thread for anyone job searching now, or in the future.
The job market *always* starts from the companies who hire. They have the budget, and need someone with a specific skillset. They post a job, and get (and often also source) qualified applicants.
There's a huge difference between popular & unpopular ones though:
The job market is a "sellers market" when there are a lot fewer jobs than qualified ppl who want to apply or change jobs. Recessions are good examples of this (in software: 2001, 2008, and some sectors now).
When this happens, even less popular companies see a lot more interest.
One of the best engineering manager job adverts I've seen.
1. No unnecessary requirements beyond "having done some level of a similar job" 2. A very clear 30-60-90-180 days plan (the majority of the ad) 3. A salary range 4. Paid the same wherever you are based (even outside US!)
I assume decent job ads like this (that also offer terms that should be standard but are not, like remote, with the same, NY-like salary) will get lots of applications.
I heard the team is split between the East Coast and EU: I assume the timezone will be important.
Just know that honest job ads like this can generate a LOT of interest. Take it from @dhh - Basecamp saw 400+ applications for a senior engineer: m.signalvnoise.com/the-worst-part…
Two small reasons to consider working at a company that has a high-quality engineering blog:
1. A sign of a transparent engineering culture (important!)
2. Some of your work & impact can become public (writing on the eng blog), possibly creating future opportunities for you.
High-quality eng blogs:
- Share in-depth details about eng challenges, approaches, learnings.
- Talk about (internal) tools used & specifics. Often with screenshots, code samples.
- *Always* display names of the engineers authoring the post
A company with a high-quality engineering blog typically:
- Supports engineers attending engineering conferences, talking about their learnings
- Has much larger internal awareness of who does what ("have you read their blog post?")
- Can attract industry-known talent more
I've been tiptoeing on software engineering compensation in the Netherlands and Europe because... I was on the high end of it. Me and many others.
I'm starting to talk about how this system works, starting with why compensation is "tripolar". And why this is important (cont'd):
Silicon Valley is having a *huge* effect on the market going up. It might also help reverse people leaving from the EU to the US to make massive salary gains, now that the "top of the market" is going up. By a LOT.
Don't take how important it is to talk about salaries from me. Take it from a DM from a person who told me he wished he knew about these things *years* earlier.
In the best engineering organizations, engineers tend to get a lot of support from managers. And it works!
But I've yet to see a place that gave *proper* support for the frontline managers supporting their teams. It works for a while: until these managers burn out and leave.
"Proper support":
- Mentors in the org for line managers
- Team meetings with the "manager team" that's both a safe space to vent, and to take action
- Involving EMs in top-down decisions that will hit their teams
- Running retrospectives with the EMs, and acting on them
While I know a *lot* of frontline engineering managers who are amazing at taking care of their team, managers of managers and directors suddenly "forget" to do the same with their EMs.
Directors will often assume EMs don't need this. On the medium- and long-term: they would.
LinkedIn built their own crash reporting solution, and explain why they did it, and what benefits they saw.
2. At Uber, similar to LinkedIn, the mobile platform team built an internal crash reporting tool called Healthline that supported signals like ANR, non-fatal, OOM and memory leaks.
It was/is a really nice tool, with many internal integrations.