Mobile teams are second class citizens, but not on purpose

Mobile teams are still catching up with their web developer colleagues.

Not in terms of skill or contributions to their orgs, but in their access to tooling and infrastructure that supports their feature work. Maybe because their company doesn’t see mobile as being as crucial to the bottom line as web or because mobile development hasn’t been around nearly as long as web development, which means solutions to mobile developer problems either don’t exist or lack the maturity of existing web solutions.  

One area where this stands out is in the release process. Releasing new code to the web is easy; you merge and run a simple script to release it. If something goes wrong, you ship a quick fix or revert it. Easy. Web developers aren’t as sloppy as I’m implying — they’re not merging to master every night and then going out for a beer — but they don’t have to be nearly as careful with their releases as an engineer who creates a packaged binary that has to be approved by a third party and then installed by a customer.

Since web developers don’t have to think about releases as this complex and annoying process, companies that start focused on the web and then jump into mobile a little later don’t conceptualize this as a problem they need to worry about. Mobile engineers can bring in their own resources and tooling, of course, but that may not be available to them for a variety of reasons.  

Why not?

Bad mobile habits are hard to break

In the faraway era of the early 2010s, companies were racing to get in on mobile much as they’re now racing to get in on AI. “This thing is the future. We must do it!” is a tale as old as tech. Organizations quickly spun up projects to get access to the billions of dollars in potential revenue generated by the App Store and Play Store (a combined $127 billion of actual, not potential, revenue per year as of 2023) and they were off.    

Building a new thing with urgency doesn’t mean you can’t and won’t do it well, but it often does mean making compromises, creating tech debt as you rush to get things done, and ultimately establishing this speedy, compromised way of doing things as The Way to Do Things since you’ve always done things that way and it worked just fine.

In the earliest days of mobile, most companies literally had a single mobile engineer who built their entire app and added all the features to it. For a while engineering teams thought that was normal, that there was always just the one "mobile person" and that they could essentially do everything needed for the app — build new features, ship hotfixes, maintain existing stuff, do platform upgrades, etc. But as teams scaled and mobile as a platform became more established, engineering leaders eventually realized and accepted that it was silly to expect a single mobile engineer to have the same output as an entire team of 50+ web developers, and that you needed to staff mobile teams in the same way you staff web engineering teams if you expect to see the same results and velocity. But that "bad habit" of thinking mobile = one mobile dev doing everything took a long time to overcome.

When you have to do more with less, you get used to doing more with less and may even be proud of the skills you develop doing so. You adapt to problems and work around them, then take these skills to other companies where you repeat this while showing new mobile engineers that this is how things get done.  

For many mobile engineers and teams this means grabbing free and open source options (like fastlane) to cobble together their own bespoke infrastructure. It means writing 30 page long Confluence docs to manage the release process. It means having conversations about how the release is going in 18 different Slack channels. It means accepting that managing mobile releases takes a lot of hustle, and that’s just how it goes.  

But what may start with only a little tinkering to make task management easier can, over time, turn into a mess as one engineer writes this bash script over here, another one writes two fastlane scripts, and a third engineer writes up some guides that no one fully understands except for them. Before you know it, you’ve created a Frankenstein’s monster that will turn on its creator and make your releases even more stressful than before.

My point here is that the very real inclination many mobile developers have to say, “This is just how releases work, and we can handle it,” creates a problem that absolutely must be dealt with at some point as the team scales, otherwise more and more time will be sunk into technical infrastructure and administration, and less time will be put into building new features.  

Let’s say a mobile developer rejects this and says, “I need a software solution that can solve my release problems!” That’s great, but they may now run into a different problem.  

Leadership doesn’t understand how mobile differs from web

There is a tendency to view mobile through a web lens. What I mean by that is leadership may not always understand or acknowledge that mobile is different, and needs its own tooling, resources and processes that differ from the web platform. So if something isn’t particularly difficult or complex for web — like, say, releases — then it will not be initially seen as an issue for mobile, no matter how much time and effort the team may be putting into it.  

Companies that accept this mobile-as-web status quo are at risk of being left behind. Mobile may not generate AI levels of interest from startups anymore, but the average human being now spends an even amount of time on their two main screens: 3hr 30min a day on mobile devices and 3hr 34min a day on their computer. If the mobile team does not have the resources they need to ship updates at the same velocity as the web team then the company is potentially at risk of missing an opportunity during half the time that people spend staring at a screen every day.  

Not fully taking advantage of my mobile screen time has caused plenty of companies to miss out on my business. A recent example: I was looking for a new checking account a couple of months ago, and after lots of comparing, I went with Chase Bank solely because their mobile banking app is a genuine delight to use. I’ve never even logged into the web version. This was not true of my previous bank, [REDACTED].

It’s not just me, and it’s not just that these apps were uniquely made for mobile use. People want to use mobile apps whenever possible. 30% of mobile users will spend more money with an organization if it offers a good mobile experience and 66% if it offers a great one. I stole these numbers from an Instabug blog post and appreciate the research they put into finding them. I recommend reading it if your leadership team needs to be even more convinced of the value of putting more resources into mobile.

The average mobile team puts 30 to 40 hours into release tasks every month. Organizations are missing out on shipping 4 to 6 new features a year by leaving mobile teams to put coding time and resources into managing their infrastructure instead of empowering them to ship more features, more often, more safely by supporting them with the tooling they need to do this.

Let’s say leadership is on board and understands the mobile team needs access to their own resources. This may still leave teams with one problem to overcome.

Mobile release software doesn’t exist

There is tons of tooling for web developers to do deployments, but none of it works for mobile because the mobile release workflow is fundamentally different. Since mobile is a younger platform than web, there hasn’t been as much time for tools that support mobile releases to become widespread and popular, or even be invented. Sure, there are CI/CD tools and testing software and crash reporting/app health platforms, but these are disparate tools replicating functionality already existing for web developers. These tools are managed in their own silos, and they don’t help with all the manual work that goes into the release cycle.

Wait a second, though. Isn’t this blog post on a mobile release management platform’s website? How can I claim this kind of software doesn’t exist when this kind of software is hosting the words you’re reading right now?

That’s a good point. It would probably be better to say this software didn’t exist until recently. An engineer googling for out-of-the-box solutions to their mobile release problems in early 2021 wouldn’t have found anything to use. They might not even have found anything until later in 2022, when our own SEO got better.

Instead they would have had no choice but to build their infrastructure themselves, maybe with the support of some fastlane scripts they wrote after taking a little time to learn Ruby. But that brings us all the way back around to the earlier point: mobile developers have had to accept that the tooling they need doesn’t exist and so they have every reason to assume such software continues to not exist. The habit has been established and as I already mentioned, bad habits can be hard to break.

But break them you should. If you need some inspiration, large mobile teams at DoorDash and Squarespace have recently written detailed walkthroughs on their own engineering blogs discussing how they updated, evolved, and greatly improved their own release infrastructure and processes. There are worse things you could do than emulate them.